Replacing a core system puts everyday business operations inside a change programme. Orders still need to ship. Customers still expect accurate balances. Finance still needs to close the month. Meanwhile, engineering teams must move data, reconnect integrations and establish confidence in software that has not yet handled the full range of production conditions.
The difficulty is that an established system contains years of accumulated business knowledge. Some of that knowledge lives in code. Some lives in scheduled jobs, spreadsheets, undocumented interfaces and the judgement of experienced staff. A replacement can meet its written requirements while missing behaviour that the business depends on.
Reducing migration risk starts with making those dependencies visible. It then requires a controlled transfer of responsibility: which system owns each process, where authoritative data lives, how correctness is measured and what happens when a migration step fails.
For technology leaders, the practical objective is to keep the consequences of each change bounded while building enough evidence to proceed.
Define the business outcome before choosing the replacement
A migration programme can become committed to a new platform before the organisation has agreed what it needs to improve.
"The system is old" gives little guidance when delivery choices become difficult. A stronger case identifies specific constraints: unsupported infrastructure, unreliable recovery, expensive manual reconciliation, slow product changes or an inability to handle expected demand.
Each constraint should connect to a measurable outcome. For example:
- Reduce the time required to introduce a new pricing rule.
- Restore order processing within an agreed recovery window.
- Remove manual reconciliation between fulfilment and billing.
- Retire a platform before its support agreement expires.
These outcomes help distinguish essential migration work from desirable enhancements. Without that distinction, replacement programmes tend to absorb process redesign, data cleansing and new product requirements until the original scope becomes unrecognisable.
Challenge the assumption that every part of the system needs replacement at the same time. Infrastructure risk might be addressed through rehosting. An integration problem might need a new interface. A business capability might justify a rewrite while other components remain serviceable.
Westpoint's discussion of moving legacy applications to AWS or Azure without rebuilding them explores that separation between moving an application and changing its design.
The business case should also account for the transition period. Running two systems, maintaining adapters, rehearsing migrations and supporting users all require funding. A replacement that looks affordable at steady state may be difficult to deliver if coexistence costs are omitted.
Discover how the business actually uses the system
Architecture diagrams provide a starting point. They rarely capture every operational dependency.
Discovery should follow complete business journeys. For an order management system, trace an order from creation through stock allocation, payment, dispatch, cancellation and refund. Identify where each decision happens, which records change and which external parties receive information.
Then examine exceptional cases. What happens when an order is amended after dispatch? Can a payment arrive before the matching invoice? How are duplicate customer records resolved? Which corrections can support staff make directly?
These questions expose behaviour that feature lists often miss.
Combine interviews with production evidence. Review application logs, database access, batch schedules, file transfers and incident records. Observe staff completing tasks, including the workarounds they use when the software falls short.
Pay particular attention to direct database consumers. A reporting tool, spreadsheet or overnight export may depend on table structures that the replacement will change. If those consumers remain undiscovered, a successful application cutover can still interrupt downstream operations.
The result should be a dependency map with named owners and a record of uncertainties. Each unresolved dependency needs an investigation task, an impact assessment or an explicit decision to accept the risk. Uncertainty becomes manageable when someone is responsible for resolving it.
Choose migration boundaries that contain failure
The unit of migration determines how much of the business can be affected by one mistake.
Moving everything during a single cutover creates a short transition period, but concentrates data movement, integration changes and user adoption into one event. Incremental migration spreads those changes over time, at the cost of temporary complexity.
Neither approach is automatically suitable.
A single cutover can be reasonable for a small system with few dependencies, a manageable data volume and an acceptable outage window. It may also be necessary where a packaged platform cannot support coexistence.
Incremental replacement becomes more attractive when capabilities can be separated and the business needs continuity during a longer programme. AWS describes the strangler fig pattern as a way to replace functionality gradually while the existing application continues to operate.
The boundary needs to reflect business behaviour. Useful candidates include a capability, a region, a product line or a customer cohort. Each has different implications:
- A capability boundary can clarify responsibility, but may leave cross-system workflows.
- A regional boundary can simplify local support, but shared records may cross regions.
- A customer cohort can limit exposure, but account routing must remain consistent.
Randomly splitting requests between systems can be unsafe for stateful workflows. If order creation reaches the replacement while cancellation reaches the legacy application, neither may have a complete picture.
Prefer boundaries with clear data ownership and limited dependencies. The first migration should be meaningful enough to test the approach, yet small enough that failure can be contained.
Treat data correctness as a business requirement
Copying records successfully does not prove that the replacement understands them correctly.
The old and new systems may represent customers, balances, dates and statuses differently. A legacy application may treat a blank field as "approved", while the replacement treats it as "unknown". Both databases can contain the same number of records and still produce different decisions.
Define data mappings alongside business rules. Document how identifiers are preserved, how duplicates are handled, what happens to incomplete records and which historical states remain valid.
Reconciliation should operate at several levels. Record counts detect missing batches. Field comparisons detect transformation errors. Business checks reveal whether the migrated data supports correct outcomes.
For an order system, useful checks might include:
- Every active order belongs to a valid customer.
- Allocated quantities agree with the inventory position.
- Payments and refunds reconcile to the expected balance.
- Cancelled orders cannot enter fulfilment.
- Historical records remain available to authorised users.
A discrepancy needs a defined path to resolution. Decide who investigates it, whether it blocks migration and how any correction is recorded. Avoid silently changing data during migration to make validation pass.
Large datasets may require an initial load followed by replication of subsequent changes. That introduces questions about event ordering, replication lag, deletes and transformations. The final transfer of authority still needs a controlled point at which the target's state is verified.
Build reconciliation early and run it repeatedly. Discovering a mapping error during rehearsal is useful. Discovering it after customers have acted on incorrect information is much harder to repair.
Make coexistence explicit and temporary
Running old and new systems together can reduce exposure, but it creates its own failure modes.
The central question is where writes happen. During each migration phase, identify the authoritative system for every relevant entity or business capability. Ownership may move over time; it must remain unambiguous.
Writing independently to both systems is particularly difficult. One write can succeed while the other fails. Retries can create duplicates. Events can arrive out of order. A user may see a change in one interface before it appears in another.
Where asynchronous replication is used, specify the acceptable delay and the business behaviour during that delay. A reporting view may tolerate stale data that a credit check cannot.
Adapters also need careful design. They can translate between old and new interfaces, allowing dependencies to move gradually. But an adapter may reproduce assumptions from the legacy system inside the replacement unless the team deliberately defines the new contract.
Every temporary component should have an owner and a removal condition. Record which migration wave eliminates each synchronisation job, compatibility endpoint and routing rule.
This is where enterprise modernisation and systems integration need to be planned together. Replacing the application leaves substantial work if surrounding processes still depend on its old interfaces.
Coexistence should have a budget and an expected duration. Review both as the programme progresses. Otherwise, temporary architecture can become a permanent operating cost.
Design rollback around accepted transactions
A rollback plan must explain what happens to business activity completed after cutover.
Before the replacement accepts writes, returning to the legacy system may be relatively straightforward. Once customers have placed orders, staff have changed accounts or payments have been processed, the legacy database may be stale.
Redirecting traffic alone could lose accepted transactions or allow them to be processed twice. AWS's cutover guidance distinguishes rollback before data changes from rollback after the target has received new transactions.
Plan for several failure states. A problem discovered before writes resume may allow a simple return to the source. A fault detected after a limited period of activity may require reverse replication or controlled transaction replay. A later failure may make repair in the replacement safer than returning to the old system.
That last option, often called fixing forward, still needs preparation. Identify likely incidents, diagnostic tools and recovery procedures before cutover.
For each migration wave, define:
- The conditions that stop or reverse the change.
- Who makes the decision.
- How transactions are preserved and reconciled.
- How long recovery is expected to take.
- Which external actions require compensation.
External side effects deserve special attention. Restoring a database does not reverse a dispatched parcel, an issued invoice or a notification already sent to a customer.
Rehearse the recovery procedure. A backup confirms that data was captured; a successful restore and reconciliation exercise provides evidence that operations can resume.
Test complete journeys and operational failures
The replacement must be tested against the way the business works, including interruptions and unusual cases.
Happy-path functional tests establish a baseline. They should be accompanied by scenarios involving delayed responses, duplicate events, expired sessions, partial fulfilment and downstream outages.
Use representative data volumes and distributions. A large customer account, a long transaction history or a heavily used reporting query may expose problems that clean test data never reaches.
Where appropriate, compare old and new behaviour using replay or shadow processing. Shadow processing must suppress side effects so that it cannot create duplicate payments, emails or shipments.
Differences require interpretation. The legacy system may contain defects that should not be reproduced. Business owners need to approve intended changes so the team can distinguish improvements from regressions.
Migration tooling needs scrutiny too. Test failed batches, interrupted transfers and repeated runs. A process that resumes safely after interruption is more useful than one that works only under ideal conditions.
Operational tests should establish whether the delivery team can detect and recover from failure. Restore backups. Exercise access controls. Simulate an unavailable dependency. Confirm that alerts reach the people responsible for responding.
These activities belong in the delivery schedule. Leaving them until the end makes them vulnerable to deadline pressure precisely when their evidence is most valuable.
Measure business health during the transition
Infrastructure metrics can show healthy servers while business processes fail.
A replacement might respond quickly while dropping cancellations, delaying invoices or building a queue that will exceed the fulfilment window. Monitoring should therefore connect technical signals to business outcomes.
For order processing, useful measures include completed orders, failed allocations, ageing queues, reconciliation discrepancies and the time between payment and dispatch. Combine these with latency, error rates and resource usage to make diagnosis possible.
Establish a baseline before migration. Where traffic is split, compare outcomes in a way that accounts for differences in customer size, workload and product mix.
Agree acceptance thresholds with operational owners. Some conditions may require an immediate stop, such as confirmed data loss. Others may justify pausing expansion while the team investigates.
The threshold should include a response. An alert without an owner or a decision path merely records that something went wrong.
The platform needs to support this operating model through repeatable deployments, access controls, recovery procedures and usable telemetry. Westpoint's cloud engineering and platform delivery services bring these concerns together with architecture and migration work.
Prepare people and rehearse the cutover
A technically sound replacement can still disrupt operations if staff cannot complete familiar tasks.
Train users around their responsibilities: handling an exception, correcting a record, finding transaction history and knowing when to escalate. Update procedures and permissions alongside the software.
Involve experienced operational staff early. They often know which rare cases matter and which workarounds keep the business running. Their participation also helps identify where the replacement deliberately changes a process.
The cutover itself should use a rehearsed runbook. Each step needs an owner, an expected duration and a verification condition. Include dependency checks, controls on incoming writes, final data synchronisation, reconciliation, routing changes and confirmation of business activity.
Rehearsals provide timing evidence. If a transfer takes longer than the available outage window, the plan needs adjustment. If a manual check produces inconsistent results, it needs clearer criteria or automation.
Prepare support coverage for the workload being migrated. Partners and downstream teams may need to be present, particularly where failures cannot be diagnosed from the replacement alone.
Plan beyond the first morning. Some defects appear only during overnight processing, invoicing or month-end activity. The observation period should cover the relevant business cycles.
Retire the legacy system using evidence
The programme is not finished when users begin working in the replacement.
The legacy application may still receive writes, supply reports or host historical records. Integration credentials may remain active. Temporary jobs may continue consuming resources and staff attention.
Define retirement criteria before the first migration wave. Confirm that dependencies have moved, reconciliations are accepted and operational teams can support the replacement. Check that required historical information remains accessible and that backups can be restored where needed.
Then remove the old routes, jobs and access paths in a controlled sequence. Retire licences and infrastructure only after checking that doing so will not remove a remaining dependency.
This work makes the business case real. Cost savings and reduced support effort remain uncertain while both estates continue running.
Start with one migration wave that can be proved
A practical next step is to select one bounded capability and document its current behaviour, dependencies, data ownership and business value.
Use that capability to prove the target design, data mapping, reconciliation process and recovery procedure. Rehearse its cutover, migrate a controlled workload and observe it through the business cycles that matter. Expand only when the evidence meets the agreed acceptance criteria.
For each wave, the team should be able to explain what will change, how it will detect an incorrect outcome, how it will preserve accepted transactions and what allows the previous implementation to retire.
Those answers give leaders a concrete basis for proceeding. They also give engineers and operational staff a shared plan for handling the moments when migration does not go as expected.
