ERP migration moves agreed business data and processes from an existing system into a new one. For finance, success means more than importing records: the new balances must reconcile, the transaction history must remain usable and the team must be able to run the next close.
Decide what the future accounting structure needs before moving data. Otherwise, the migration can preserve the reporting problems that prompted the project.
How much history should you migrate?
There are three common choices: opening balances with open items, a defined period of transaction history, or the full available history. Each has a cost and a purpose.
Opening balances can reduce the volume of data to transform, but finance still needs access to the records supporting them. Current-year history can make reporting across the cutover easier. A longer history can support comparisons and investigation, provided the team can reconcile it and preserve the meaning of the records.
Choose based on reporting, audit, operational and retention needs. Full history is not automatically the right answer, and leaving records in an archive should be an explicit design decision rather than an afterthought.
The All Gravy customer story describes a full-history migration into Light. It is one approach to consider when discussing scope, rather than a requirement for every company.
What should you map before importing?
Agree the chart of accounts, entities, currencies, dimensions and reporting periods. Map customers, suppliers and open items with stable identifiers. Record how the team will treat inactive records and duplicates.
Then examine fields that look similar but mean different things. Invoice date, posting date and service period may drive different reports. A department embedded in an old account code may need its own dimension in the new system.
Keep a mapping register with an owner for each decision. Test it on a small but representative extract before processing the full dataset.
Which active schedules and balances need separate checks?
An opening balance does not carry every instruction needed for the next period. Inventory the work still in progress at cutover.
| Record | Keep with the opening position | First-close check |
|---|---|---|
| Revenue and prepaid schedules | Original value, amount already released, remaining dates and accounting basis | The first new release starts from the remaining balance without duplicating migrated activity |
| Open invoices and credits | Document IDs, original currencies, due dates and allocations | Ageing and open amounts agree with the source |
| Intercompany balances | Entity pair, shared reference and unresolved differences | Both sides reconcile before group elimination |
| Foreign-currency balances | Source amounts, rates and previous revaluation or translation adjustments | Finance can reproduce the opening position and explain the next currency movement |
| Fixed assets | Cost, accumulated depreciation and remaining schedule | The register agrees with the ledger and the next depreciation entry |
If subsidiaries move in phases, name the ledger of record for each entity and period. Agree who supplies the trial balance, maintains account mappings and corrects a late submission. A trial-balance import alone does not establish transaction-level drill-down or open-item migration.
Reserve named finance-team capacity for parallel testing and the first close. Include year-end and audit commitments in the implementation timetable, with a documented condition for delaying cutover.
How do you prove the data arrived correctly?
Use several checks. Reconcile trial balances by entity and period, then compare receivables, payables, cash and other material supporting schedules. Confirm the number and value of open items, and inspect source documents and links for selected transactions.
A balanced trial balance alone does not prove that every customer balance or document reference migrated correctly. Record differences, investigate them and obtain sign-off on their resolution.
Reconcile again after the final load. Testing an earlier extract does not establish that the cutover data is complete.
What belongs in the cutover plan?
Define when each source system stops accepting changes, who exports the final data and who approves the destination balances. State which system issues invoices and payment instructions at each point so the team avoids duplicate activity.
Test the critical workflows before cutover, including corrections and failures. Agree the conditions for delaying go-live and how the business would continue operating if it does.
The ERP implementation timeline places these decisions within the wider project. Include the first close in the support plan instead of treating go-live as the finish line.
What should remain accessible after migration?
Keep the source exports, mapping decisions, reconciliation evidence and required historical documents in a controlled location. Confirm how people will retrieve them when old subscriptions or access rights end.
Use the ERP selection scorecard to assess a vendor's migration proposal. For Light, review how migration works and the customer examples, then bring the source systems, history requirements and entity structure to the implementation discussion so the team can scope the work against your records.
