A failed data migration isn’t just a few incorrect records in the new system. It can mean inventory that doesn’t match reality, unreconciled accounting balances, orders that can’t be delivered, and teams reverting to Excel files. That’s why the question “how do you migrate data” needs to be treated as an operational decision, not just a technical task before go-live.
For a company implementing an ERP, migration is the moment when information from disparate systems becomes a single foundation for finance, sales, procurement, production, warehousing, and reporting. The outcome depends less on how fast a file gets imported and more on the quality of the decisions made before, during, and after the import.
How to Migrate Data in an ERP
A controlled migration starts with clearly defining its scope. Not all historical data needs to be moved. A distribution company may need complete master data, open balances, current inventory, prices, commercial terms, and the historical data relevant for analysis. On the other hand, documents closed ten years ago can stay archived in the old system, if legislation and audit requirements allow it.
This choice reduces the cost, duration, and risk of the project. Especially for organizations that grew through acquisitions, used different applications across departments, or worked for years with local files, the volume of data can hide many exceptions. Complete migration is not automatically correct migration.
In a SAP Business One project, the migration plan must be aligned with the processes configured in the new ERP. If the item structure, units of measure, chart of accounts, warehouses, or approval rules have changed, the old data cannot simply be copied over. It must be transformed so that it works within the new operational model.
Establish Data Owners, Not Just the Technical Team
IT can extract the data, but it can’t decide on its own whether a customer record is a duplicate, whether an item is active, or whether an invoice has the correct classification. Every domain needs a business owner: finance for balances and the chart of accounts, sales for customers and pricing, logistics for items and inventory, operations for industry-specific workflows.
These owners validate the transformation rules and sign off on the test results. Without this distributed responsibility, the project team ends up rushing decisions that should have been made by the managers who understand day-to-day operations.
An implementation partner such as Serra Software can organize the process, propose loading methods, and identify integration risks. However, final data validation belongs to the company that uses that data with its customers, suppliers, banks, and authorities.
Start With a Source Inventory and Data Cleansing
The first practical step is a source inventory. Data can come from a legacy ERP, an accounting application, an e-commerce platform, a WMS, CRM systems, in-house databases, and Excel files. For each source, you need to document the available fields, the data owner, how often it’s updated, coding rules, and known issues.
Cleansing comes next. This is where most of the benefits emerge, but also where the most uncomfortable discussions happen. For example, the same company might be registered three times under slightly different names, and the same product might have different codes in purchasing, warehousing, and sales. If these inconsistencies are imported without rules, the new ERP will simply reproduce the old confusion in a new interface.
Cleansing involves removing duplicates, filling in mandatory fields, standardizing addresses, verifying tax codes, normalizing units of measure, and establishing a naming convention. For items, you also need to clarify whether an old code is active, replaced, or should be blocked. For business partners, contacts, billing addresses, and shipping addresses need to be separated.
Don’t turn this stage into an open-ended exercise. Set clear rules and a decision threshold. If a piece of information can’t be confirmed, it can be flagged for review, excluded from the first load, or kept only in the archive, depending on its impact on operations.
Map the Data to the New Structure, Not to the Old Screen
Mapping explains the relationship between the fields in the source and the fields in the new ERP. It’s the document that answers simple but critical questions: where does the customer code end up, how is VAT translated, which warehouse corresponds to each location, and how are values converted into the reporting currency.
Good mapping also includes transformation rules. A common example is converting payment codes or product groups. In the old system, a field might contain inconsistent values like “30 days,” “30D,” “OP30,” and “monthly.” In the new system, these need to be mapped to a standardized value, approved by finance and used consistently across documents and reports.
Pay attention to data that depends on other data. You can’t correctly load sales invoices before the customers, items, accounts, taxes, and payment terms they depend on exist. Load order matters. Generally, master data is loaded first, followed by opening balances, inventory, and open documents, and finally the data needed for reporting or the selected historical records.
Test the Migration as a Business Process
A technical import that completes without errors doesn’t prove the migration is correct. Data needs to be tested in real scenarios: issuing an invoice, receiving an order, reserving inventory, recording a payment, calculating VAT, closing a period, and generating a management report.
The recommendation is to plan at least two test cycles. The first identifies structural, rule-based, and data quality issues. The second confirms that fixes work and that business teams can validate the results. For companies with complex processes, a go-live simulation test is essential: the load is run within a timeframe close to the planned launch, and the time required is measured.
Checks need to be measurable. Verifications worth documenting include:
- the number of customers, suppliers, and items imported, compared against the source;
- total balances across customers, suppliers, bank accounts, and general ledger accounts;
- inventory quantities and values by warehouse, item, and batch, where applicable;
- the number and value of open documents, including invoices, orders, and delivery notes;
- key reports compared between the old system and the new ERP.
Discrepancies shouldn’t be hidden in a technical spreadsheet. Every discrepancy needs an explanation: source error, transformation rule, different reference date, rounding, or intentional exclusion. Only discrepancies that have been explained and approved can be accepted.
Plan the Go-Live and Stabilization Period
The go-live date needs to be set according to the company’s rhythm. For a retailer, a peak season or the annual inventory count are risky choices. For a manufacturing company, the switch needs to be coordinated with work orders in progress, material consumption, and capacity planning. For a service business, month-end close may be a safer reference point than a date chosen purely based on technical availability.
The cutover plan needs to specify when updates to the old system stop, who performs the final data extraction, who validates the files, in what order the data is loaded, and what the acceptance criteria are. A rollback plan should also be defined, even if the goal is never to use it. If a critical issue arises, everyone needs to know who makes the call, which operations can continue manually, and how instructions are communicated to users.
After launch, the migration isn’t fully finished. The first few days bring exceptions that don’t show up in testing: a special document, a rare business rule, an integration sending an unexpected code. A stabilization period with fast support, error monitoring, and daily reconciliation protects operations and user confidence.
A well-run migration delivers more than accurate data in SAP Business One. It brings order to master data, clarifies responsibilities, and builds the discipline needed for credible management reports. Treat it as the first proof that the new ERP can support the company’s growth – through data that teams can use, verify, and turn into fast decisions.
