Direct answer
Stop loading, stop further changes, and take a copy of both the old and the new system as they are now. Then find out exactly what is wrong before choosing between going back and repairing forward. The choice depends on whether the old system is still intact and whether people have already started working in the new one. The longer new work lands on top of a bad load, the harder a clean return becomes. This page is a first-response guide. It does not promise that a failed migration can always be reversed, and the planning that should have come before is in the legacy system data migration plan.
First moves: stop, freeze, snapshot both sides
Before diagnosing anything, protect what exists:
- Stop any load that is still running or scheduled to run again
- Stop people creating or editing records in the new system, or note precisely what they change from now on
- Keep the old system unchanged and readable
- Save a copy of the new system's current state and of the files that were loaded
Scope the damage
Find out what is actually wrong instead of guessing from one bad record. Compare the two sides on the things that matter: which record types are missing, which fields arrived empty or changed, which users are affected, and whether the problem is spread evenly or clustered around a source, a date range or one kind of record. Write down what you find. A vague statement such as some data is wrong cannot be acted on, while a list of specific gaps can be turned into a repair plan. The checks in data formats before migration explain a frequent source of quiet damage.
Roll back or fix forward: the questions to ask
There is no universal answer, but these questions usually decide it:
- Is the old system still complete and untouched, and can it go back into use?
- Has anyone created or changed records in the new system since the load?
- Is the damage limited and well understood, or still unclear?
- Can the affected records be corrected without touching the rest?
- Who is authorised to decide, and who must be told before the decision?
Why the rollback window closes
Going back is simple only while the new system holds nothing that the old one does not. Once people enter new work there, a rollback discards it or forces it to be copied back by hand. That is why the freeze matters, and why the release process needs a rollback decision made before the load rather than after. See safe software release and rollback for that side of the planning.
Handling records created since the load
If work has already happened in the new system, list it. Decide for each group whether it stays, gets re-entered elsewhere or is held until the repair is done. Keep this list separate from the migrated data so that nobody has to guess later which records are original and which are new.
Re-run only what failed, with the same rules
If you repair forward, load only the missing or corrected records, using the same mapping and rules as the original run. Loading everything again risks doubling what already arrived. Before each re-run, agree how a record that already exists is recognised, which is the ID question covered in keeping old IDs and links after migration. Test the re-run on a small sample and check the result against the old system before doing the rest.
Communicate to users
Tell the people who use the system what happened, what they should not do, and where to look for the truth in the meantime. Silence produces workarounds and new inconsistencies. For a CRM move, the cutover steps in the CRM migration cutover checklist list what users need to hear.
Write the incident record and change the plan
Keep a short written record: what was loaded, what went wrong, what was found, what was decided and why, and what changed in the plan. Use it to change the next attempt, for example by adding a sample check, a stricter sign-off or an explicit rollback trigger.
Where LATYNEX fits
If the target is a custom web application, portal, integration or internal tool that LATYNEX is building or scoping, we can help plan the repair or the rerun as part of that work, with scope and cost agreed in writing. See Web Application Development.
When LATYNEX is not the right fit
It is not the right fit for a pure vendor-to-vendor move that needs no custom build, where the vendor's own support is the right first call. It is also not the right fit for a file-server or infrastructure migration, which is an IT operations job. LATYNEX does not offer an emergency repair or takeover service.
Questions
What is the first thing to do when a migration partly fails?+
Stop further loading and changes, and take a copy of both systems as they are now. Do not repair anything until you know what is wrong.
Should we roll back or fix forward?+
It depends on whether the old system is intact, whether new work has landed in the new system and how well the damage is understood. Decide with the people who own the data.
Can we simply run the whole load again?+
Usually not blindly. Loading everything again can duplicate records that already arrived. Re-run only what failed, with the same rules, after testing on a sample.
What if users have already entered new records?+
List them separately and decide for each group whether it stays, is re-entered or waits. Do not mix them into the migrated data without a record.
Can a failed migration always be reversed?+
No. It depends on what still exists in the old system and what has changed since. That is why a rollback plan belongs before the load.