A sound default for an ERP migration is to load open items, year-end balances and master data, keep a defined window of summarised history for comparatives, and move the rest into a read-only archive. Migrating full transactional history is the exception, justified by a specific reporting, legal or operational need, and it carries the most reconciliation work.
This guide is about the scoping and retention decision, which comes before any mapping. It is different from our ERP data migration checklist, which covers cleansing, mapping, trial loads and cutover once scope is fixed, and from the step-by-step migration plan. If you are a CFO, controller or finance lead who has just been told that history is "out of scope", or who is writing that sentence into a tender, this is the decision behind it. For help with the scoping step, see our ERP data migration services.
Retention periods, audit access and record-keeping rules are set by law, policy and contract in each country. This guide describes general practice, not legal, tax or accounting advice. Confirm retention with your legal counsel, auditor and tax adviser.
Key takeaways
- There are three realistic scopes: open items and year-end balances only, a history window, or full history. Choose per data domain, not once for the whole project.
- Every record you migrate has to be mapped, loaded, reconciled and signed off. History multiplies that work without always adding value.
- "Out of scope" for history only works if a searchable, access-controlled archive exists and the retention obligation is met there.
- Audit-trail records are evidence about the old system. They are usually archived, not re-created in the new system.
- Mid-year moves need year-to-date figures for items such as employee reimbursements, tax and payroll-linked totals, so scope those explicitly.
- Write the scope as a table with owners, so tenders and contracts cannot be read two ways.
What are the three scoping options?
The options differ in how much the new system knows about the past. Option 1 loads only what is still open plus balances. Option 2 adds a defined window of history for comparatives and trend reports. Option 3 loads all history and treats the old system as retired.
| Option | What moves | What stays behind | Good fit |
|---|
| 1. Open items and year-end balances | Master data, open receivables and payables, open orders, closing trial balance, stock on hand | All closed transactions | Clean break, short cutover, history rarely needed day to day |
| 2. History window | Option 1 plus a defined period of detail or monthly summaries | Anything older than the window | Comparatives, trend reports, warranty or dispute lookups |
| 3. Full history | Everything, mapped to the new structure | Nothing, except the system itself | Strong legal or operational need to query history in one place |
Many finance teams settle on Option 1 or 2 for finance data and Option 2 or 3 for a few domains, such as asset registers, contracts or service histories.
How do you decide what to migrate for each data domain?
Ask who will need the data after go-live, how often, and whether the old archive can answer the question. Data that supports a live process must move. Data that only answers occasional questions can stay in an archive. Data that nobody can name a user for should not move.
| Question | If yes | If no |
|---|
| Is the record open, or could it change after go-live? | Migrate it | Consider archive |
| Is it needed to calculate a balance, a depreciation run or a stock value? | Migrate it | Consider archive |
| Is it needed for comparative reports this and next year? | Migrate detail or summaries | Archive |
| Is it needed for warranty, dispute or customer service lookups? | Migrate a window or link to the archive | Archive |
| Does a law, contract or auditor require it to be retained? | Retain it, in the archive if not in the ERP | Review at the next retention check |
| Would loading it require mapping that nobody can validate? | Archive it | Migrate it |
Run this by domain: general ledger, receivables, payables, fixed assets, inventory, projects, contracts, payroll and expenses, customers and suppliers, documents. Our wider legacy ERP modernization guide covers the replace-or-extend question that sits above this one.
What does open items and year-end balances only actually involve?
It involves migrating master data, the closing trial balance at a clean period end, and the open items that make up the control accounts, then proving that the totals tie. Receivables and payables are loaded as individual open invoices so ageing and payment matching continue, not as a single net balance per account.
Typical contents: chart of accounts and mappings, customers and suppliers, the closing trial balance, open invoices and credit notes, open purchase and sales orders, stock quantity and value by item and location, fixed asset register with accumulated depreciation, open project balances, and opening balances for bank. Opening balances for P&L accounts are usually zero at a year-end start; mid-year starts need year-to-date P&L balances.
Compare this with the tender wording that appears in procurement documents: "transfer of open and year-end balances, supplier and customer information, and other data from our legacy system. Migration of transactional-level data is out of scope." Read that as: summary balances and master data move; detailed journals, closed invoices and historical postings do not. It is clear on what moves, but vague on three points, which should be clarified before pricing:
- Who extracts and who validates the data, and in what format.
- Whether comparatives (prior-year monthly totals) are in scope as summaries.
- Where the old data is kept and who answers questions about it.
What should be archived read-only?
Archive any closed transactional history that you must keep but will not use daily. A usable archive is searchable, access-controlled, tamper-evident, exportable and tied to a retention schedule. A folder of spreadsheets or a database dump nobody can open does not meet that bar.
| Archive requirement | Why it matters |
|---|
| Read-only | Evidence must not be changed after the fact |
| Searchable by key fields (document number, party, date, amount) | Auditors and staff need to find records quickly |
| Role-based access with logging | Sensitive data stays controlled |
| Export to open formats | Avoids dependence on a retired product |
| Linked identifiers | Customer and supplier numbers should match those in the new ERP |
| Retention schedule with review dates | Records are deleted when policy allows, not kept forever |
| Named owner | Someone answers audit and legal requests |
Keep the legacy system running read-only, or extract to a lower-cost archive store, depending on licence terms, security support and the retention period. The cost of keeping an old platform alive is a real part of the decision, so compare it with the cost of migrating more history.
How should audit-trail records be handled?
Audit-trail records, the logs of who created, changed, approved or deleted something and when, should normally be archived intact, not loaded as new activity in the new system. Re-creating them would give old actions new timestamps and users, which weakens their value as evidence. Retain the original logs read-only and link them to the migrated records.
What the new system needs is its own audit trail from go-live, plus a record of the migration itself: the extract, the mapping, the reconciliation results and the sign-offs. That migration record becomes the bridge your auditor reads between the old log and the new one. Ask your auditor in advance which evidence they expect for the migration period.
What about reimbursement and expense history mid-year?
When you move employee reimbursement or expense data mid-year, migrate open claims, approved but unpaid items, the policies and limits that apply, and year-to-date totals per employee where they affect later calculations or reporting. Closed claims can usually be archived. Confirm with your payroll provider and tax adviser which year-to-date amounts must be carried over.
Points to settle:
- Open and in-approval claims, with their approval history so far, so approvers do not restart.
- Receipts and supporting documents for items still open or under review.
- Year-to-date reimbursements and any taxable portion that affects later payroll or reporting.
- Corporate card transactions not yet matched.
- Mapping of expense categories, cost centres and projects to the new structure.
- The archive location for closed claims and receipts, and how long they are kept.
Worked example: scoping a mid-sized finance migration
Figures are illustrative and show how scope changes the load, not what any project costs.
A company is moving from a 12-year-old ERP at a fiscal year-end. The legacy system holds 420 active GL accounts, 1,900 open receivable items, 650 open payable items, 3,100 active customers and suppliers, 4,200 stock items and about 2.4 million journal lines across 7 years.
| Item | Option 1 | Option 2 (24-month window, summarised) | Option 3 |
|---|
| Master data records | About 7,300 (3,100 customers and suppliers, 4,200 stock items), plus 420 GL accounts mapped separately | Same | Same, plus inactive records |
| Open AR and AP items | 2,550 | 2,550 | 2,550 plus all closed items |
| Journal lines loaded | 0 (balances only) | Monthly account totals for 24 months | About 2.4 million lines |
| Reconciliations needed | Closing TB, open items, stock | Same, plus monthly totals to old reports | Same, plus every period and every subledger |
| Prior-year comparatives in new ERP | None | Yes, at account level | Yes, at transaction level |
| Where old detail is queried | Archive | Archive beyond 24 months | New ERP |
The controller chooses Option 2 for finance because the board wants prior-year comparatives, but not transaction-level detail. Fixed assets and open contracts are loaded in full, as those drive live calculations. Closed journals older than the window go to a read-only archive with the same account numbers, searchable by document number and date. The auditor is shown the retention schedule and the migration reconciliation before sign-off.
Reconciliation targets are the same in every option: closing trial balance to the old ledger, open receivables and payables to their control accounts, and stock quantity and value to the stock report, each signed by the domain owner.
What steps prepare legacy data for a major upgrade?
Prepare legacy data in this order: decide scope by domain, name data owners, profile quality, cleanse at source, choose the cut-off, build the archive, then run trial loads. The scope decision comes first, because it determines how much cleansing is worthwhile.
- Inventory systems, tables and volumes.
- Decide scope per domain using the table above.
- Assign an owner to each domain who signs off the reconciliation.
- Profile quality and agree what is cleansed before loading.
- Choose the cut-off period and freeze rules.
- Stand up the archive and test retrieval.
- Run trial loads and reconcile, as described in our checklist.
When this is the wrong approach
Open items only is the wrong scope if regulators, contracts or customer service need transaction detail in the new system on day one, if the legacy platform will be switched off soon with no secure archive, or if the data model changes so much that totals cannot be proved without detail. Full history is the wrong scope if the reason is simply "we might need it". Where the legacy platform itself is the risk, start with a legacy software modernization assessment.
Glossary: open item, an invoice or entry not yet paid or settled; year-end balance, the closing balance of an account at a period end; comparatives, prior-period figures shown beside current ones; archive, a read-only store for records you must keep but do not use daily; audit trail, the log of who did what and when.
How Timeline Digital approaches this work
Timeline Digital treats migration scope as a decision to settle in the Plan step, before any mapping starts. Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, delivering remotely. We agree migration scope by data domain with the client's finance team, and the free pilot of 2 to 3 key modules lets your team test the result before the final agreement. Schedules are set from requirements in the Plan step, and code ownership passes on full payment. See our custom ERP software page for the approach.