Custom Software · 5 min read
Legacy migration: five risks to test before going live
The new application accepts orders on Monday. At month-end, somebody discovers that historical credit notes are treated differently. The interface is finished, but an essential business case is missing. This guide turns five migration risks into practical checks and explains why a recovery plan must include records created after the switch.
Find the work that does not appear in the main menu
Export scripts, spreadsheet macros, print templates and overnight jobs may sit outside the application. Ask the people handling month-end work and exceptions which files they move and which figures they correct manually.
Collect representative transactions and their expected outcomes. Include cancellations, partial payments, returns and retrospective corrections where relevant. Reuse these cases for acceptance. A function is understood when the team can explain why its result is correct, not merely reproduce its screen.
Inventory
Identify record types, integrations and the authoritative system.
Rehearse
Copy representative data and test repeat deliveries.
Reconcile
Check relationships, totals and critical records; explain differences.
Approve cutover
Confirm acceptance criteria, recovery and responsibilities.
Suggested review sequence. Each transition needs evidence and an accountable owner.
Reconcile relationships as well as record counts
An import can preserve the number of rows while linking them to the wrong customer, changing decimal precision or replacing historical prices with current prices. Document field mappings, identifiers, units, time zones and the meaning of missing values. Record cases that cannot be resolved automatically.
Consider a fictional wholesaler importing 12,000 orders. The count matches, but 240 line items lose their order relationship. Only a relationship check reveals the defect. Compare totals by period, open balances and records without valid parents.
Cleaning data requires business decisions. Similar company names do not prove that records describe the same customer. Confirm ambiguous merges and preserve a traceable source-to-target mapping.
Assign one owner for each type of data
Two systems changing the same stock figure create a conflict that a nightly sync cannot reliably settle. Document which application owns each important value, the direction of transfer and when ownership changes.
Test delayed and duplicate messages and an unavailable interface. Retrying an order whose acknowledgement was lost must not create a second order. AWS describes this as idempotent processing. Demonstrate the business result by delivering the same operation repeatedly and observing one intended effect.
Keep improvements separate from launch requirements
Migration discussions uncover changes people have wanted for years. Maintain separate lists for essential functions, defects and later improvements. Evaluate each addition against effort, data and tests.
The business owner then decides whether it belongs in the first release and what must move out if necessary. A fixed price cannot compensate for an undefined scope. It needs an agreed boundary.
Acceptance means completing real work
Developer click-throughs cannot establish every business rule. Ask future users to complete realistic tasks with appropriately prepared data. Observe permissions, search effort and error recovery as well as the final result.
Record passed cases and unresolved launch blockers. Training and delivery of screens are different from business acceptance.
| Risk | Evidence before launch | Business decision owner |
|---|---|---|
| Hidden work | Critical cases and expected results | Process owners |
| Data errors | Relationships, totals and exception reconciliation | Data owners and business teams |
| Parallel operation | Data ownership and duplicate-delivery tests | System and process owners |
| Expanding scope | Approved release scope and later backlog | Project sponsor |
| Unusable workflows | Completed tasks by future users | Named acceptance owners |
Rehearse recovery before new transactions begin
Define a final synchronisation and, if needed, a bounded period without writes. Follow it with technical checks and business approval. Use explicit stop conditions such as irreconcilable stock differences or unprocessed payments.
Once the new application accepts writes, restoring an earlier database can remove new work. Specify how those transactions will be preserved and reconciled during a reversal or repair. Microsoft highlights the additional complexity of stateful and schema changes in safe deployment guidance.
Run a timed rehearsal. Identify who decides, who disables writes and who informs users. Check access and absence cover. A recovery procedure with missing credentials cannot help during an incident.
Define completion beyond the first day
Keep a defined observation period for infrequent workflows, issue ownership and repeated reconciliation. Retire the original system only after dependencies, archive access and open transactions are addressed.
A process sketch, major data sources and a difficult business case are useful inputs for a first planning discussion. They allow a bounded investigation before estimating the entire migration.