Incremental system modernisation guide
How do you modernise a business system without replacing it?
Keep the existing system of record where it still works, place a stable integration boundary around it, and deliver one valuable interface, workflow or service at a time while old and new components coexist safely.
The direct approach
Define the business outcome, isolate the existing system behind an adapter or service, and add one new capability outside it. Keep the legacy system authoritative for the records and rules it still owns. Route only the selected workflow through the new component, reconcile both sides and maintain a practical rollback path.
This is not a promise to keep every legacy component forever. It is a way to earn replacement decisions with working boundaries, measured value and lower operational risk.
01
Decide whether the constraint needs extension or replacement
| Evidence | Extend first | Replace or retire sooner |
|---|---|---|
| Core processing | Stable, trusted and understood | Incorrect, unsafe or no longer supportable |
| Integration | Supported API, events, files or reliable read access exists | No safe interface and change cannot be controlled |
| User experience | Core works but screens or self-service are poor | Required workflow conflicts with the whole data and process model |
| Change demand | A few capabilities need faster iteration | Most capabilities require coordinated structural change |
| Operating risk | Coexistence can be monitored and supported | Vendor, security or compliance risk is unacceptable |
Age is not the decision criterion. Use service impact, change cost, supportability, security, data quality and strategic fit.
02
Create a stable boundary around the existing system
The adapter translates modern application concepts into the existing system's supported contracts. It prevents every new screen, service and partner from depending directly on legacy table names, protocols and quirks.
- define operations in business terms rather than database terms;
- validate inputs before calling the legacy system;
- translate identifiers, statuses, dates and error responses consistently;
- add timeouts, retries and idempotency only where appropriate;
- record correlation identifiers and outcomes for support; and
- version the new contract independently of internal changes.
03
Use the smallest modernisation pattern that solves the problem
Experience
New interface
Add a customer or staff application while keeping existing transactions and rules.
Access
API facade
Expose a stable supported contract instead of multiplying direct dependencies.
Reporting
Read model
Copy approved data into a model designed for search, reporting or external access.
Capability
Incremental extraction
Move one bounded domain or service out when ownership and behaviour are clear.
AWS describes the strangler fig pattern as progressively routing selected functionality to new components while the existing application continues to operate. The useful idea is controlled coexistence, not a mandatory move to microservices.
04
Keep data ownership and write paths explicit
| Concern | Practical rule |
|---|---|
| System of record | Name the authoritative owner for each entity and state transition |
| Reads | Use an API for current state or a reconciled read model for scalable views |
| Writes | Send commands through supported business operations rather than raw table updates |
| Synchronisation | Define latency, replay, duplicate handling, ordering and correction behaviour |
| Identifiers | Maintain governed mapping between legacy and new identities |
| Cutover | Change ownership only with migration, reconciliation and rollback evidence |
Read more about building an application on an existing ERP or CRM and connecting a custom application to a legacy system.
05
Plan how old and new components will coexist
For every release, state which users and transactions use the new path, what remains on the old path, how data is reconciled and how support teams recognise a failure. A coexistence register should include:
- capability and current owner;
- traffic or user routing rule;
- data read and write direction;
- acceptable delay and failure behaviour;
- monitoring and support owner;
- rollback trigger and procedure; and
- evidence required to retire the legacy path.
06
Control the risks that incremental programmes often hide
- Permanent duplication: give every transitional component a review date and exit condition.
- Split business rules: identify one owner and test equivalent outcomes across paths.
- Uncontrolled direct access: stop new consumers from bypassing the modernisation boundary.
- Invisible synchronisation failure: monitor delay, dead letters, mismatches and replay.
- New interface over bad process: simplify the workflow before automating every historical exception.
- No operating ownership: fund support, observability and change management as part of delivery.
07
Build a roadmap around business slices
- Measure the current friction, risk or service limitation.
- Choose one bounded user journey and map its dependencies.
- Define source ownership, the integration boundary and failure behaviour.
- Prototype the riskiest interface or data synchronisation assumption.
- Release to a controlled user group with old and new paths observable.
- Compare outcome, support load, data accuracy and change speed.
- Expand, adjust or retire a legacy capability only when evidence supports it.
Sources
Primary references
Related solution
Need a delivery path rather than a technical guide?
The business system modernisation solution explains how focused applications, integration boundaries and incremental capability change fit into a commercial delivery approach.
Questions
Frequently asked questions
Can you modernise a legacy system without replacing it?
Yes. Keep the existing system responsible for stable capabilities while adding supported interfaces, new read models and focused applications around it. Replace components only when their risk or constraint justifies the change.
What should you modernise first?
Choose a bounded customer or staff workflow with clear value, manageable dependencies and measurable friction. Prove the integration and operating model before tackling a deeply coupled core process.
What is the strangler fig pattern?
It is an incremental modernisation pattern in which new components are introduced around an existing application and take over selected capabilities over time. Old and new systems coexist until a legacy capability can be safely retired.
Should the new application write directly to the legacy database?
Prefer supported APIs, services or controlled integration adapters. Direct database writes can bypass business rules, create tight coupling and make both rollback and future replacement harder.
When is full replacement still appropriate?
Replacement may be justified when the system is unsupported, unsafe, economically unsustainable, legally unsuitable, impossible to integrate or fundamentally unable to support the required operating model. Make that decision with evidence rather than age alone.
Plan an incremental change
Bring the constrained workflow and the system that supports it today.
LCR can help identify a safe modernisation boundary, prove the riskiest integration and deliver a focused first release.