A legacy migration is not complete because records appear in a new database. People must still find the right customer, interpret the history and complete the work in progress. A technically successful import can leave operations confused if identifiers, statuses or relationships change without a clear explanation.
Plan migration as a sequence of evidence-backed decisions: establish ownership, define mappings, rehearse the transfer, reconcile the results and control the switch. The most important detail is often what happens to information created while the move is taking place.
Inventory the system around the database
List scheduled jobs, reports, exports, shared folders, integrations and manual procedures that depend on the old system. Interview the people who run monthly or occasional tasks, not only daily users. An infrequent invoice export can be easy to miss and difficult to replace during a live transition.
For every dependency, record an owner, its input and output, execution frequency and consequence of failure. Include credentials and configuration locations without copying secret values into the plan. Identify which dependencies will move, remain temporarily or be retired.
Define the scope of historical data. Some records may need to remain searchable without becoming editable in the new application. Agree that distinction with the responsible business owners and document any retention requirements already established for the organisation.
Make mapping rules explicit
Create a mapping for each important entity: source field, destination field, transformation, default, validation and handling of exceptions. Preserve a way to trace new identifiers back to old ones. That cross-reference helps support teams investigate discrepancies after the move.
Hypothetical example: an old service desk uses “closed” for both completed jobs and abandoned requests. The replacement separates those outcomes. A migration cannot infer the correct destination status from the old status alone. Define another reliable rule or send ambiguous records for review.
Handle dates, time zones, missing values and duplicated records deliberately. Do not silently turn an unknown date into today's date or merge people because their names match. Record rejected and transformed rows with reasons so the business can review the consequences.
Choose a transition shape that fits the dependencies
A single cutover moves responsibility at an agreed point. A phased migration transfers particular workflows or groups over time. The latter may reduce the size of each move, but it introduces a period when systems coexist and must exchange information predictably.
Martin Fowler's original explanation of the Strangler Fig approach describes gradually replacing an existing application. Treat that as an architectural option, not an automatic answer. Your dependencies, data boundaries and ability to operate two systems determine whether incremental replacement is practical.
Whichever approach you choose, name the authoritative system for each record type during every stage. Avoid vague instructions to “keep both updated”. If both systems accept changes, specify the synchronisation mechanism, conflict policy and person responsible for resolving discrepancies.
Rehearse with representative complexity
Run trial imports in an isolated environment with appropriately controlled data. Include attachments, unusually long history, duplicated identifiers, missing references and exceptional statuses. A clean demonstration dataset does not establish that the real transfer can succeed.
Record the exact source snapshot, migration version, start time, completion time and exceptions. Make the process restartable: a partial failure should not require someone to guess which records already moved. Verify that rerunning an agreed stage does not duplicate records or overwrite newer information unexpectedly.
Have operational users perform their actual tasks in the migrated environment. Ask them to trace a record from intake through completion and generate the outputs they rely on. This tests the meaning of the data as well as its technical presence.
Reconcile more than row counts
Matching totals are useful but insufficient. The same number of records can contain broken relationships or altered values. Define checks at several levels and assign responsibility for explaining every material difference:
- Completeness: expected records and attachments arrived, with documented exclusions.
- Relationships: requests still refer to the correct customers, owners and histories.
- Values: statuses, dates and amounts match the agreed transformations.
- Operations: important reports and end-to-end tasks produce expected results.
- Exceptions: rejected or ambiguous records have a named resolution owner.
Agree tolerances before the rehearsal. Some fields may permit normalisation while others require exact agreement. Do not adopt a broad percentage threshold that hides a missing high-value record or a broken permission boundary.
Write the cutover and recovery runbook
Set out who authorises the switch, who performs each step and which evidence permits the next step. Include the final backup, write freeze or change-capture boundary, transfer, reconciliation, integration switch and operational checks. Record a clear stop condition for each critical stage.
Rehearse recovery rather than treating a backup file as proof. Establish where it can be restored, which application version can use it and how long the tested process takes. Compare that evidence with the disruption the business can tolerate.
Rollback becomes harder after the replacement accepts new writes. Define how those changes would be preserved, exported, replayed or reconciled before returning to the old system. If recovery instead requires fixing forward, say so and identify the people and procedures needed.
Keep ownership through stabilisation
After cutover, monitor failed integrations, unresolved exceptions and discrepancies in business outputs. Provide a clear reporting route for users and a named person who can distinguish a migration defect from unfamiliar behaviour. Retire old access and infrastructure only after agreed dependencies and recovery needs have been resolved.
Use the project brief guide to commission migration discovery alongside replacement work. Visuosofts' application development service is a relevant route for discussing the new system. Contact Visuosofts with your dependency inventory, data samples and transition constraints to scope the investigation.