ERP Data Migration: What to Move and What to Leave Behind

ERP Implementation • Data Migration • Business Continuity

What We Migrate—and What We Leave Behind—When Replacing an ERP

When a business replaces its ERP system, one question appears almost immediately: how much of the old system should move into the new one? The instinct is often to migrate everything. Years of invoices, customer records, supplier details, stock movements and reports have accumulated, and nobody wants to lose information. But moving every record is not always the right decision. Some data is essential for daily operations. Some is needed for financial continuity or compliance. Other data is duplicated, outdated or no longer useful.

1. Replacing an ERP is also a data decision

Imagine a UAE distribution company, Gulfline Trading, preparing to replace a legacy ERP system after many years of use.

The old system contains:

• Thousands of customer and supplier records.
• Multiple versions of the same product code.
• Sales and purchase invoices from previous financial years.
• Completed orders and old delivery records.
• Current stock balances across several warehouses.
• Outstanding customer and supplier invoices.
• Historical financial reports and audit information.

The team initially suggests transferring everything. That sounds safe, but it creates new questions. Should inactive customers be recreated? What happens to duplicate item codes? Should fully paid invoices from seven years ago become live transactions? Should old stock adjustments be imported individually?

These are not simply technical questions. They affect reporting, operations, finance, compliance and the way employees use the new system.

Our starting principle: migrate the information the new business environment needs, preserve the information the business must retain, and avoid carrying unnecessary complexity into the replacement system.

2. What should migrate into the new ERP?

We normally divide migration data into categories. Each category has a different purpose, validation requirement and business owner.

A. Master data

Master data describes the core entities the business uses repeatedly. It is often the foundation of the new ERP.

• Customers and their approved addresses, contacts and payment terms.
• Suppliers and relevant commercial information.
• Items, product codes, descriptions, units of measure and categories.
• Warehouses, branches and locations.
• Chart of Accounts and relevant accounting dimensions.
• Price lists, tax details and other required configuration records.

However, master data should not be copied without review. If the same customer exists under three spellings, the business must decide which record becomes the approved master. If an item code is obsolete, it may not belong in the active item list.

B. Opening balances

Opening balances establish where the business stands when the new ERP becomes its system of record. They should represent the approved closing position of the old system at the agreed cutover date.

Depending on the business, these may include:

• General Ledger balances and the approved Trial Balance.
• Outstanding customer receivables.
• Outstanding supplier payables.
• Bank and cash balances.
• Stock quantities and values by item and warehouse.
• Fixed asset balances and relevant asset details.
• Advances, deposits and other outstanding balances.

These figures need to reconcile to the old system. A migration that loads balances without proving their accuracy can make the new ERP look operational while carrying incorrect financial information from day one.

C. Open transactions

Not every transaction in the old system is finished. Some still require action after go-live.

Examples include:

• Customer invoices that have not been fully collected.
• Supplier invoices that remain unpaid.
• Sales orders awaiting delivery.
• Purchase orders with outstanding quantities.
• Production orders that are still in progress.
• Customer advances or supplier advances that need settlement.

These records matter because the business must continue working on them in the new system. Their references, outstanding quantities, dates, amounts and related parties need careful mapping.

D. Selected historical transactions

Some historical data may be valuable for operational analysis, customer service, audit trails or management reporting. The business may choose to bring across selected periods or transaction categories.

The important word is selected. A historical record should have a clear reason to exist in the new environment. If users only need to look it up occasionally, a controlled archive may be more appropriate than recreating it as a live transaction.

3. What can we leave behind?

Leaving data behind does not mean deleting it or ignoring its importance. It means deciding that the information does not need to become an active record in the new ERP.

Important distinction: leaving a record out of the new ERP does not automatically make it safe to delete. Retention requirements, audit needs, contractual obligations and applicable laws must be considered before any source data is removed.

4. Clean the data before moving it

Migration is an opportunity to improve data quality, but cleaning should be a planned activity rather than a last-minute spreadsheet exercise.

Consider a simple example from Gulfline Trading. The old system contains the following item records:

