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 does not answer another question, which determines the shape of the data you live with afterwards.

That question needs to be asked before the rules are built. It is often settled implicitly instead, 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.

Cutover can fit into a short window or organise months of coexistence. The model choice shapes usage and maintenance throughout the system’s working life. Both decisions need to be explicit.

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.

In practice, the two are often combined. Trouble starts when that mixture happens by accident.

Carrying the structure: what you save and what you inherit

The attraction is real and should not be dismissed. Users recognise more of their data. Some reports and familiar conventions can be retained, reducing part of the training and transformation effort. That gain still needs to be checked in the target: keeping a source code guarantees neither a working report nor an equivalent process. Required adaptations can absorb the initial saving.

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.
• Adaptations have a bill. Where a custom shape prevents a standard function from working, the model or the function needs adapting. Those extensions require maintenance and checks during upgrades; their cost also depends on the extension mechanisms the target supports.
• The decision becomes costly to revisit. Rebuilding later can require a second migration on a live system, with more data and dependencies. It is not irreversible, but that cost needs comparing with rebuilding during the project.

Rebuilding: the cost is real and arrives early

Rebuilding brings the data closer to the vendor’s intended model. That can make standard functions easier to use and limit some adaptations. Configuration, interfaces, training and upgrade testing still need to be planned.

A substantial part of the bill arrives during the project, in workstreams the plan needs to make visible:

• Arbitration volume can rise sharply. Codes without equivalents, granularity changes, merged or split concepts need rules validated by the business. Cases those rules cannot settle enter the arbitration queue that needs planning, which can move 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 many programmes land somewhere in the middle: standard model where it is easy, source structure where it is expensive. That is a legitimate position. A frequent risk is how it takes shape.

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 programme can end up with both upgrade adaptations and reports to rework, without having chosen the benefits it expected from each approach.

Make the split explicit and written. For example, on a scope where these choices have been validated:

Master data follows the target model. Open transactions preserve the information needed for continuity, with references, units and statuses compatible with the target. History selected for archiving remains accessible outside the operational system. Any deviation requires a named decision.

This policy needs mappings and acceptance criteria for each family. It does not permit loading transactions in a source structure incompatible with target master data. Written this way, it gives the developer at 6pm a rule and an accountable person to refer to.

How the audit settles it

If this decision cannot be confirmed at kickoff, facts are missing. The data audit provides three measurements for comparing the options:

• How much of the source is standard-compatible already. If 80% of your material master maps cleanly to the target model, transformation effort concentrates on the remaining 20%. That helps cost it; interfaces, tests and rare cases still need assessing.
• How much arbitration each option generates. Compare both decision queues: rebuilding can add decisions, but retaining source peculiarities can require them too. Divide the decision count by the total weekly capacity agreed with the business to obtain a duration in weeks. Then check allocation by owner, dependencies and availability: the average does not clear a queue blocked with one decision-maker.
• How much of the source structure is actually used. A custom field that is 97% empty is a signal to investigate, not proof that it is useless. The populated 3% may serve an essential rare case. Check conditional usage, reports, interfaces and history before deciding to retain, archive or drop it.

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.

Data model and cutover are decided together

The cutover calendar cannot choose the data model on its own. The model cannot choose the cutover on its own either.

A large arbitration queue can lengthen preparation. Phased cutover only helps if the domains can operate separately during transition. Conversely, required availability, dependencies and the ability to coexist constrain data choices. AWS also bases cutover selection on business requirements and technical constraints, not just loading time.

The audit lets you compare those constraints and adjust both decisions before committing the date. The approaches and conditions for coexistence are compared 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.