Every new-system project has a date nobody questions out loud — and a phase that usually pushes that date. It is not development, not integration testing, not training. It is data conversion: taking what exists in the old system and putting it into the new one in a shape the business recognises as its own.

It is the most underestimated phase because it looks mechanical. Extract, transform, load. In practice, every column carries a business decision nobody documented across twenty years of operation, and most of those decisions only surface when the load fails — or worse, when it succeeds and the number comes out different. AI has changed the economics of this phase, but it changed where you can save time, not where you can outsource accountability.

Conversion is not a technical task: it is a queue of decisions

When conversion slips, the quick diagnosis is always the same: “extraction is slow” or “the tool is bad”. It almost never is. What stalls the phase is the queue of questions nobody can answer alone.

What is the correct balance for an item that appears in three places with three different values? Is that customer registered four times under slightly different spellings one customer or four? A document opened in 2011, untouched since 2014 and never cleared — does it go? The free-text field where the team started writing the salesperson code eight years ago becomes what in the new model?

None of these questions is technical. All of them depend on someone in the business with the authority to decide and own the outcome. That is why the first deliverable of a well-run conversion is not a script: it is the list of open decisions, with an owner and a date. Until that list closes, every load is provisional.

What actually goes: scope is the first saving

The question that saves the most money in conversion is also the least popular: what does not go.

The project reflex is to take everything — “to be safe”. But converted history is not free history: it has to be mapped, cleansed, loaded, validated and then maintained. Each extra year of history multiplies the effort across all five steps and, on top of that, fattens the new database from day one.

An honest scope usually has three layers. Master data goes in full, but cleansed — customers, vendors, materials, chart of accounts, cost centres. Balances go as the cut-off position, not movement by movement. Historical transactions go only where there is a legal obligation or real operational use; the rest stays queryable in the old environment or goes to archiving. It is exactly the same discipline as archiving and data volume management: deciding what deserves to sit in the hot database.

Once the business understands that “not converting” is not “losing”, scope drops — and the whole phase shrinks with it.

AI-assisted mapping: a proposal, never a verdict

The mapping document — source field, target field, transformation rule — is the heart of the conversion and, historically, weeks of spreadsheet work. This is where AI changes the arithmetic.

Given the source schema, the target documentation and a real data sample, an assistant returns in hours what used to take weeks: a field-by-field mapping proposal, a justification for each choice, the transformation script, a list of values that fit no target domain, and the matching validation queries. The gain is not writing faster — it is reviewing instead of drafting. Reading and correcting a thousand lines of proposal is far cheaper than producing them from scratch.

Three uses pay off especially well. Value domains: the assistant reads the distinct values of a free-text field and proposes the classification, revealing along the way what was being used off-standard. Deduplication: instead of exact matching, similarity across name, address and tax ID, with a score — AI suggests the clusters, the business confirms them. Post-load anomalies: flagging what came out statistically odd relative to the source, which is exactly where conversion errors hide best.

Cleansing happens at the source — and beforehand

There is a strong temptation to cleanse during the load, with rules inside the transformation script. It works on the first cycle and charges interest later: the rule lives only in the conversion code, nobody in the business can see it, and when data lands wrong in the target the argument becomes about the rule instead of about the data.

Cleansing at the source is slower at the start and far cheaper at the end. The duplicate record is resolved by whoever owns it, with the decision recorded where the business can see it; the unclassified item is classified by whoever knows how to classify. Conversion then loads data that is already good — and validation starts measuring the load rather than the cleanup.

A practical rule: if the fix requires business knowledge, it belongs at the source. If it is purely format — dates, decimal separators, character encoding, field length — it can belong to the transformation.

Validate in layers, cheapest first

Conversion without reconciliation is a bet with a date on it. Three layers, in this order, cover almost everything.

1. Counts — records per object, source against target, with every difference explained. Cheap, runs on every cycle, and catches partial loads and reprocessing duplicates.
2. Totals the business recognises — balance per account, stock per warehouse, open items per customer. This is the layer that matters: if the controller does not recognise the number, the conversion is not ready, however neatly the counts tie out.
3. Sampling aimed at the edges — the largest value, the oldest record, the one with the most decimal places, the one with accented characters, the one with a null field, the record nobody understands. Conversion errors live in the exceptions, not in the average.

Every load cycle has to end with that report signed off. Without it, the team discovers the problem at the first period close after go-live, which is the worst possible place to discover it.

Load cycles: rehearse before it counts

A conversion that runs exactly once, at cutover, is a gamble. The pattern that works is the opposite: several full cycles before the real date, each with wider scope and more business people looking at the result.

The first cycle measures mechanics — duration, dependency order between objects, what breaks. The second measures quality, with the business genuinely reconciling. The third is a timed cutover rehearsal: it starts and finishes inside the window, with the same people and the same runbook that will run on the day. If the third cycle does not fit the window, the problem is the schedule — and that is a far better discovery to make three weeks out than at three in the morning on go-live night.

Each cycle also improves the source: whatever validation rejects comes back as a cleansing task. That is why starting early pays off even with incomplete scope — the value is in the correction loop, not in the load itself. It is the same discipline that keeps an SAP implementation free of surprises.

What survives go-live

When conversion is done well, three things outlive the project and keep paying.

Traceability: for every converted record, you can say where it came from and which rule transformed it. That answers audits and settles the “this number is wrong” argument in minutes instead of the weeks it takes without a trail.

Quality rules: whatever conversion validation tested becomes a permanent check. The new database is born with its quality criteria already defined, rather than degrading quietly until the next migration.

And documented decisions: what was left out, why, and where to look it up. A year later, when somebody asks about a document from 2013, the answer exists.

The honest limit: AI has not converted anything on its own in any project we have run. It read schemas, proposed mappings, generated scripts and queries, clustered duplicates by similarity and flagged anomalies after the load. The expensive decisions — what counts as a duplicate, what may be rounded, what does not need to go — remained with people who answer for the data. What changed is that those people now spend their time deciding instead of typing into spreadsheets.

To prepare for this phase, two pieces from the Inove Academy help before you start. The quick guide on cloud migration asks the same question at a different scale — what goes as it is and what deserves a redesign before it crosses. And the implementation e-book shows why most project problems are not technical, with data conversion as the recurring example.