When your stock-on-hand figure differs between the warehouse spreadsheet, accounting system and production records, an ERP project has a data problem before it has a software problem. This ERP data migration guide is designed for operational businesses that need to move critical records without carrying years of duplicate customers, unreliable item codes and unbalanced financial history into a new platform.
Data migration is not simply exporting a spreadsheet and importing it elsewhere. It is the controlled process of deciding what information the new ERP needs, cleaning it, translating it into the new structure, validating the results and preparing people to use it correctly from go-live. For manufacturers, processors, retailers, labour-hire operators and multi-site businesses, this process directly affects invoicing, purchasing, scheduling, traceability, payroll-related workflows and management reporting.
Start with the operational outcome
A migration plan should begin with the decisions the new system must support. Finance may need accurate opening balances and outstanding receivables. Warehouse teams need trusted stock quantities, bin locations, serial or batch details, reorder settings and supplier information. Production teams may need bills of materials, routings, work centres, machine data references and quality checkpoints.
This is why a full historical copy is not always the best approach. Moving ten years of transactions can add cost, delay testing and make the new ERP harder to use. In many cases, businesses migrate open transactions, current master data, opening balances and a defined period of accessible history, while retaining the legacy system as a controlled read-only archive.
The right scope depends on regulatory obligations, customer traceability requirements, audit needs and how often staff genuinely refer to older records. A food processor with batch recall obligations will have different requirements from a professional practice migrating client billing and project data.
Assign owners before extracting anything
No implementation partner can determine whether a customer record is current, a stock code is obsolete or a bill of materials reflects the factory floor better than your team can. Assign a business owner to each data area: finance, customers and suppliers, inventory, sales, purchasing, production, projects and employee or labour records.
These owners should approve the migration rules, not merely review a final file under time pressure. IT can manage extracts, access and technical controls, but operational accountability belongs with the people who use the data every day.
Build a data inventory and migration rules
Create a practical inventory of every source system, spreadsheet and manual register that feeds the business. Fragmented environments often contain information in accounting software, point-of-sale tools, warehouse files, maintenance logs, production sheets and individual team folders. Recording the source, owner, format, refresh frequency and data quality gives the project an honest starting point.
For each data set, define one clear rule: migrate, transform, archive or retire. Avoid the common assumption that every field must be retained because it exists. A free-text note column with inconsistent entries may be better archived than imported into a structured field that users will rely on later.
Field mapping is where operational detail matters. A legacy item description may need to become separate fields for item name, product group, unit of measure, tax treatment, standard cost and replenishment method. Customer addresses may need delivery and billing locations separated. Employee or labour-hire records may require licence expiry dates, pay conditions, site eligibility and timesheet approval relationships.
Document every transformation rule. If leading zeroes are removed from item codes, units are converted, duplicate suppliers are merged or inactive products are excluded, record the decision and who approved it. These rules make test results explainable and stop the team from debating the same issue during cutover.
Clean data where it delivers operational value
Migration is a valuable opportunity to improve data, but perfection can become a costly distraction. Focus cleansing effort on records that affect transactions, compliance, reporting or customer service after go-live.
For example, standardise units of measure before loading inventory. A mix of “ea”, “each” and “units” can create purchasing and stock-control errors. Confirm that item codes are unique, tax settings are correct, supplier payment terms are current and customer credit limits reflect the approved policy. Remove duplicates only when the business can confirm they are truly duplicates; two similar company names may represent separate legal entities or delivery sites.
Production data needs extra attention. Bills of materials should reflect actual consumption, not an old engineering estimate. Routings should include realistic work centres, setup times and expected run times where planning depends on them. If the ERP will receive PLC or machine data, agree the asset identifiers, timestamp rules and exception handling before integration testing begins.
Do not use migration to quietly rewrite financial history. Opening balances and open items must reconcile to approved source reports. Corrections should be made through agreed accounting processes, with an audit trail, rather than hidden inside an import file.
Test migration in repeatable cycles
A single test import is not enough. Run several migration cycles using the same documented process, then compare results against source-system control totals. Test with a representative set of everyday and difficult cases: an overdue invoice, a credit note, a partly received purchase order, negative stock if it exists, a batch-tracked item, a multi-currency supplier and a production order already in progress.
Validation should be both numerical and operational. Finance should reconcile trial balances, aged receivables, aged payables and tax figures. Warehouse staff should spot-check item quantities, locations, lot numbers and valuation methods. Sales teams should confirm customer contacts, prices and open orders. Production supervisors should test whether planning, issue-to-production and finished-goods receipt transactions work as expected.
A useful control is to set acceptance thresholds before testing. You may require zero difference in general ledger balances, while allowing a small number of non-critical address formatting exceptions for remediation. Without thresholds, teams either reject workable results over minor formatting issues or accept serious discrepancies because the deadline is close.
Rehearse the cutover, not just the import
Go-live succeeds when the whole operating process is rehearsed. Plan when legacy transactions stop, when final extracts occur, who checks each load, how opening stock is verified and when users can start entering new transactions. Identify a clear decision-maker for each stage and set a fallback point if a critical control fails.
It is usually safer to freeze selected master-data changes shortly before cutover. Otherwise, the business continues creating new customers, items and price updates while the final migration is being prepared. The freeze period should be as short as practical and clearly communicated, particularly to sales, purchasing and warehouse teams.
Security deserves the same discipline. Migration files often include bank details, employee information, customer contacts and commercial pricing. Limit access, encrypt files in transit and at rest, use controlled storage, and remove temporary extracts when they are no longer required. Managed cloud security and role-based access help protect the new environment, but the project also needs sensible handling procedures from day one.
Support the first weeks of live operation
The first fortnight after go-live is where data quality becomes operational confidence. Establish a daily review of failed imports, unmatched transactions, stock variances, integration exceptions and user questions. Prioritise issues that stop billing, dispatch, payroll-related administration or production recording before improving reports or screen layouts.
Keep a formal issue log with an owner, severity, decision and resolution date. This prevents workaround habits from becoming permanent. If a team starts maintaining a parallel spreadsheet because a report is unfamiliar, address the reporting requirement and training gap rather than allowing disconnected data to return.
For businesses using Power BI, AI-assisted workflows or industrial integrations, phase advanced capability sensibly. The initial priority is accurate core transactions. Once finance, inventory, production and sales records are trusted, analytics, voice bots, carbon accounting and machine-driven automation can be configured on a dependable data foundation.
OneBusiness implementations can be configured around industry workflows, but configuration only produces value when the information entering the system is governed and understood. The most successful migrations treat data as an operating asset, not an IT handover.
A well-run migration gives your team more than a clean start. It gives them a shared version of stock, cash, jobs, customers and production performance – the control needed to make quicker decisions with confidence.
