Data migration strategy: the decision that is not the cutover

Ask a programme what its migration strategy is and you will be told big bang, or phased, or trickle. That is a cutover strategy. It answers when the old system stops and the new one starts, and it is a real question.

It is not the decision that determines what you live with afterwards.

That one is asked much earlier, usually implicitly, often by a developer under time pressure rather than in a workshop: do we carry the source data model into the target, or do we rebuild the data for the target model? It gets decided field by field, quietly, and by the time anyone names it the answer is already half implemented.

The cutover strategy affects one weekend. This one affects ten years.

The two answers, stated honestly

Carry the structure across. Reproduce the source’s organisation in the target as closely as the target permits. Custom fields where the source had custom fields, the same code lists, the same granularity. The target is configured to accept what you already have.

Rebuild for the target. Take the target’s native model as given, and reshape the source data into it. Codes get remapped to the target’s standard, granularity changes where the models differ, and anything the target has no concept of has to go somewhere or go away.

Nobody chooses purely. Everyone ends up mixed. The failure is not the mixture, it is the mixture happening by accident.

Carrying the structure: what you save and what you inherit

The attraction is real and should not be dismissed. Users recognise their data. Reports still work. Training is shorter because the screens show what people expect. Above all, the migration itself is cheaper: fewer transformation rules, less arbitration, fewer decisions to escalate.

What you inherit is less visible at the time:

• The workarounds come with the data. The field used for something other than its name, the status code whose meaning changed in 2016, the numbering scheme that ran out of digits in 2019. You are not migrating data, you are migrating twenty years of accumulated compromise, and it becomes the new system’s baseline.
• You pay for the target twice. Standard functionality that assumes the standard model does not work on your custom shape, so it gets customised. Each customisation is a permanent maintenance cost and a permanent upgrade obstacle.
• The decision becomes irreversible. Rebuilding later means a second migration, on a live system, with more data than you have now. Almost nobody does it. The structure you carry across is the structure you keep.

Rebuilding: the cost is real and arrives early

Rebuilding gets you a system that works the way the vendor intended, with standard processes that need no adaptation and an upgrade path that stays open.

The bill arrives during the project, all of it, and it lands on the part of the plan least able to absorb it:

• Arbitration volume rises sharply. Every code that has no equivalent, every granularity change, every merged concept becomes a business decision. This is the workstream whose duration you do not control, and it is what moves the date.
• Users lose their landmarks. Data that looks unfamiliar generates resistance during acceptance testing, which is exactly when you need the business engaged and cooperative.
• History becomes harder. Reshaping current data is tractable. Reshaping ten years of history into a model it was never built for is often not worth it, and that pushes you towards an archive, which is a separate decision people would rather not make.

The hybrid, and why it usually goes wrong

In practice everyone lands somewhere in the middle: standard model where it is easy, source structure where it is expensive. That is a legitimate position, and it becomes a problem for one reason.

It is rarely decided. It is accumulated.

Field by field, under schedule pressure, whoever is writing the rule that afternoon takes the cheaper option. Six months later the model is a patchwork nobody designed, where two similar objects follow different logics because they were built in different weeks by different people. The system is not standard, so upgrades hurt. It is not consistent with the source either, so reports need rework. It has the costs of both approaches and the benefits of neither.

The fix is not to forbid hybrids. It is to make the split explicit and written:

Master data follows the target model without exception. Open transactional data carries the source structure to preserve continuity. History is archived, not migrated. Any deviation requires a named decision.

Written like that, the rule is checkable and a developer at 6pm knows which side of it they are on. Unwritten, the same intention produces the patchwork.

How the audit settles it

The reason this decision cannot be made at kickoff is that it depends on facts nobody has yet. The data audit produces exactly the three numbers that settle it:

• How much of the source is standard-compatible already. If 80% of your material master maps cleanly to the target model, rebuilding is far cheaper than it looked, because the cost sits in the remaining 20%.
• How much arbitration each option generates. Rebuilding always generates more. The audit tells you how much more, in decisions, and your business partners tell you their weekly rate. Multiply. If the answer exceeds the schedule, you have your constraint, and it is arithmetic rather than opinion.
• How much of the source structure is genuinely used. Custom fields that are 97% empty are not a business requirement, they are residue. Carrying them across because “the business needs them” is a claim the audit can test in an afternoon.

A programme that commits to a strategy before the audit is committing to assumptions about all three. That is how a hybrid gets accumulated instead of chosen.

Cutover strategy comes after, not before

The sequence matters, and it is usually run backwards.

The data strategy constrains the cutover strategy, not the other way round. Rebuilding generates a large arbitration queue, which takes months of part-time business work, which makes a long preparation phase unavoidable and a phased cutover more attractive because it lets you finish one domain while another is still deciding. Carrying the structure across shortens preparation and makes a big bang more plausible.

Deciding the cutover first, then discovering that the data strategy it implies does not fit the calendar, is the standard way programmes end up renegotiating in month six. The comparison of the three cutover approaches, once you know which data strategy you are on, is in the ERP data migration guide.

The question to put on the table

Before any date is committed, one question, answered in writing, per data family:

Does this data enter the target in the target’s shape, or in ours? If ours, what does that cost us in customisation, and who accepted that cost?

The second half is what makes it a decision rather than a preference. Carrying the source structure across is often the right call, and it is only defensible when someone has priced the customisation it implies and agreed to pay it for the life of the system.

An answer of “we will see during the build” is not a strategy. It is a hybrid, accumulating.