ERP data migration: which records to move and how to check cutover

Which data should move into a new ERP first?

Move the records needed to run the first live workflow: active customers and suppliers, open jobs or orders, their dependent records and the history staff need to work correctly. Preserve other required history in an accessible archive. Before switching, test the import, reconcile the data and agree how to recover if cutover fails.

For an operations head or founder planning a custom ERP, the first migration question is practical: can the team complete tomorrow’s work with what will be in the new system?

Moving the whole database does not answer that question. Neither does moving a small customer list while leaving out the rate sheets, documents or unpaid invoices those customers’ jobs depend on. The right scope follows the workflow and its dependencies.

Name the first workflow and its system of record

Write down where the workflow starts, where it ends and which system owns each part after launch. For a freight forwarder, the first release might cover sea-export booking through job closing, with accounting remaining in an existing finance system.

That boundary changes the migration. Operational job details may move, while accounting references and reconciled balances are connected or displayed without creating a second accounting ledger. If finance is moving too, the balance and transaction treatment needs its own approved design.

List the screens, documents, reports and integrations users need to finish that workflow. Then trace the supporting records. An open shipment might require a customer, consignee, supplier, currency, rate, document and approval status. Each necessary dependency belongs in the scope, even if a simple “active customer” filter would exclude it.

Divide the records into three working groups

Active reference records

These are the customers, suppliers, items, rate sheets and other master records the first workflow will use. Define “active” in writing. Recent activity or an open balance can be useful criteria, with exceptions for records required by open work.

Keep the definition specific to the business. “A transaction in the last 18 months” is a possible rule to assess, not a universal standard. An infrequent customer with an unresolved job may still need to move.

Open work and balances

Include jobs, orders, bookings and other transactions that remain operationally or financially incomplete. Capture their current stage, supporting documents, partial costs, receipts and outstanding actions where those belong in the new workflow.

Decide how open invoices, payments and opening balances will be represented. Importing both detailed transactions and an overlapping opening balance can count the same amount twice. Finance should approve the treatment before the load is built.

History needed inside the new system

Identify what users must look up for customer service, repeat work, reporting or review. Separate that operational need from the requirement to retain records somewhere accessible.

Finance and the appropriate advisers should confirm applicable retention and access requirements. Do not assume that an illustrative migration window, such as the current and previous financial year, establishes a retention period or permits deletion of older records.

For records staying outside the new ERP, document where they live, who can retrieve them and how attachments are found. Test retrieval before retiring access to the old system.

Preserve the links back to the original records

Give every imported record a reliable mapping from source system and source ID to target ID. Include the source system because two spreadsheets or databases may use the same number for different records.

Keep that mapping after launch. It supports reconciliation, customer queries, later migration phases and investigation of a failed import. If several records are merged, preserve the original IDs and the approved merge decision.

Deduplicate before loading, with uncertain cases routed to an owner. Matching names or addresses can suggest a duplicate, but should not silently merge separate legal entities, branches or accounts. Even where a business identifier helps, confirm how that identifier is used in the source data and target model.

Make the import safe to rerun. A corrected trial load should update or replace the intended test records rather than silently creating a second copy. Record rejected rows and their reasons so they can be corrected and checked.

A hypothetical freight-forwarding migration

Consider a Mumbai freight forwarder using an older operations system, Excel job sheets and Tally. This example illustrates a migration design; it does not describe a SolvTree client deployment.

The first release covers sea-export operations. The team includes customers with relevant recent work or open receivables, then adds any other parties referenced by open sea-export jobs. Air-only records wait unless a shared dependency makes them necessary now.

Open jobs move with their existing job numbers, operational status, container details, available documents and approved cost information. Selected closed jobs move as read-only reference history. Older records remain in a tested archive.

Operations and finance approve a mapping between customer IDs, job IDs and the relevant Tally ledger references. Similar shipper names are reviewed rather than merged automatically. The import preserves a traceable link to every source record.

In the trial environment, the team compares open-job counts, financial values within the agreed scope and the relationships between jobs and customers. Staff inspect representative jobs at different stages, including unusual or partly completed cases. A random sample can add coverage, but it should not replace deliberate checks of known risks.

Finally, a user runs a booking through the full intended workflow. This can reveal missing rates, permissions or documents that a record-count comparison would miss.

Agree the acceptance checks before the final load

A successful import message means the load ran. Business acceptance needs a separate set of checks:

• Completeness: expected records loaded, rejected rows resolved and required attachments accessible.
• Relationships: every child record points to the correct customer, order, job or other parent; no unexplained orphan records remain.
• Counts and status: totals match the agreed source extract, and open work has the intended stage.
• Financial values: relevant totals reconcile by customer, supplier, currency and other necessary dimensions, without overlapping balances.
• Traceability: users can follow target records back to source IDs and approved mappings.
• Usability: operations and finance can complete representative tasks with the permissions they will have after launch.

Agree tolerances and the treatment of expected differences in advance. Do not invent a tolerance on cutover day to make an unexplained discrepancy pass. Name the person who signs off each check and the person who can stop the switch.

Separate a pre-live abort from a post-live rollback

Before the final extract, define a cut-off and how late changes will be handled. This may mean a controlled write pause or a tested method for capturing changes since the trial extract. Rehearse the sequence and verify that backups can be restored.

If acceptance checks fail before the new system takes live work, abort the cutover under the agreed plan. Confirm which system resumes writes and who tells the team. Correct the problem before trying again.

After go-live, the problem is different. New jobs, approvals, invoices or status changes may exist only in the new ERP. A rollback must stop further conflicting writes, preserve those changes, reconcile them and transfer them through an approved recovery process. Only then can the previous system resume responsibility.

Do not allow both systems to become independent writable sources for the same work. Keep the old system read-only for reference where appropriate, and specify who handles exceptions during the initial support period.

When to expand the migration

Move more data when a defined workflow or reporting requirement needs it. An air-freight release may need additional customer and job records. A profitability report may need older cost history, with a validation plan for that history.

An automation layer may be enough if the existing systems work and the main problem is repeated copying between them. A custom ERP is worth evaluating when the core workflow, permissions and reporting cannot be supported reliably by the current setup.

SolvTree’s custom ERP systems and integration and scoped delivery approach provide a starting point for that assessment. Bring the first workflow, source systems and open-work categories to an ERP migration scoping conversation. Those inputs make it possible to discuss what must move, what can remain accessible elsewhere and how a safe switch would be tested.