Quick answer
Move the configuration, master data, opening balances and unfinished transactions needed to operate the new ERP. Assess completed transaction history separately rather than assuming it all belongs in the operational system. Microsoft distinguishes configuration from migrated master data and open transactions; SAP’s migration cockpit similarly focuses on the initial data needed to start operations. (learn.microsoft.com)
Recommended acceptance rule: approve the migration only after explaining differences between the agreed source data and the target, reconciling financial and inventory values, testing business workflows and obtaining named business-owner sign-off.
1. Separate the migration into four data categories
For planning, split the migration into four categories. Microsoft groups stock and open balances with open transactions, but tracking balances separately gives finance a clearer approval task. Its guidance identifies currencies and tax codes as configuration, and customers, products and vendors as master data. (learn.microsoft.com)
Use this planning worksheet:
| Category | Typical contents | Recommended scope decision |
|---|---|---|
| Configuration | Currencies, tax codes, posting rules, accounting dimensions and business parameters | Establish the approved target setup; do not copy legacy settings without review |
| Master data | Customers, suppliers, items and their required relationships | Include records needed for continuing operations and migrated transactions |
| Opening balances | General ledger balances, stock quantities and inventory values | Establish an agreed starting position at cutover |
| Open transactions | Unpaid invoices, unapplied payments, credit notes and unfinished orders | Preserve the outstanding obligation or remaining work through a supported migration method |
Check each target migration object before finalizing scope. For example, SAP S/4HANA Cloud Public Edition’s migration cockpit documentation distinguishes master data, open transactions and balances, and describes restrictions affecting orders with follow-on documents. Those restrictions should not be generalized to every ERP or migration method. (help.sap.com)
Start with two prerequisites: an approved target configuration and a defined cutover boundary. Without them, the team has no stable basis for mapping records or comparing balances.
2. Decide what belongs in the ERP and what belongs in an archive
For each dataset, ask:
- Does a user need it to complete a transaction after go-live?
- Does another migrated record depend on it?
- Is it needed only for historical lookup or reporting?
- Can the supported migration method preserve its meaning and relationships?
These questions turn “move everything” into a documented business decision. Microsoft’s data-management guidance likewise asks teams to identify how data is used, which use cases require it, where it is stored and whether access has a cost. (learn.microsoft.com)
A practical starting proposal is to:
- Migrate operationally necessary master records and outstanding transactions.
- Archive completed documents that are required for lookup but not continuing processing.
- Evaluate historical reporting balances separately from detailed transaction history.
- Exclude redundant staging files and unnecessary data only after authorized review.
Historical balances are not equivalent to historical documents. SAP documents a historical-balance migration object intended for reporting, while its migration cockpit guidance excludes completed historical transaction processes from the standard initial migration scope. (help.sap.com)
Do not use an arbitrary “last few years” rule without examining business needs. An older customer may still have an unpaid invoice; a recently closed order may belong only in historical access.
3. Assign owners and write acceptance rules before cleansing
Give every dataset a business owner, a technical migration owner and an approver. Microsoft identifies migration analysts, data stewards and migration architects or developers as distinct contributors; its governance guidance places cleansing responsibility with people familiar with the data. (learn.microsoft.com)
For a smaller organization, one person may fill several roles. Still, make the decisions explicit:
| Dataset | Suggested business owner | Suggested acceptance evidence |
|---|---|---|
| Customers and suppliers | Receivables or payables lead | Approved duplicate decisions, valid terms and correct relationships |
| Items and inventory | Inventory or operations lead | Quantities, locations, units and tracking details |
| Open invoices and balances | Finance lead | Agreed balances, aging and ledger reconciliation |
| Configuration | Relevant process owner | Approved settings and successful workflow tests |
Write measurable rules before the first load. Examples include “every unpaid invoice resolves to an approved customer” and “every excluded customer has a documented reason.”
For financial differences, define the approval process rather than hiding exceptions inside a tolerance. Any rounding allowance should specify its cause, calculation and approver. Treat unexplained differences as unresolved.
4. Clean and map data without losing its identity
Source and target structures can differ. Microsoft’s migration guidance calls for documented field and value mapping, transformation, testing and validation; its Dataverse guidance also highlights duplicates, incomplete data and relationship dependencies as migration challenges. (learn.microsoft.com)
Create a mapping register containing:
- Source field and target field.
- Data type, length and required status.
- Conversion, lookup or defaulting rule.
- Business owner and approval.
- Validation check.
- Treatment of missing or invalid values.
Retain a cross-reference between legacy and target identifiers. For example, map legacy customer C0042 to target customer CU-1042, then use that same approved mapping for its invoices and orders.
Recommended cleansing checks include duplicate candidates, blank required fields, invalid references, date formats and unit conversions. Do not merge customers solely because their names resemble each other. Have the business owner approve the identity decision and the treatment of dependent records.
Keep an exception log instead of silently substituting convenient defaults. A loaded record with the wrong payment terms is not a successful business outcome.
5. Run trial loads and rehearse the cutover boundary
Use trial loads to test the complete process, not just the import tool. Microsoft recommends repeated migration tests, addressing duplication and corruption, confirming that performance fits the cutover window, and obtaining business approval of cutover processes. (learn.microsoft.com)
For each rehearsal, preserve:
- The source extract and extraction time.
- Scope filters and mapping version.
- Import sequence and execution logs.
- Rejected records and corrective actions.
- Reconciliation results.
- Workflow-test evidence.
Follow the target’s documented dependencies rather than assuming a universal load order. Microsoft’s configuration guidance specifically calls for tracking sequence and dependencies. (learn.microsoft.com)
Define what happens to activity after extraction. Will posting stop, will approved changes be captured in a final incremental load, or will selected records require controlled dual maintenance? SAP notes that freeze periods or double maintenance may be necessary for some master data during cutover. (help.sap.com)
Also agree on a recovery decision: who can halt cutover, what evidence triggers that decision and how the team restores a known state. Have qualified implementation personnel document and test the product-specific procedure.
6. Reconcile counts, relationships, quantities and money
Use a reconciliation workbook that compares the approved source scope with the resulting target state. Include columns for expected result, actual result, difference, explanation, owner and approval.
Recommended checks are:
| Layer | Practical comparison |
|---|---|
| Completeness | Expected records versus loaded, rejected and deliberately excluded records |
| Identity | Legacy-to-target identifier cross-references |
| Relationships | Invoices linked to the correct customers; orders linked to valid items |
| Operational values | Inventory by item, location, unit and applicable tracking detail |
| Financial values | Open receivables/payables, inventory value and general ledger balances |
| Usability | Collection, payment, receipt and fulfillment scenarios using migrated data |
These are proposed project controls, not a claim that a particular ERP provides an automatic reconciliation report.
Compare like with like: the same company, cutoff, currency basis, posting status and filters. Record every approved transformation that changes the expected result.
Pay particular attention to double counting. Microsoft’s C5-to-Business Central migration documentation explicitly describes measures to avoid double-posting open transactions to the general ledger. SAP also warns that migrating closed documents can create postings already represented in balances. The accounting design must therefore be confirmed for the selected migration route—not improvised as a generic opening journal. (learn.microsoft.com)
7. Worked example: customers, inventory and unpaid invoices
The following example is entirely synthetic. All amounts are illustrative USD, with one company and no foreign-currency conversion.
Customer completeness
The agreed source scope contains 120 customer records:
- Four are confirmed duplicate records merged into four retained customers.
- Six are excluded after review because they have no continuing use or dependent open records.
- The expected target count is therefore 120 − 4 − 6 = 110.
If 110 customers load, the count check passes—but the team must still verify the cross-references and invoice relationships. Keep the ten scope decisions as evidence explaining why source and target counts differ.
Inventory
Synthetic item BOLT-01 has this approved starting position:
| Location | Quantity in eaches | Illustrative value per each | Expected value |
|---|---|---|---|
| A | 100 | $2 | $200 |
| B | 50 | $2 | $100 |
| Total | 150 | — | $300 |
A target containing 150 eaches entirely in Location A passes the total-quantity test but fails the location test. Compare both quantity and value at the agreed detail level.
This simplified example is not a costing-method instruction; use the selected ERP’s documented valuation and migration treatment.
Unpaid customer invoice
Synthetic invoice INV-1001 originally totaled $1,200. A $300 payment was applied before cutover:
Expected outstanding amount = $1,200 − $300 = $900.
A second unpaid invoice contributes $600, giving expected open receivables of $1,500.
Check that the target preserves the correct customer, outstanding amount, currency, document reference and due date. The technical representation depends on the migration object. SAP’s migration material states that partially open items should carry the remaining quantities or values. (assets.cdn.sap.com)
Finance should then confirm that the target receivables detail totals $1,500 and that the corresponding general ledger position agrees under the approved migration accounting design—not an additional $1,500 posted twice.
8. Prove historical access and obtain business sign-off
Treat the archive as a deliverable with its own acceptance test. Before retiring the source system, ask a normal authorized user to retrieve a selected invoice, supporting document and relevant historical report.
Recommended archive checks include:
- Search by legacy customer, supplier and document identifiers.
- Readable documents and preserved relationships.
- Defined access permissions, ownership and support.
- Documented backup and recovery arrangements.
- Confirmed software dependencies and access costs.
- A retention and disposal policy reviewed by the appropriate specialists.
Microsoft identifies searchability, security, licensing, archival and access costs as data-management considerations. No universal retention period or continued legacy-access entitlement is established by the sources used here; confirm those requirements for your organization. (learn.microsoft.com)
For final approval, assemble the scope register, mapping version, load logs, reconciliations, exception decisions, workflow results and archive test.
Ask finance to approve financial balances, operations to approve stock and unfinished work, and the project’s accountable decision-maker to approve go-live. Microsoft’s go-live guidance calls for stakeholder sign-off, testing with migrated data and a cutover go/no-go checkpoint. (learn.microsoft.com)
The release decision should answer two questions: can the business continue correctly in the new ERP, and can it still retrieve the history it chose not to migrate?