Migrating a running legacy system: ownership, cutover and fallback

Choose a transition boundary staff understand

A phase should be recognisable in daily work. Examples include new service requests after an agreed point, one customer group or one bounded process responsibility. Assess whether staff can tell which system to use at that boundary. A technical module boundary may be unsuitable if one operation constantly switches between old and new applications.

Describe exceptions remaining in the old application too. Who amends a request created before transition? How is a new employee instructed? Offering historical records as a read-only archive differs from maintaining two active processes. The boundary should show which responsibility genuinely moves during the phase and which old procedure can subsequently be retired.

Record the normal workflow and unfinished work

Describe states occurring during a working day: received, reviewed, in progress and completed, using the process’s own meaning. Record where unfinished cases will sit when cutover begins. A request already assigned to an employee cannot be treated as though nobody has reviewed it.

Use this baseline to select transition checks. Can staff find their outstanding work? Do customer commitments remain recognisable? Which checks temporarily remain manual? Validating the prepared data import belongs to the import workstream. The operational trial then examines whether people can continue using those records at the agreed point, including work already in flight.

Assign write ownership for each operation

Record which system may accept new requests, corrections and status changes. Different records can have different owners, but every responsibility must be named and technically enforceable. Two screens displaying the same information can otherwise suggest that staff may use either one.

Work through a concurrent change. A planner amends an appointment while an old background job sends an earlier status. Which change wins, and how is the other processing blocked or reviewed? Identify who may resolve conflicts. A temporary period with two writers requires more than a promise to reconcile later. If available source information cannot distinguish the changes reliably, the transition may need a stricter boundary.

Define data reconciliation, exceptions and business review separately: Import data into new software: turn an export into reviewed records.

Design temporary coexistence explicitly

Describe what the systems exchange during coexistence, in which direction and with what meaning. Limit the temporary connection to responsibilities needed for the phase. A new application inheriting every old exception may lose its intended design advantage before the first phase finishes.

A translation boundary can separate different models, as described by the anti-corruption-layer pattern. It does not replace operating and ownership agreements. Demonstrate a normal handover, a rejected message and an uncertain outcome. Identify who operates the temporary connection and when it can be removed. Without a retirement criterion, temporary dual operation can silently become permanent.

Microsoft Azure Architecture: Anti-Corruption Layer ↗

Agree how ongoing changes are handled

Choose deliberately between an agreed input pause, later processing of changes or another controlled transition. The choice depends on available source information and the organisation’s operating flexibility. Do not assume every older application provides a complete change log. Investigate how deletions and corrections become visible, for example.

Define the transition in business terms. When should staff create a new request in the new system? Where should an existing request be amended? A technical timestamp alone does not answer those questions. Explain how a late file or message will be handled. Otherwise the migration may appear correct while a post-transition change is still lost.

Rehearse work around the cutover point

A transition rehearsal should show more than opening a new record. Include work started before cutover, a change at the boundary and a late notification from the old system. Agree which operations are simulated and which are actually executed in an agreed test environment.

Ask staff to explain where they continue and how they recognise uncertainty. A new request might belong in the new application while amending an older one still uses an explicit old route. The rehearsal tests whether that distinction is workable. If many cases still need verbal explanation, revise the phase boundary or instructions before moving a wider group of users.

Reconcile ongoing work on both sides

During transition, check that expected business events have been processed. Matching total record counts can hide two missing cases and two duplicates. Use a difference view that follows a request or operation through the systems using recognisable references and processing states.

Agree how often someone reviews differences and when further cutover pauses. An unexplained backlog might be a temporary technical interruption or evidence that the responsibility boundary is wrong. Treat the view as an owned work queue. Preserve how each discrepancy was resolved so the same late notification does not repeatedly cause investigation or duplicate work.

Make cutover an explicit decision

Agree which checks must pass, which limitations are temporarily acceptable and who authorises cutover. A technical team cannot independently decide that missing history is operationally unimportant. Involve the owner of the affected business journey.

Include the availability of people. A quiet migration window is of little use if nobody can assess an unexplained discrepancy. Staff, operators and suppliers need consistent transition instructions. If an important criterion fails, postponement or a narrower first step should remain possible. That decision belongs in the plan rather than being invented under cutover pressure.

Define fallback after new input exists

Fallback is easy to describe while only a copy has been made. Once staff have entered new requests, corrections or messages, those activities need a place in the recovery plan too. Restoring the old database can discard new information. Explain when reversal remains straightforward and when additional reconciliation becomes necessary.

Recovery might include temporary manual recording or a separate export of new changes. Investigate and rehearse the appropriate route with examples before cutover. Do not promise recovery time based on a document alone. Show which operations have been exercised and which dependencies remain uncertain.

Google SRE: Testing for Reliability ↗

Example: moving an enquiry workflow in phases

Illustrative example: a maintenance company receives new service enquiries through a portal from Monday onward. Existing jobs remain in the current scheduling application. A temporary connection forwards approved new enquiries but does not let the portal independently overwrite appointments. A late scheduling amendment remains identifiable as a separate event.

The rehearsal changes an enquiry while it is being handed over. The team discovers that the old route can resend an earlier confirmation. It adjusts the boundary and check before moving more users. The phase decision then rests on a working handover, explained differences and an agreed treatment of unfinished jobs. That evidence differs from merely completing a successful data import.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Legacy software modernisation ↗
• Software audit ↗

Questions about this topic

Continue with a related question