Simply importing all four rows would transfer the old system’s inconsistencies into the new one. The team needs to confirm which records represent the same product and whether historical transactions refer to the original codes.

Common data-cleaning activities

• Deduplication: identify duplicate customers, suppliers, items and contacts.
• Standardisation: use consistent naming, address formats, units of measure and codes.
• Validation: check mandatory fields, tax details, currencies and linked records.
• Mapping: connect old codes, account heads and categories to their new equivalents.
• Exception handling: record missing or conflicting information and assign someone to resolve it.
• Traceability: retain source identifiers so imported records can be traced back to their original records.

One important rule: do not overwrite or discard the original source data during cleaning. Keep an untouched export and maintain a separate cleaned migration dataset. This makes it possible to review decisions and investigate differences later.

5. How much historical data should move?

This is one of the most important decisions in an ERP replacement project. There is no universal number of years that every business should migrate.

The answer depends on why the business needs historical information, how much detail users require, the cost of migration, reporting expectations and applicable retention requirements.

Option 1: Migrate operational data and opening positions

The new ERP starts with approved master data, opening balances and transactions that remain open. Older completed transactions stay in the legacy system or a controlled archive.

This approach can simplify go-live, but users need a reliable way to retrieve older information when required.

Option 2: Migrate selected historical periods

The business brings across a defined period of transaction history, perhaps to support management comparisons, customer service or operational analysis.

The selected period should be justified by actual reporting needs. The team also needs to define which transaction details must be preserved and how they will be reconciled.

Option 3: Migrate detailed transaction history

Some businesses need extensive historical detail inside the new environment. This may be justified by complex reporting, audit, operational or regulatory requirements.

However, detailed historical migration can require substantial mapping, testing and reconciliation. It may also bring old master records and inconsistencies into the new system.

For many organisations, a practical approach is to keep the legacy system available in read-only form for historical reference while bringing the records required for current operations into the new ERP.

That archive should not be an informal collection of old spreadsheets. It needs controlled access, clear retention rules, backup arrangements and a documented retrieval process.

6. Who owns the migration decisions?

One of the biggest risks in ERP migration is assuming that the implementation team can decide what the business should keep, correct or remove.

The technical team can extract data, map fields, build import templates and run validation checks. But it cannot independently determine whether a customer is commercially active, whether an old invoice should be retained, or whether a stock balance is correct.

Those decisions need business ownership.

These roles may vary by company size. In a smaller organisation, one person may own several areas. What matters is that every data category has an identified decision-maker and an approval trail.

Who decides what stays behind?

The business should approve a migration scope document that records:

• Which data categories will be migrated.
• Which historical periods will be included.
• Which records will be archived rather than imported.
• Which records will be excluded and why.
• Who approved each decision.
• How exceptions and unresolved data issues will be handled.

This prevents a technical decision from accidentally becoming a financial, operational or compliance decision.

7. Plan the cutover, test the migration and reconcile

A successful migration is not proven by seeing records appear in the new ERP. It is proven by showing that the right records arrived, that important relationships remain intact and that the business can continue operating correctly.

• Customer and supplier record counts.
• Outstanding receivables and payables by party.
• Stock quantity and valuation by item and warehouse.
• Bank and cash balances.
• General Ledger and Trial Balance totals.
• Open sales and purchase order quantities.

Step 6: Obtain business sign-off

Each data owner should approve their area after reviewing the relevant reports. Unexplained differences should be investigated rather than hidden in a suspense or adjustment account.

Step 7: Complete the final migration and monitor go-live

After final extraction and import, validate the production environment and monitor the first days of operations. Keep a record of issues, corrections and approved changes.

A migration is not complete when the import finishes. It is complete when the business can demonstrate that its opening position is correct, its important records are available and its teams can work confidently in the new system.

8. How ERPNext supports a structured migration

ERPNext provides tools and opening workflows that can support the transition from a legacy ERP. The migration design still needs to determine what should be imported, in which sequence and how the results will be verified.

Data Import for master records

ERPNext’s Data Import tool supports importing and updating records using CSV or Excel templates. It can be used for data such as customers, suppliers, items and other supported document types.

