Replacing a legacy system while keeping operations running
Plan staged replacement, coexistence, rehearsed cutover and recovery around the interruptions and risks the business can accept.
Replacing a legacy system starts with a continuity decision: which work must keep running, what interruption is acceptable and how the business will recover if a stage fails. A staged approach can reduce disruption, but it cannot promise zero downtime for every system.
Begin with the functions and dependencies, including the workarounds staff rely on. The old system's useful behaviour is rarely captured completely in its feature list.
Choose a boundary that can move safely
A site, user group, workflow or service may provide a practical replacement boundary. Confirm whether its inputs, outputs and records can be separated without breaking work that remains in the old system.
Avoid treating every old feature as a requirement for the new platform. Observe actual use and ask which capabilities support current work. Rebuilding unnecessary behaviour adds effort and can delay the useful changes.
The Strangler Fig pattern describes incremental replacement through a routing layer. It suits systems where the relevant requests can be redirected. It is an option to assess, not a universal requirement for modernisation.
Compare the transition approaches
| Approach | Useful when | Main condition to manage |
|---|---|---|
| Single cutover | The system is understood and a planned outage is acceptable | Rehearsal, final synchronisation and a credible recovery window |
| Move by site or workflow | Work can be divided into controlled groups | Connections and ownership during coexistence |
| Replace behind a routing layer | Requests can be directed to old or new functions | Reliability and eventual removal of the temporary layer |
| Parallel comparison | Important outputs need comparison before use | Duplicate work and suppression of external side effects |
Parallel processing needs particular care. Two systems calculating an outcome may be helpful; two systems sending the same order, message or financial instruction can create a new problem.
Define record ownership during coexistence
For each record, state where updates are made and how the other system receives them. Resolve edits, delayed messages and transactions created while a stage is moving. Temporary connections need support and monitoring just as permanent ones do.
Treat data migration as a separate workstream with owners, repeatable loads and acceptance evidence. Counts, balances, relationships and representative workflows need checking. The data migration guide covers this work in more detail.
Decide when the source must stop accepting updates and how the final changes reach the target. A rehearsed migration using yesterday's data does not establish that cutover-day records will reconcile.
Rehearse recovery under realistic conditions
Write the conditions for stopping or returning to the previous arrangement. Name who decides and what evidence they use. Keep the required access, tools and people available throughout the transition window.
Once the new platform accepts live transactions, recovery may require bringing records back into agreement. Test that path. A backup is useful, but restoring it without accounting for subsequent work can lose legitimate transactions.
Prepare the people who run the service
Walk through the transition with frontline staff and support teams. Explain what changes, where work is completed and how issues are reported. Make pending work visible when it moves between systems or teams.
Keep a defined period of early support, then review the first complete business cycle. Retire the old component only when the relevant workflows, records, reporting and archive access have been accepted.
Twin's enterprise platform and workflow approach assesses components as retain, configure, integrate or build. The purpose is a controlled operating change, with the new system earning its place through evidence rather than a switch date alone.