ERP data migration: plan cutover and prove the opening state

What belongs in the migration rather than the archive?

Separate the data needed for day-one operations from historical material that needs an appropriate access plan.

Microsoft distinguishes configuration data from migrated master data and open transactions. Examples include products, customers, open orders, stock on hand and open balances. Use that distinction to inventory your scope; the supported transfer mechanism remains specific to the ERP you choose.

Reference: Microsoft Learn: data migration for Dynamics 365 projects

Ask what the new system must do with each data class on its first operating day. An unfinished sales order needs valid product and customer relationships; a completed historical report may serve a different purpose. Do not move every old record simply because it can be exported. Also decide how authorised staff will retrieve older evidence they still need.

Record a decision for each class: migrate, clean first, retain separately with access, or dispose of only under an agreed retention decision. This is not a general instruction to delete business history. Establish your actual operational and legal requirements, then make those decisions visible to the migration team.

Design the store-to-ERP connection that will run after cutover

How can a successful import still produce the wrong records?

A valid file transfer does not establish correct identities, units or relationships.

Dynamics data entities provide a vendor-specific example of mapping source fields to target fields. The mapping mechanism can validate structure, but your team still needs to confirm that the imported records mean what the business expects.

Reference: Microsoft Learn: data entities and field mapping

Create a crosswalk with old identifier, target identifier, meaning and transformation rule. Check leading zeros, case, currency, units and time context. A pack and a single item can share a plausible description while requiring different stock quantities. A silent conversion can make an otherwise clean import operationally wrong.

Resolve duplicates through an approved decision rather than similar names alone. Then test relationships: an order should refer to the intended customer and exact sellable variant. Retain the crosswalk after launch so staff can find an old order reference without guessing. Counts of loaded rows cannot prove those relationships.

Define product attributes and variants before migration

How should partially completed orders be carried over?

Migrate the remaining business obligation with an explicit account of work already accepted elsewhere.

Distinguish ordered, paid, reserved, released to a warehouse, shipped and refunded quantities. These states can differ within a single order. Decide which remaining lines the new ERP should process and which activities continue under the old route. A single order-level status is often insufficient for that handover.

Agree whether opening inventory means physical, reserved or available units. Importing a net available quantity and then subtracting the same reservations again understates availability. Importing physical stock while forgetting outstanding commitments can overstate it. Write the expected arithmetic down before choosing import fields.

Keep store, warehouse and payment references attached to the relevant records. Recreating an ERP order must not automatically release warehouse work that was already accepted. Include late cancellations and returns against pre-cutover orders. Staff need a clear owner for every process split across the transition.

How do you control changes after the initial extract?

Define the writing boundary and the route for later changes before loading the opening data.

Microsoft’s cutover guidance calls for sequenced tasks, owners, verification, rehearsal and a rollback plan. Apply that structure to your operating window rather than assuming a standard weekend duration will fit every migration.

Reference: Microsoft Learn: cutover strategy and rehearsal

Document the extract’s business timestamp, how later changes are captured and when the old writing path stops. Include updates to records already exported and deliberate removals. A second unqualified file import can undo corrections or miss changes instead of producing a clean delta.

Distinguish abandoning an import before launch from returning to the old ERP after new transactions exist. Name who can pause the process, what evidence triggers that decision and how changes made in the target would be preserved or reconciled. A backup is useful recovery material; it is not the full operating decision.

What evidence establishes that migrated data is usable?

Reconcile quantities, balances and relationships, then run real work from the agreed opening state.

Microsoft describes data acceptance testing in terms of correct target data that is usable in operations. Include business users completing representative work, rather than relying only on import success messages.

Reference: Microsoft Learn: implementation test types

Use an agreed frozen comparison point. A Monday source cannot be fairly compared with a target already receiving Tuesday orders. Record tolerances, rounding rules, explained exclusions and the person approving each result. Adapt the following editorial matrix to your own financial and operational definitions.

When has the migration rehearsal actually passed?

The team must complete, verify and safely stop the planned sequence within the available operating window.

Use a representative data volume and the intended tools. Measure extract, cleanup, transfer, import, error correction and business validation separately. An import that fits the window is not enough if the checking work has been omitted from the schedule.

Ask the people who will own cutover to follow the runbook. Include an intentionally invalid record and show how it is corrected and reprocessed without blindly repeating all work. Keep the defect log and update the sequence after rehearsal. A successful consultant demonstration is not yet an operable handover.

At the actual cutover, responsible business owners approve the opening state and documented exceptions again. Assign early-life monitoring and a clear end to parallel operation. Rehearsal improves the plan, but it cannot establish that a later, changed set of production data is correct.