A data migration rarely fails on the technology. It fails on what nobody counted, requested or wrote down beforehand. This is the order that prevents that, with what each step has to deliver before you move on.
A data migration is the controlled move of records, documents and the links between them to another system, including the proof that everything arrived complete. That last part is the whole story. Anyone can copy data. Demonstrating that you lost nothing is the work.
In practice three things go wrong, and none of them are technical. Nobody counted up front, so afterwards nobody can say whether it adds up. The export turned out to be more limited than expected, and that only surfaced after notice had been given. And the history was put out of scope to save time.
The EU Data Act has applied since September 12, 2025, and it shifts the second point from hoping your vendor cooperates to requiring that they do. More on that at step two.
Delivers a list of sources with a choice (move, archive or lapse) and an owner for each.
Delivers a written export specification plus a real test export that you have opened.
Delivers a baseline count with a date and time, which you can run again verbatim afterwards.
Delivers a mapping document in which every source field has a destination or an explicit decision.
Delivers an exception report stating what you will do with each item, after the people who work with the data daily have checked their own records.
Delivers a runbook with times, owners and an explicit fallback moment.
Delivers a verification report with the counts before and after, and an explanation for every difference.
Do not start with the system you are replacing, but with the places your business data actually lives. That is almost never just that package. There are mailboxes, a network drive, a SharePoint environment, and the spreadsheets where the real work happens because the system could not handle it.
Make three choices per source: move, archive or lapse. Write it down and have someone with subject matter responsibility sign off, so that "surely that should have come along too" is a decision and not an argument halfway through.
If it is an ERP, that choice is harder than with a CRM: part of what you see on screen is not stored there but calculated. Which kinds of data those are and what you ask for per kind is in ERP migration: which data do you keep?
Deliverable: a list of sources with a choice and an owner for each.
This is the step most often skipped and the most expensive one to get wrong. Ask in writing for the full list of what you can take with you, and then for a test export.
You are in a stronger position than most business owners realise. The Data Act requires cloud service providers to include in the contract an exhaustive list of all categories of data and digital assets that are portable when you switch, including what is excluded. Time limits apply too: a notice period of at most two months to start a switch, in principle at most thirty calendar days to transfer your data, and at least another thirty days to retrieve your export. Your vendor also has to cooperate in good faith, including with the provider you are moving to.
In practice: request that list before you give notice, and test the export before the clock starts. What is missing is a negotiating point while you are still a customer, and a problem the moment you are not. Also count on responses getting slower as your contract runs out. We covered the cost side of the same law earlier in Data Act: from 2027, switching can't cost you anything.
Deliverable: a written export specification plus a real test export that you have opened.
A baseline count is the dullest part of a migration and the only thing that saves you afterwards. Count records per table, files per folder and per file type, and alongside that record a few substantive control totals: the total outstanding balance, the number of active customers, the number of orders in the current year.
Those control totals matter more than the counts. Counts can add up while the content has shifted, for example because a wrong separator moved amounts by a factor of a hundred. A total that matches to the cent rules that out in one go.
Nobody counted up front, so afterwards nobody can say whether it adds up.
Records per table, files per folder and per file type, plus a few control totals, run verbatim before and after.
Deliverable: a baseline count with a date and time, which you can run again verbatim afterwards.
Only now does the new system come into view. Record for every field where it goes, how the value is converted and what happens when it is empty or does not fit. Free text fields and pick lists are the familiar stumbling blocks: ten years of homegrown status values rarely map one to one onto a new model.
Pay particular attention to the link between records and files: most exports produce those separately, and a quote that no longer hangs off its customer is technically present and practically gone. This is also the moment to clean up. Merging duplicate customers costs almost nothing extra during the move and is a separate project afterwards.
Deliverable: a mapping document in which every source field has a destination or an explicit decision.
Run the full migration once on a copy, with the same scripts and the same order as the real thing. Not a sample, but everything. Only at full scale does what stays hidden at a hundred records come out: the 2014 record with an odd character set, the 900 megabyte attachment, the customer that exists twice.
Then have the people who work with it daily check their own records. The salesperson who looks up their ten largest customers finds in ten minutes what a technical check would never have caught. Repeat until the exception list is empty or every remaining item has been consciously accepted.
Deliverable: an exception report stating what you will do with each item.
The real migration is short and boring if the trial went well. Pick a window in which nothing changes in the old system, usually an evening or a weekend, and move only what has been added since the trial. The shorter that window, the less your organisation notices.
Agree two things in advance that nobody enjoys discussing: when do you fall back to the old system, and who makes that call. A fallback plan you never use is worth an hour of preparation.
Deliverable: a runbook with times, owners and an explicit fallback moment.
Run the baseline count from step three again verbatim, now on the new system, and put the results side by side. Differences are fine as long as you can explain them: twenty-four records fewer because you merged twenty-four duplicate customers is a good answer. Differences nobody can explain are the only real alarm signal.
Keep the old system readable until the first full month-end close has gone well. Only then do the forgotten corners surface: the export for the accountant, the list that is used just once a month. Give notice after that month, not the moment it is technically done.
Deliverable: a verification report with the counts before and after, and an explanation for every difference.
History goes out of scope too easily. Notes, activities and email history feel like ballast and are the first to go when the schedule gets tight. But it is exactly the layer that gives your customer picture its value, and the layer you need the moment you want to do anything with AI on your own data.
What stands out when you read the seven steps back: five are about recording, counting and verifying, and only two about actually moving anything. That is no accident. The move itself is largely automatable, the proof that nothing is missing is not.
That leaves the question of where you are migrating to. From one closed package to another means you will need this same plan again in five years. Put your data in an in-house data layer and connect your software to it, and the next system change is no longer a migration but an integration. That is covered on the AI Native Data Layer page, our own approach on data migration without data loss, and the reason to start on five signs your business has outgrown its CRM.
The controlled move of records, documents and the relationships between them to another system, including the evidence that everything arrived complete. That last part is the actual work: anyone can copy data, proving you have lost nothing is where a migration succeeds or stalls.
Not the system you are replacing, but the question of where your business data actually lives. That is almost never just that one package: there are mailboxes, a network drive, a SharePoint environment and the Excel files where the real work happens because the system could not. Make a choice per source (move, archive or drop) and have someone with subject-matter responsibility sign off on it.
In practice for three reasons, and none of them is technical. Nothing was counted beforehand, so afterwards nobody can say whether it adds up. The export turned out to be more limited than assumed, and that only surfaced after notice had been given. And history was pushed out of scope to save time.
The complete written list of what you can take with you, and then a real test export that you have opened yourself. The Data Act obliges cloud providers to include in the contract an exhaustive list of all categories of data and digital assets that are transferable when switching, including what is excluded. Request that list before you give notice: whatever is missing is a negotiating point while you are still a customer, and a problem once you are not.
By taking a baseline count with a date and time before the migration, and running that exact same count again afterwards. The verification report puts the before and after counts side by side and gives an explanation for every difference. Without a count beforehand there is no evidence afterwards, only a feeling.
In the free migration scan we walk through steps one to three with you: which systems and sources there are, what you can actually get out of them and where the risks sit. You get a concrete migration plan, even if you go on with another party.
Request the migration scan