A legacy system may still support orders, billing, or customer service while making every change harder. Modernising it means protecting those operations and starting with a stage the team can observe, validate, and reverse.

The objective is to reduce disruption risk. No pattern guarantees absolute availability: continuity depends on dependencies, data, and the ability to respond when a change does not behave as expected.

1. Make the operational dependencies visible

Start with a process map and the technology supporting it. Identify what each component does, who uses it, and what happens if it stops responding. Talk to the people handling incidents too: they often know dependencies that documentation misses.

  • Critical flows: orders, closing activities, payments, and tasks that must not become blocked.
  • Dependencies: APIs, scheduled jobs, files, shared databases, and external consumers.
  • Data and rules: where information is written, who treats it as authoritative, and which exceptions require manual correction.
  • Operations: sensitive time windows, owners, alerts, and recovery procedures.

This inventory distinguishes a component with clear boundaries from one that appears independent but shares state or rules across the system.

2. Choose a first stage you can verify

A good candidate combines business usefulness, understandable boundaries, and manageable scope. It might be a query, an integration, or one specific capability. The oldest component is not necessarily the best first migration.

Define the expected outcome and how you will check it: equivalent responses, data reconciliation, errors, response times, and manual intervention. Agree the criteria with the people using the process and measure the current situation before changing it.

  • Which problem does this stage remove?
  • Which contracts must it preserve for consumers?
  • Which dependency could prevent isolation?
  • How will we know it works, and when will we stop the change?

3. Let the existing and new systems coexist

The Strangler Fig pattern documented by Microsoft replaces capabilities gradually and uses a façade to route requests to either the old or the new system. It supports keeping the existing application running while responsibilities move.

The practical idea is to keep a stable entry point and move one capability at a time. That boundary might be an API, adapter, or routing layer. It also creates temporary work: two environments, contracts to maintain, and dependencies to monitor.

The AWS Strangler Fig guidance describes this incremental approach for decomposing monoliths. Applying it should start with the system's constraints; moving to microservices is not a universal requirement for modernisation.

If you cannot intercept requests, isolate state, or maintain coexistence, you will need another strategy. The pattern must fit the operation and the team's capability.

4. Treat data as part of the migration

Code can return to an earlier version while its effects on data persist. Before changing a capability, specify where it will write and which system will be the source of truth during each stage.

  • Compatibility: can the previous system read new data and states?
  • Synchronisation: how will you detect lag, duplicates, or out-of-order events?
  • Reconciliation: how will you check integrity and business outcomes?
  • Recovery: which changes must be replayed or compensated when returning to the previous system?

Writing to two databases does not create consistency by itself. If one write fails, you need an explicit retry and repair policy. A backup helps recover information, but it does not replace a procedure for dealing with operations performed since that backup.

5. Deploy with signals and a rehearsed exit

Agree who decides to advance, stop, or roll back. Where the architecture allows it, start with a user group, a fraction of traffic, or a controlled window. Observe both technical health and process outcomes: a successful HTTP response can still contain an incorrect calculation.

The Microsoft guidance on safe deployments recommends progressive exposure, health checks, and recovery plans. Define the advancement criterion before widening the change.

  • Technical signals: errors, latency, queues, resources, and dependency availability.
  • Operational signals: completed transactions, discrepancies, and user incidents.
  • Stop criteria: conditions that require halting expansion or starting recovery.
  • Rollback rehearsal: steps, permissions, data, measured duration, and owner.

If returning safely to the previous state is not possible, record the limitation and prepare another recovery option. Routing traffic back does not undo payments, notifications, or completed writes.

An example: separating order queries

Illustrative example, not a client case: a company wants to improve order tracking while its existing system retains order creation and billing.

The first stage can replace only the query capability. A new interface obtains statuses through a defined contract; the existing system still handles writes. The team compares responses, checks permissions, and observes data freshness before expanding use.

If incomplete statuses or unacceptable delays appear, the team routes queries back to the previous system and investigates. Once reads are reliable, it can explore a second stage for writes with a separate consistency and recovery plan.

Checklist before approving the first stage

  • A dependency map and process owner are in place.
  • The chosen component has verifiable boundaries and contracts.
  • Write ownership and the source of truth are defined.
  • Tests cover the common case, exceptions, and relevant failures.
  • Advancement and stop signals are agreed.
  • Recovery has been rehearsed with representative data and permissions.
  • There is a plan to retire coexistence when it is no longer needed.

Modernising with control turns a large transformation into stages that produce evidence. The first delivery should improve one part of the operation and clarify what the team needs before taking on the next stage.

Codiloop can help you scope your first modernisation stage by reviewing dependencies, integration, data, and recovery before committing to the full scope.