Migrating to an AI-native ERP — the data problem nobody solved

Every part of an ERP project got faster except one.

Building is minutes. Configuring is a conversation. Reporting is a question. And then you hit data migration, and it takes as long as it ever did, because the work is not technical — it is a long series of small judgements only your team can make.

This is the most under-quoted line in every proposal you will read, ours included. Here is the honest version.

Why AI does not fix this

It seems like it should. Reading messy records and mapping them to a clean structure is exactly the pattern-matching AI is good at, and to be fair, it does help with a chunk of it.

The problem is that the hard part is not recognising the mess. It is deciding what the mess means, and that information does not exist in the data.

Three examples from real migrations:

• Three customer records for the same company. AI spots the likely duplicates in seconds — that part is genuinely solved. But which is the real one? One has the correct address and stale contact. One has the right contact and wrong terms. One has all the transaction history. Merging them requires knowing that the terms on record two were superseded verbally in 2023, which is in someone's head.

• A notes field holding a decade of payment terms. Free text. "45 days as agreed w/ KL branch", "COD after the 2019 thing", "usual". AI extracts structure from most of it. It cannot tell you what "the 2019 thing" was, and that one is your credit policy for a customer who still owes you money.

• Product codes that changed meaning in 2018. SKU A-1120 was one thing until March 2018 and something else after. No field records this. Your historical sales analysis is silently wrong unless someone who was there flags it. AI cannot detect the absence of information it was never given.

The pattern: AI handles the mechanical mess. What is left is institutional knowledge, and it does not live in the database. It lives in people, and getting it out of them takes conversations, not compute.

The mistake that stalls projects

Almost everyone does this: treat migration as Phase 1.

It is intuitive. Get the data in, then build on it. Every traditional methodology said so, because in the old world you had to — the system needed a data model populated before it did anything.

It is the single most reliable way to kill momentum.

You spend eleven weeks cleaning records nobody has looked at since 2019, for processes you have not built yet, with no user seeing any benefit. Enthusiasm — which is finite and is your actual scarce resource — drains completely. By the time you build anything, the sponsor has stopped attending the meetings.

Worse, you are cleaning blind. You do not yet know which fields matter, because you have not used the system. So you clean everything to the same standard, which means you over-invest in data nobody will touch and under-invest in the fields that turn out to be load-bearing.

The alternative: migrate on demand

Invert it. Do not migrate data until a live process needs it.

Build the process first. Run it on new transactions. Then pull in exactly the history that process actually requires — and no more.

Concretely, for a distributor:

• Build the sales-order workflow. Run it on new orders from Monday.
• It needs current customers, not historical ones. Migrate the ~200 customers who ordered in the last 18 months. Leave the other 1,400 alone.
• It needs the current product list. Not the 2018 codes.
• Historical sales stay where they are, read-only, until something needs them. Often nothing does — and if reporting eventually needs three years of history, migrate it then, when you know exactly which fields the report uses.

Two things happen. You get value in week two instead of month four. And you clean data with knowledge of what it is for, which is faster and produces a better result.

The objection is real: you now have data in two places for a while. Yes. That is a genuine cost and it needs managing — one system is the source of truth for each thing, and everyone knows which. It is a smaller cost than a dead project, and it is temporary.

What actually has to move

Sort your data into four buckets. The proportions surprise people.

Live operational data. Open orders, current stock, active customers, unpaid invoices. This must move, must be right, and is a much smaller pile than you think.

Reference data. Products, price lists, suppliers, the chart of accounts. Must move, mostly clean already, moderate effort.

History you will actually use. Enough sales history for seasonality, enough purchase history to check a supplier. Usually two to three years, not fifteen. Move it when a process needs it, not up front.

Archive. Everything else. Records from a business that no longer exists in this form. It does not need to be in the new system. It needs to be accessible — which is a very different requirement, met by keeping the old system read-only, or a database export in cold storage.

The most expensive mistake in migration is treating bucket four like bucket one. People migrate fifteen years of records because it feels irresponsible not to, then never open them.

The conversations you cannot skip

The migration will surface things nobody wants to discuss. This is not a bug — it is the most valuable output.

"Which of these is the real customer?" forces someone to own the customer master. Usually nobody does, which is why there are three.

"What are this customer's actual payment terms?" produces disagreement between sales and finance. That disagreement has been costing you money invisibly for years. The migration is just when you finally see it.

"Do we still sell this?" reveals the 400 SKUs nobody has decided to kill.

Budget time for these. They are not overhead; they are the point. A migration is the first time in years anyone has looked at what the business actually thinks is true, and it turns out the business does not agree with itself.

Which is also why migration cannot be delegated to a vendor. We can move the data. We cannot tell you which customer record is real, and any vendor who says they can is going to guess.

A realistic plan

1. Pick one process. The painful one.
2. Build it. Days.
3. Identify the minimum data it needs to run. Almost always less than you assumed.
4. Clean and move only that. With a named person from the business who can settle the judgement calls in real time — not by email over three weeks.
5. Go live on new transactions. Old data stays where it is.
6. Backfill history only when something needs it. Frequently: never.
7. Repeat for the next process.

No big-bang cutover. No Phase 1 data project. No eleven weeks before anyone sees anything.

Common questions

Does AI make ERP data migration faster?

Only partly. AI handles the mechanical mess well — it spots likely duplicate customer records in seconds and pulls structure out of a decade of free-text notes. What it cannot do is decide what the mess means, because that information is not in the data. Which of three customer records is the real one, or what a note like "COD after the 2019 thing" refers to, lives in someone's head, and getting it out takes conversations rather than compute.

Should we clean and move all our data before going live?

No, and treating migration as Phase 1 is the most reliable way to kill a project. You spend weeks cleaning records nobody has looked at in years, for processes you have not built yet, while no user sees any benefit and enthusiasm drains. You are also cleaning blind, because you do not yet know which fields matter. Build the process, run it on new transactions, then migrate exactly the history it needs.

How much history do we actually have to move?

Less than it feels. Live operational data — open orders, current stock, active customers, unpaid invoices — must move and is a smaller pile than people expect. Reference data such as products, price lists and the chart of accounts must move too, and is usually fairly clean. History you will genuinely use is a few years, not fifteen, and it can wait until a process needs it. The rest needs to be accessible, not migrated.

Can we hand the migration to the vendor?

Not the part that matters. A vendor can move data; they cannot tell you which customer record is real, what a customer's actual payment terms are, or that a product code changed meaning years ago with no field recording it — and one who says they can is going to guess. Those calls need a named person from the business who can settle them in real time, not by email over three weeks.

The honest bottom line

If a vendor quotes you six weeks, they are quoting the build. Ask what happens to your data. If the answer is confident and quick, they have not done this — or they intend to move it verbatim, mess and all, which produces a fast migration and a system nobody trusts. That is worse than a slow one.

The build got fast. The data did not. Any plan pretending otherwise fails in month two, and it fails quietly: the software works fine and nobody uses it, because the numbers in it are wrong and everyone knows it.

We sell developer time by the day partly for this reason. Migration is where the genuinely hard work concentrates now, and it is honest to price it as work rather than bury it in an implementation fee.

Related: the death of the 18-month ERP implementation for which parts collapsed, and what AI still cannot do in ERP.

Also worth reading: how to evaluate an AI ERP vendor.