Templates, required fields, linked records and validation warnings should be reviewed before the import is run. The tool is not a substitute for cleansing or deciding which records belong in the new system.

Read the ERPNext Data Import documentation.

Opening balances for the financial starting point

ERPNext provides opening balance workflows for bringing forward approved balances. Depending on the data type, different methods may be required for outstanding invoices, stock, fixed assets, payments and other ledger balances.

These should be prepared from an approved cutover schedule and reconciled to the legacy system’s closing position.

See Opening Balance in Accounts and Opening and Closing.

Opening invoices for outstanding receivables and payables

Where invoice-level ageing and future settlement matter, the Opening Invoice Creation Tool can create opening sales and purchase invoices for outstanding balances. It preserves important references and dates for follow-up without recreating the entire historical sales or purchase workflow.

This distinction is important: an opening invoice is not the same as importing every historical invoice with its original item-level activity.

See the Opening Invoice Creation Tool documentation.

Reconciliation and controlled testing

Migration should include trial imports, exception review and reconciliation reports. ERPNext’s import validation can identify issues with templates and records, but the business must still verify the resulting balances and operational relationships.

We recommend documenting the source file, migration batch, control totals, review status and approver for each major data category.

Our implementation approach: use ERPNext’s import and opening tools where they fit the approved migration design, and define additional mapping, scripts or integration work only where the source data and business requirements call for it.

9. The old ERP still has a role after go-live

When the new ERP becomes operational, the old system does not necessarily become irrelevant overnight.

It may still be needed to answer questions about historical transactions, investigate disputes, retrieve supporting documents or provide information for audits and management reviews.

A sensible transition plan defines:

• Who can access the legacy system after cutover.
• Whether it will remain read-only.
• How historical reports and attachments can be retrieved.
• How long records must be retained.
• How backups, security and access controls will be maintained.
• When and under whose approval the old environment can be retired.

For some businesses, an archive or reporting environment may be more practical than keeping the entire old ERP running indefinitely. The choice should be based on retrieval needs, cost, security and retention obligations.

10. A practical ERP migration checklist

Before approving the final migration scope, we recommend confirming the following with the relevant business owners.

• Scope: Is there an approved list of data categories and historical periods to migrate?
• Master data: Have customers, suppliers, items and other core records been reviewed?
• Duplicates: Have duplicate and obsolete records been identified and resolved?
• Mapping: Are legacy codes, accounts, units and categories mapped to the new system?
• Opening position: Are balances and open transactions based on an approved cutover schedule?
• History: Is there a documented decision about which historical transactions move and which are archived?
• Retention: Have legal, tax, audit and contractual retention requirements been considered?
• Ownership: Does each data category have a named business approver?
• Testing: Has a test migration been completed and reviewed?
• Reconciliation: Do the source and target control totals agree?
• Cutover: Is there a documented final extraction, import and go-live plan?
• Archive access: Can authorised employees retrieve historical information after the old ERP is retired?

11. A better ERP starts with better migration decisions

Gulfline Trading’s migration is not successful because every old record appears in its new ERP. It is successful because the company knows which customer and supplier records are valid, which stock and financial balances are correct, which open transactions need attention and where older history can be found.

The business has also assigned people to approve those decisions. That is what turns data migration from a technical exercise into a controlled business transition.

Replacing an ERP is an opportunity to simplify the information environment, improve data quality and establish clearer ownership. The goal is not to carry the past forward unchanged. It is to preserve what matters while giving the business a cleaner foundation for the future.

Frequently asked questions

Planning to replace your ERP?

Before moving data, make sure you know what the business needs to retain, what should become part of the new system and who will approve the results. Craft Interactive helps businesses plan ERP transitions around their processes, data requirements and operational priorities.

Let’s discuss your current system, migration scope and the right path to a controlled ERP transition.

Talk to Craft Interactive

Further reading

• ERPNext: Data Import
• ERPNext: Opening Balance in Accounts
• ERPNext: Opening and Closing
• ERPNext: Opening Invoice Creation Tool