Identify datasets and their owners
Begin with a data inventory. Record the source, object, volume, export method, responsible person and intended use. A data object might be a customer, an order or an individual order item. Document the identifiers that connect these objects.
| Dataset | Decision to make | Example business check |
|---|---|---|
| Master data | Which customers, suppliers or services will still be needed? | An order item references the correct service |
| Open transactions | What must remain actionable after the switch? | A partially completed order retains its remaining scope |
| Configuration | Which values give business records their meaning? | Units, statuses and currencies are correctly assigned |
| History and documents | What is needed in the target system or elsewhere? | An older supporting record can still be found through its reference |
The distinction between configuration data, master data and open transactions is also used in Microsoft’s data migration guidance. Your inventory must reflect the specific source and target systems.
Decide what to migrate, archive or clean
Not every historical record needs to be loaded into the operational target system. Equally, history should not be deleted as a blanket rule. Decide for each dataset whether it is needed for daily work, evidence or reporting, and how it will be accessed later. Relevant specialists should review retention, deletion and access requirements.
Document exclusions with a reason and an owner. Before cleaning a record, establish whether it is unused or still referenced by an open order, for example. Protect test exports and limit access to people who need them for the migration.
Map fields and open transactions
Mapping defines how information will be represented in the target system. Identical field names do not guarantee identical meaning. “Status” might describe a processing stage in the old system and an approval in the new one. Numerical fields require consistent units, decimal precision and signs.
A mapping entry needs a source field, target field, transformation rule, required-field status, error handling and business owner. Relationships also require a mapping between old and new identifiers. A new order number must not break the connection to its customer, items or documents.
- Source
- Order A-17 · Customer K-04 · Remaining quantity 3 · Unit: hours
- Mapping rule
- Resolve the customer identifier through a reference table. Transfer the open quantity only.
- Target and check
- Order A-17 → Customer K-04 · 3 hours open. Open the linked delivery record.
Define import order from these dependencies. An order can only reference its customer when the required mapping exists. A missing required value should not be replaced with arbitrary information. Record the exception for review and decide whether to complete, defer or explicitly exclude it.
Reconcile a trial migration with business checks
A technically successful import does not establish that the transfer is correct. Plan a trial using representative data and relevant exceptions. These may include cancelled items, partial invoices, empty optional fields, special characters and changed customer relationships.
First compare counts and totals on the same basis. Comparing all old orders with only open new orders will necessarily produce a difference. Record filters, cut-off date, unit and approved exclusions. Add business samples: Can an imported transaction be processed correctly? Are its supporting records accessible? Do the intended permissions apply?
Resolve differences explicitly
In this illustrative example, the approved export contains 120 open service items. The target contains 119. The difference needs an explanation before the run can be approved. An intentionally consolidated item may be valid; a lost item is an error. The number alone cannot tell you which occurred.
Repeat corrected imports in a controlled test environment. Record the mapping version and source snapshot used. Also test repetition: reimporting a dataset should not silently create additional transactions. How this is achieved depends on the import mechanism.
Plan the cut-off and final changes
Cutover is the planned transition to the new environment. Data may continue to change in the old system until then. Decide whether you can use a sufficient window with no writes or how changes since the previous export will be captured. This includes new, changed and, where relevant, deleted records.
A phased transition can be appropriate, but it needs explicit boundaries: Which company, process or dataset is already governed by the new system? Parallel operation without clear data ownership creates further reconciliation problems. Dependencies and operational requirements determine the suitable approach.
- PrepareTests passed · recovery checked · owners available
- Control changesWrite freeze or documented change capture active
- Import and reconcileCheck the final snapshot and open transactions
- Decide on launchApprove or follow the agreed fallback plan
Assign an owner, deputy and completion evidence to each cutover task. Rehearse the sequence in a suitable environment. Microsoft’s cutover guidance covers task order, approvals, rehearsal and rollback; the checklist here applies those planning principles independently of a particular ERP supplier.
Decide abort and fallback rules in advance
Rollback requires more than an available backup. Establish how long fallback remains possible, who can trigger it and how the old system becomes authoritative again. This includes a tested restoration procedure and explicit treatment of data created since the last safe state.
The boundary after enabling writes is particularly important. If orders have already changed or documents have been created in the new system, simply switching on the old one is insufficient. Those transactions must be accounted for during fallback. If that cannot be done reliably, a planned correction in the target may be the more suitable option. Make that decision during preparation.
Define concrete abort criteria, such as unexplained differences in critical datasets or inability to run an essential process. Business owners and project leadership should jointly decide which remaining issues, if any, are acceptable.
Check records and balances after the switch
After launch, check the first real transactions and downstream handovers. Are totals plausible? Do exports and interfaces work? Can errors be assigned to an owner? A named support channel helps the team report issues consistently.
Retire the old system only after evidence access, remaining tasks and ongoing retrieval needs have been resolved. Record business approval of the migration separately from future improvement requests. Maintain those requirements in an ERP specification so that they do not silently expand the agreed migration scope.
Use the mapping and reconciliation templates
Download the mapping and reconciliation CSV
Download the cutover plan as Markdown
The CSV contains labelled examples and blank rows for your own mapping and reconciliation decisions. It uses semicolons and UTF-8. The Markdown template adds roles, cut-off, approval, fallback and post-launch checks. Replace the examples and have critical verification rules confirmed by the business owners.
If you are preparing migration as part of a custom ERP solution, a system inventory and a small anonymised data export are useful starting points. They help identify the data, relationships and unresolved decisions that determine the actual scope of work.