Decide what belongs in the new system.
A migration begins with a business decision about information. Which master records are required to operate? Which open transactions must continue? How will historical information remain available for reporting, customer service or audit? Moving everything can import years of inconsistency; moving too little can leave the business dependent on a system it expected to retire.
We separate those data sets before planning the load. Open invoices, for example, must still support collection and allocation after cutover; old closed transactions may be needed only for reference. That distinction changes the mapping, testing and reconciliation effort, as well as the systems you can retire.
Build a migration specification people can review.
| Migration decision | What to specify |
|---|---|
| Mapping and meaning | Define how source fields become target records, values and relationships. Document transformations, defaults and identifiers, especially where a familiar field means something different in the new process. |
| Quality and ownership | Agree how duplicates, incomplete records and inconsistent values will be handled. Give each unresolved exception an owner. A technical load cannot decide which supplier address or customer record is correct. |
| Reconciliation and acceptance | Specify the totals, counts, relationships and samples needed to prove completeness. Business owners should understand both the results and the explanations for legitimate differences. |
Rehearse the move before the final load.
- 01
Profile
Inspect representative extracts and identify missing values, unusual structures and dependencies. Establish how source changes will be tracked while preparation continues.
- 02
Prepare
Clean and map the data through a repeatable process. Preserve the decisions behind transformations so another team member can reproduce and review them.
- 03
Trial load
Load an appropriate test environment, investigate rejected records and check downstream behavior. Test a transaction using migrated data rather than validating records only in isolation.
- 04
Reconcile and cut over
Compare agreed control totals, obtain acceptance and rehearse the final sequence. Define data freezes, delta handling, fallback conditions and responsibility for each cutover step.
A loaded record still needs to work.
A customer can import successfully yet belong to the wrong subsidiary. An item can exist while using the wrong purchasing unit. Our migration review follows representative records into transactions, so a technically successful load is checked against the work it must support.
For receivables, an illustrative reconciliation compares open invoices and credits by customer, currency and due date, then explains differences against the agreed control totals. The finance owner accepts that opening position. Rejected records and later source changes stay visible through the final load.