ERP Migration Checklist: Data, Cutover and Reconciliation

An ERP migration succeeds when three things are planned as carefully as the new system itself: the data migration, the cutover, and the reconciliation that proves the new system's numbers are right. This checklist covers all three, from scoping which data to move through the go-live weekend to the first month-end close. Use it whether you are moving from spreadsheets, an accounting package, or another ERP.

Most migration trouble is predictable. Data is dirtier than expected, mapping decisions are made too late, nobody owns sign-off, and the cutover plan exists only in someone's head. A written checklist with named owners prevents most of it.

1. Migration strategy and scope

Settle these decisions before any data is extracted:

• Go-live date and cutover timing, usually aligned to the start of a month or financial period.
• Big-bang go-live or phased by company, site or module.
• Which data objects migrate: master data, open transactions, balances, history.
• How much history to bring across, and where older history will remain accessible.
• Who owns each data object on the business side and who signs it off.
• Migration tools: native import, scripted API loads, or middleware.
• Number of trial migrations, with at least two full rehearsals planned.
• How long the legacy system stays available in read-only mode.

What to migrate: a typical scope

2. Data quality and cleansing checklist

• Profile each source: record counts, empty fields, invalid formats, obvious duplicates.
• Deduplicate customers and vendors using agreed matching rules such as tax ID, email or name plus address.
• Archive inactive records instead of migrating them, with agreed cut-off rules.
• Standardize formats: addresses, phone numbers, country codes, units of measure.
• Validate tax registration numbers and bank details where the business relies on them.
• Review item master data: descriptions, categories, units, costing methods, reorder rules.
• Confirm the new chart of accounts and map every legacy account to it.
• Assign a business owner to fix source data, not just the migration team.

Cleansing is business work. IT can find problems, but only the people who know the customers, products and accounts can decide what is correct.

3. Mapping and transformation checklist

• Create a field-by-field mapping document for each object, from source to target.
• Map code lists: payment terms, tax codes, units, warehouses, cost centers, currencies.
• Define default values for mandatory fields that do not exist in the source.
• Agree on how legacy IDs are kept, usually in a reference field, so records can be traced.
• Document transformation rules, such as splitting full names or combining address lines.
• Define the load order based on dependencies: accounts, then partners and items, then balances and open documents.
• Have business owners sign off the mapping before the first trial load.

4. Trial migration checklist

• Load into a test environment that matches production configuration.
• Log load errors and fix them at the source or in transformation rules, not by hand in the target.
• Time each step so the cutover plan is based on real durations.
• Run the full reconciliation process described below.
• Have key users test real scenarios on migrated data: invoice a migrated order, receive a migrated purchase order, collect a migrated receivable.
• Record lessons and update the runbook after each trial.

5. Reconciliation checklist

Reconciliation is how you prove the migration worked. Agree acceptance criteria in advance and have finance and operations sign them off.

Counts and completeness

• Record counts per object match between source extract and target, after planned exclusions.
• Every exclusion is listed with a reason.
• Sample checks of individual records by business users, including the most important customers, vendors and items.

Financial balances

• Opening trial balance in the new system matches the legacy closing trial balance at cutover, account by account after mapping.
• Accounts receivable aging total matches the receivables control account, and customer-level balances match.
• Accounts payable aging total matches the payables control account, and vendor-level balances match.
• Bank and cash balances match bank statements at the cutover date.
• Fixed asset register values match the asset accounts.
• Open foreign currency balances are handled consistently with the agreed exchange rates.

Inventory

• Quantities by item, warehouse, location, lot and serial match a physical count or the agreed legacy figures.
• Inventory value matches the stock accounts in the opening trial balance.
• Unit costs are consistent with the chosen costing method.

Open documents

• Open sales and purchase orders match in count, value and remaining quantities.
• Open work orders and their consumed materials are accounted for.

6. Cutover checklist

The cutover is a short, controlled window. Write it as a runbook with timed steps, owners and go or no-go checkpoints.

Before cutover

• Final configuration frozen and moved to production.
• User accounts, roles and permissions set up and tested.
• Integrations configured and tested against production endpoints.
• Communication sent to staff, customers and vendors where relevant, such as new invoice formats or bank details.
• Master data freeze in the legacy system announced.
• Physical stock count scheduled if inventory balances will be loaded from it.

During cutover

• Stop transactions in the legacy system at the agreed time.
• Complete the legacy period-end steps needed to produce closing balances.
• Extract, transform and load in the rehearsed order.
• Run reconciliation and obtain written sign-off from finance and operations.
• Hold the go or no-go decision with the sponsor; have a rollback plan ready if no-go.
• Switch the legacy system to read-only.

After go-live

• Daily issue review with a clear triage process for the first weeks.
• Monitor integrations for failures every day.
• Watch the first full cycle of each key process: invoicing, payment runs, purchasing, production.
• Complete the first month-end close in the new system with extra checks.
• Decommission or archive the legacy system only after the retention plan is in place.

7. Roles and responsibilities

Every item on this checklist needs a named owner. A simple split that works in most projects:

• Migration lead: owns the plan, runbook, tools and load process.
• Data owners in finance, sales, purchasing, operations and HR: cleanse source data, approve mappings, and sign off reconciliation.
• Finance controller: owns the opening trial balance, subledger reconciliation and the first close.
• Project sponsor: makes the go or no-go decision and resolves conflicts.
• Key users: test migrated data in real scenarios and confirm it is usable.

When ownership is clear, problems found during trial loads get fixed at the source quickly instead of bouncing between teams.

Common migration mistakes

• Treating migration as a technical task at the end of the project instead of a workstream from the start.
• Migrating full history by default, which adds effort and risk with little benefit.
• Fixing data by hand in the target system, so the next trial run repeats the same errors.
• No signed reconciliation, so doubts about the numbers linger for months.
• Choosing a cutover date that clashes with peak trading or the financial year-end.

For the wider project around migration, see my ERP implementation guide. Platform-specific notes are in the Odoo implementation guide, and you can see an example in the trading company ERPNext migration case study.

Next steps

If you are planning an ERP migration and want a second pair of eyes on the scope, mapping or cutover plan, I can help as part of my ERP consulting work. Get in touch to talk it through.

Frequently Asked Questions

How much historical data should we migrate to a new ERP?

Usually as little as the business needs to operate. Most projects migrate master data, open transactions and opening balances, and keep detailed history in the legacy system or an archive for reference, audit and reporting.

How many trial migrations should we run?

Plan for at least two full rehearsals with reconciliation. Each trial exposes data and mapping issues, and the final rehearsal should run cleanly and within the time available for the real cutover.

Who should sign off an ERP data migration?

Business owners for each data object, typically finance for balances and the chart of accounts, operations for inventory and items, and sales and purchasing for customers, vendors and open orders. IT runs the process but should not be the sole sign-off.

What is the best time to cut over to a new ERP?

Usually at the start of a month or financial period, avoiding peak trading seasons and the financial year-end close. Aligning to a period boundary keeps opening balances and reporting simple.