ERP Data Migration Plan Template
Data migration is where many ERP projects lose weeks, because the data nobody owned turns out to be wrong. A written plan puts owners, rules and mock loads on paper before the first extract runs.
Fill in
ERP Data Migration Plan Template
ERP Data Migration Plan
Project: Plant 1 ERP Replacement Source system: Legacy ERP on IBM i Target system: SAP S/4HANA Data migration lead: R. Gupta Migration tooling: Vendor migration cockpit Planned mock loads: 3
1. Scope
Objects in scope: Customers, vendors, items, bills of material, routings, work centers, open purchase orders, open sales orders, on-hand inventory, GL opening balances, fixed assets.
History approach: Open transactions plus 24 months of summarised GL balances
Objects explicitly excluded should be listed here with the reason and where the data will remain accessible.
2. Cleansing and transformation rules
Remove inactive items with no movement in 36 months. Merge duplicate vendors by tax ID. Standardise units of measure. Validate addresses and tax numbers.
Every rule has an owner who approves it, and rule changes after mock load 1 go through the migration lead.
3. Object plan
| Object | Data owner | Source | Load method | Volume | Reconciliation check |
|---|---|---|---|---|---|
| Customer master | Sales ops | Vendor migration cockpit | Record count, credit limit sum | ||
| Vendor master | Purchasing | Vendor migration cockpit | Record count, tax ID unique | ||
| Item master | Engineering | Vendor migration cockpit | Count by type and UoM | ||
| Open purchase orders | Purchasing | Vendor migration cockpit | Open value, line count | ||
| On-hand inventory | Warehouse | Vendor migration cockpit | Quantity and value by item | ||
| GL opening balances | Finance | Vendor migration cockpit | Trial balance debits equal credits |
4. Mock load schedule
| Load | Purpose | Planned date | Exit criterion |
|---|---|---|---|
| Mock 1 | Find mapping and data errors | Error list issued to data owners | |
| Mock 2 | Validate fixes and timings | Load success above agreed threshold | |
| Mock 3 / dress rehearsal | Run to real cutover schedule | Reconciliation signed by data owners |
5. Reconciliation and sign-off
Each object is reconciled by record counts and control totals (quantity, value) between source extract and target system. Data owners sign off each object after every mock load. Production load proceeds only when all owners have signed off the dress rehearsal. Open differences are logged with an owner and due date.
Approvals
This is a starting point. Add object-specific mapping in a mapping worksheet and keep field-level detail out of this plan. Table volumes and sources are left blank on purpose; fill them from your extract profiling.
Migration data profiling review
Tell us the source system and objects and we will suggest profiling queries and duplicate checks to run before mock load 1.
Optional. The tool and every export work without this. No spam.
How to use the template
Enter your source and target systems, tooling and the number of mock loads. List objects in scope and write your cleansing rules in plain language. Export the document and use the object table as the register: add one row per object with its business data owner, source, volume and reconciliation check. Review the plan with finance, operations and engineering, because each owns different master and transactional data. Version it and keep it current as rules change after each mock load.
Principles behind the plan
Migrate what the business needs to operate and report, not everything the old system ever held. Master data is moved clean, open transactions are moved with balances that reconcile, and history is usually summarised or archived. Every object needs a business owner, not only an IT owner, because only the business can decide whether a duplicate vendor or an item with no movement should survive.
- One named business owner per data object
- Cleanse in the source or staging area, not by hand in the target
- Control totals for every load: counts, quantities and values
- Archive history instead of loading all of it when possible
Mock loads and reconciliation
Each mock load should be a full rehearsal of extract, transform, load and reconcile. The first usually exposes the largest volume of errors and is expected to fail on a share of records. By the second, errors should be traceable to a short list of rules. The final rehearsal runs to the real cutover timetable and is the source of the timings in your cutover plan. Reconcile inventory by quantity and value per item, open orders by line count and open value, and GL by trial balance.
Common mistakes
Common failures are starting cleansing too late, leaving owners out of reconciliation, and loading unit-of-measure or tax code mismatches that are only visible when the first invoice posts. Another is allowing the mapping to change without informing testers, which breaks UAT data. Freeze mapping versions and tell test leads when they change.
Frequently Asked Questions
How much history should we migrate?
Most manufacturers migrate open transactions, current master data and GL opening balances, with a summarised period or two of history. Full transaction history is usually archived in a read-only reporting store because it adds load time and reconciliation effort.
How many mock loads do we need?
Three is a common standard: one to find errors, one to validate fixes and one dress rehearsal on the real schedule. Complex or multi-site projects often need four or more.
Who should own data migration?
A dedicated migration lead coordinates the work, but each object needs a business data owner who approves cleansing rules and signs off reconciliation. IT owns the mechanics, the business owns the content.
Should we use the vendor migration tool or custom scripts?
Vendor tools such as migration cockpits give prebuilt structures and validation and are usually the first choice. Custom scripts or ETL are used for objects the tool does not cover or for heavy transformation. Many projects use both.
If duplicate detection, classification of items or unit-of-measure cleanup is eating your schedule, we can discuss AI-assisted profiling that runs on your own servers against your source data.
Related Tools
ERP Cutover Plan Worksheet
Build a task-by-task ERP cutover runbook with owners, durations and a buffer, and calculate the total cutover window.
ERP Migration & SelectionERP Implementation Project Plan Template
Generate a structured ERP implementation project plan with scope, phases, governance, milestones and risks, ready to export as PDF or Word.
ERP Migration & SelectionERP UAT Test Script Template
A user acceptance test worksheet with example order-to-cash and procure-to-pay scripts, tester columns and result tracking you can export to Excel.
ERP Migration & SelectionData Migration Effort Calculator
Estimate the hours, elapsed weeks, and cost of migrating your legacy ERP data based on entity count, data quality, history depth, and test cycles.
ERP Migration & SelectionERP Go-Live Readiness Assessment
A ten-question scored assessment of your ERP go-live readiness, with a verdict and recommended actions before your go/no-go meeting.
More ERP Migration & Selection tools
See all- ERP TCO Comparison Calculator (5-Year)
- ERP Migration Risk Assessment
- ERP Selection Scorecard for Manufacturers
- ERP Go-Live Readiness Checklist
- ERP Change Management Readiness Assessment
- ERP Integration Complexity Calculator
- Cloud vs On-Premise ERP Cost Calculator
- ERP Upgrade vs Replace Assessment
- ERP Implementation Timeline Estimator