ERP DATA MIGRATION AND CUTOVER WORKBOOK
Tellency evaluation resources | Reviewed 3 November 2026
https://tellency.com/resources/erp-evaluation-tools

Use this fill-in register to plan migration work, not as a promise of automatic
migration or a guaranteed rollout date. Illustrative examples use no customer
records. The finance owner must approve accounting cutover and reconciliation.

PROJECT CONTROL
Source system(s):
Destination and environment:
Scope / exclusions:
Cutover date, timezone and business calendar:
Migration owner / finance reviewer / operations reviewer:
Data protection, authorised access and retention responsibilities:
Freeze window and emergency-change process:
Go/no-go authority and rollback decision maker:

DATASET REGISTER — repeat for every dataset
Dataset (e.g. products, suppliers, customers, open orders, opening balances):
Business owner:
Source export and extraction timestamp:
Authorised storage location / access / retention:
Source record count:
Duplicate and inactive-record policy:
Destination field mapping and transformation rules:
Required identifiers and dependency order:
Validation rules / rejection log / correction owner:
Target imported count / rejected count / approved exclusions:
Control totals or spot-check method:
Evidence location / reviewer / status:

MAPPING EXAMPLE — illustrative only
Source item_code -> destination product identifier: retain leading zeroes.
Source unit -> destination unit: map only agreed compatible units.
Source category -> destination category: approved mapping table required.
Source inactive flag -> destination status: retain historical reference scope.
A unit named "box" does not establish how many units a particular item contains.
An empty value should not silently become a default tax code or account.

DEPENDENCY CHECK
[ ] Users and roles available for authorised validation.
[ ] Chart of accounts, currencies, tax and payment settings agreed.
[ ] Products, units, locations and lots mapped where applicable.
[ ] Suppliers and customers deduplicated with retained identifiers.
[ ] Open documents reference valid master records.
[ ] Stock and financial opening positions have agreed effective dates.
[ ] Attachments, history and integrations explicitly included or excluded.

RECONCILIATION REGISTER — define expected values BEFORE import
Control name / source timestamp / source value / destination value / difference:
1. Master record counts, approved duplicates and exclusions.
2. Customer balances by customer and currency.
3. Supplier balances by supplier and currency.
4. Stock quantity by item, location and lot where required.
5. Stock valuation by agreed costing basis and date.
6. Open order quantity and value, including partial fulfilment.
7. Opening trial balance and relevant control accounts.
8. Historical transactions, attachments and retained audit access as scoped.
Difference explanation / adjustment reference / approver / date:

ILLUSTRATIVE RECONCILIATION
Source customer balance: 10,000 in agreed currency.
Imported open invoices: 11,000; imported unapplied credit: 1,000.
Destination net balance: 10,000. Confirm the credit remains usable and that
invoice-level references, ageing dates and reporting are correct. Matching one
net total alone does not prove a correct customer ledger.

DRY RUN
Run ID / extraction date / software version:
Import order and duration:
Failures and correction method:
Reconciliation evidence:
User workflow checks after migration:
Repeat-run method that prevents duplicate documents:
Approved changes for next run:

CUTOVER CHECKLIST
[ ] Source freeze acknowledged by business owners.
[ ] Final export identified and stored with controlled access.
[ ] Import completes with reviewed rejection log.
[ ] Financial and operational controls reconcile.
[ ] Critical order-to-cash and procure-to-pay workflows accepted.
[ ] Integrations tested with agreed activation timing.
[ ] Users trained and support responsibilities published.
[ ] Go-live decision recorded by named authority.

ROLLBACK AND AFTERCARE
Rollback triggers and decision deadline:
Source reactivation procedure:
Treatment of transactions already entered in the destination:
Integration rerouting and duplicate-prevention checks:
Communication owner and affected teams:
Day-one issue register / priority / owner / resolution evidence:
First-close acceptance and retained source access:

Reuse: copy and adapt for your own project. If publishing an adaptation,
identify changes and cite the resource page above. No referral fee, endorsement
or reciprocal link is required. Remove personal/customer data before sharing.