An ERP data migration checklist has five working parts: a scope list that says what moves and what is archived, cleansing rules with owners, a field mapping sheet, a reconciliation matrix that proves each load, and a cutover run-sheet with go/no-go criteria. Each line needs an owner, a due date and evidence of completion, otherwise it is a wish list.
Our guide to the ERP data migration plan explains the eight steps of a migration and why they matter. This article is the companion working document: tables you can paste into a spreadsheet, fill in and track. It applies whether you are moving to a packaged ERP, a cloud ERP or a custom system, and whether the source is an old ERP, an accounting package or a set of spreadsheets. If you want a team to run the migration, see our ERP migration services. For the wider rollout, see ERP implementation services.
How to use this checklist
- Copy each table into one workbook, one tab per section.
- Add three columns to every row: Owner (a named person, not a department), Due date and Evidence (a link to the report, ticket or sign-off).
- Review the workbook weekly in the project meeting. A row is closed only when the evidence exists.
- Keep the workbook under version control or in a shared drive with history, because auditors and your future self will ask what changed.
Section 1: Scope and inventory
| # | Check | Detail |
|---|
| 1.1 | List every source system | ERP, accounting package, spreadsheets, CRM, warehouse tools, payroll exports |
| 1.2 | List data objects in scope | Customers, suppliers, items, bills of materials, price lists, chart of accounts, open orders, open invoices, fixed assets, employees, balances |
| 1.3 | Decide migrate, summarize or archive for each object | Migrate active and open records; summarize closed history as balances; archive the rest in a readable form |
| 1.4 | Set the history window | For example the current and prior financial year in detail; older years as totals; agreed with finance and auditors |
| 1.5 | Fix the cutover date | Prefer the start of a period, never in the middle of a month-end close |
| 1.6 | Freeze policy | Agree when users stop creating records in the old system and how late entries are handled |
| 1.7 | Name a data owner per object | The business person who can say whether a record is right |
| 1.8 | Record volumes | Rows per object; used to plan load time and rehearsal length |
| 1.9 | Identify regulated or personal data | Decide masking for test environments and retention periods |
Section 2: Profiling and cleansing
Profile before cleaning so you fix by rule, not by hand.
| # | Check | Detail |
|---|
| 2.1 | Profile each object | Count records, blanks, duplicates, out-of-range values, orphans (invoices with no customer) |
| 2.2 | Define a duplicate rule | For example same tax number or same normalized name and postcode; the rule is signed off by the data owner |
| 2.3 | Define active versus inactive | For example no transaction for 24 months and zero balance; inactive records are archived, not migrated |
| 2.4 | Standardize formats | Dates, phone numbers, country codes, units of measure, currency codes |
| 2.5 | Fix at the source where possible | Clean in the old system so every trial load benefits; keep a change log |
| 2.6 | Resolve negative or impossible values | Negative stock, invoices without lines, balances that do not agree to the ledger |
| 2.7 | Complete mandatory fields | List new ERP mandatory fields that the old data lacks and decide default or manual entry |
| 2.8 | Record rejected records | Every excluded record has a reason and an owner |
Section 3: Mapping sheet
Create one row per target field. This is the document developers build from and auditors read.
| Source system | Source table / field | Target object / field | Transformation rule | Default if blank | Validation | Owner |
|---|
| Old ERP | CUST.CUST_NAME | Customer.Name | Trim spaces; title case | none; reject if blank | Max 120 characters | Sales ops |
| Old ERP | CUST.TERMS | Customer.PaymentTerms | Map old code 30D to Net 30 (lookup table) | Net 30 | Must exist in target list | Finance |
| Spreadsheet | Items.xlsx col F | Item.UnitOfMeasure | Map PCS, Pc, pieces to EA | EA | Must exist in target list | Warehouse |
| Old ERP | GL.BALANCE | OpeningBalance.Amount | Sum by account and period end; sign reversed for liabilities | 0 | Trial balance equals source | Finance |
Mapping checks:
- Every target mandatory field has a source or a default.
- Every source field is mapped, deliberately ignored, or archived, with the decision recorded.
- Lookup tables (payment terms, tax codes, units, warehouses) are signed off by their owners.
- Identifiers: decide whether old IDs are kept as a legacy reference field. Keeping them makes later queries and reconciliation much easier.
- Currency and rounding rules for multi-currency balances are written down.
Section 4: Trial loads
| # | Check | Detail |
|---|
| 4.1 | Build repeatable load scripts | Same inputs give the same results; scripts are under version control |
| 4.2 | Load into a test environment | Never rehearse in the live environment |
| 4.3 | Run trial 1 | Expect many errors; the aim is a list of defect categories |
| 4.4 | Run trial 2 | Defects from trial 1 fixed; errors should drop sharply |
| 4.5 | Run a timed dress rehearsal | Full volume, full run-sheet, timed per step; staff who will run cutover do the work |
| 4.6 | Record load times | These set the length of the cutover window |
| 4.7 | User acceptance on migrated data | Business users search for records they know and check them |
Plan at least two trial loads and one timed dress rehearsal. Fewer is a risk you should accept knowingly and in writing.
Section 5: Reconciliation matrix
Run these after every load, and keep each report.
| Object | Check | Source value | Target value | Difference | Signed off by |
|---|
| Customers | Record count (active) | | | | Sales ops |
| Suppliers | Record count (active) | | | | Purchasing |
| Items | Record count; count with valid unit and price | | | | Warehouse |
| Stock | Quantity and value by item and location | | | | Warehouse and finance |
| Accounts | Trial balance by account at the cutover date | | | | Finance |
| Receivables | Open invoice total and ageing by customer | | | | Finance |
| Payables | Open bill total and ageing by supplier | | | | Finance |
| Open orders | Count, value and status distribution | | | | Operations |
| Fixed assets | Cost and accumulated depreciation | | | | Finance |
| Spot checks | 25 random records per object compared field by field | | | | Data owner |
Rules: a difference must be zero or explained and approved in writing; financial totals are matched to the cent or smallest currency unit; counts are matched exactly.
Section 6: Cutover run-sheet
| Time | Step | Owner | Duration (from dress rehearsal) | Check |
|---|
| T-5 days | Final trial load and reconciliation sign-off | Migration lead | | Reports filed |
| T-2 days | Confirm access, licences, support contacts | Project manager | | Checklist ticked |
| T-1 day | Communicate freeze to users | Business owner | | Acknowledged |
| T-0 | Freeze old system; take verified backup | IT lead | | Backup restores |
| T+1 | Extract final data | Migration lead | | Row counts logged |
| T+2 | Load into production | Migration lead | | No fatal errors |
| T+3 | Run reconciliation matrix | Finance and data owners | | All lines signed |
| T+4 | Smoke-test key transactions (sale, purchase, payment, stock move) | Key users | | Pass or fail logged |
| T+5 | Go/no-go decision | Steering owner | | Criteria met |
| T+6 | Open the new system; set old system to read-only | IT lead | | Access changed |
Adjust the clock to your own dress-rehearsal timings; the sequence matters more than the labels.
Section 7: Go/no-go criteria and rollback
Write the criteria before the weekend, not during it.
- All reconciliation lines are signed off, or each difference is explained and approved by finance.
- Smoke tests for the five most important transactions pass.
- Key users are present and trained.
- Support contacts for the ERP vendor or implementer are on call.
- The old system is intact, read-only and ready to reopen.
Rollback needs a trigger (which failed check forces it), a decision-maker (one named person), a method (reopen the old system, discard or quarantine the new entries) and a communication plan. Record how transactions entered after go-live would be re-keyed if you roll back; if that is impractical after a certain time, state the point of no return.
Section 8: Hypercare
| # | Check | Detail |
|---|
| 8.1 | Daily reconciliation for the first two weeks | Stock, cash, receivables and payables |
| 8.2 | Issue log with severity and owner | Reviewed daily |
| 8.3 | Keep the old system read-only | For the retention period your auditors and policy require |
| 8.4 | First period-end close in the new system | Finance reviews the first close line by line |
| 8.5 | Lessons learned | Record what the rehearsals missed |
Common reasons checklists fail
- No owners. Items assigned to "IT" belong to no one.
- Cleansing deferred to after go-live. Dirty data moves faster than anyone cleans it afterwards.
- Reconciliation only at the end. Run it after every trial load.
- Mapping lives in someone's head. It must be a document.
- Cutover timed by guesswork. Use dress-rehearsal durations.
Who can run this migration with you
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. Our ERP migration services cover profiling, cleansing support, mapping, scripted trial loads, reconciliation reports and a rehearsed cutover for a custom, packaged or cloud ERP; the scripts and mapping documents transfer to you on full payment. There is no fixed timeframe: the schedule is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a complete system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Long-term support under a service level agreement (SLA) follows launch. Timeline Digital does not publish prices for custom software, because every project is custom.
About the author and publisher
This guide was written by Usama Asif, CEO and CTO of Timeline Digital. The example rows are illustrations of the format, not recommendations for your data; your auditors and finance team decide history windows and balance rules.