Ask anyone who has been through an ERP implementation what went wrong and the answer is usually data. Not the configuration, not the training. The customer list with four versions of the same company, the item master with units that meant different things in different warehouses, the opening balances that did not tie out until three weeks after go-live.
We treat migration as a project inside the project. This is the checklist we work from.
1. Decide what moves
Not everything should come across. For each category, decide: migrate as live data, migrate as history, or leave in the old system for reference.
Master data (always migrate)
- Chart of accounts, mapped to the new structure rather than copied as is
- Business partners: customers, vendors, leads, with contacts, addresses, payment terms and price list assignments
- Items: codes, descriptions, units of measure, barcodes, item groups, warehouses, costing method
- Price lists and special prices
- Bills of materials, if you assemble or kit
- Employees, sales reps and territories where they drive commissions or reporting
Opening balances (always migrate)
- General ledger trial balance as at cutover
- Open accounts receivable, invoice by invoice, so statements and collections work from day one
- Open accounts payable, invoice by invoice
- Inventory quantities and values by warehouse, and by batch or serial where tracked
Open transactions (usually migrate)
- Open sales orders, so the warehouse keeps shipping
- Open purchase orders, so receiving keeps working
- Open quotes worth keeping
History (decide deliberately)
Sales history is valuable for reporting and for reps, but bringing years of invoices into the new system as posted documents is expensive and creates reconciliation work. The common compromise is to load summarized history, keep the old system available read-only for a period, and migrate detailed history to a reporting database rather than into SAP Business One.
2. Clean before you load
Loading dirty data into a clean system wastes the clean system. Before any import:
- Deduplicate business partners. Same company under three names, or a customer that is also a vendor, needs one decision per case.
- Standardize item codes and descriptions. Decide the naming convention now; changing item codes later is painful.
- Fix units of measure. Each, case, pallet, and the conversions between them, defined once per item.
- Retire dead records. Customers with no activity in years and items with no stock and no sales can be archived rather than migrated.
- Complete missing fields. Payment terms, tax codes, price list assignments and item groups are cheap to fill in a spreadsheet and expensive to fix document by document afterwards.
- Agree the barcodes. One primary barcode per item and unit, verified against what is on the physical product.
3. Map the fields
Every source field maps to a destination field, a default value or a decision to drop it. The mapping document is a deliverable in its own right. It names the source, the destination, the transformation and the owner who signs off. When someone asks six months later why a customer's credit limit is what it is, the mapping document answers.
SAP provides the Data Transfer Workbench for bulk imports through templates, and the Service Layer and DI API for more complex loads. The tool matters less than the discipline around it.
4. Load in rounds
Never migrate once. Migrate at least three times.
- Trial load into a test company with a sample of every record type. This finds mapping errors and template problems.
- Full rehearsal with complete data, timed, followed by validation by your team. This finds data quality problems and gives you a real cutover duration.
- Cutover load on the agreed date, using the rehearsed procedure and the timing you now know.
If the full rehearsal takes fourteen hours, you know cutover will not fit in an evening, and you plan accordingly.
5. Validate with the people who own the numbers
Validation is not the implementation partner ticking a box. It is your finance lead confirming that the trial balance ties out, your warehouse lead confirming that stock counts match, your sales lead confirming that price lists are right for the top customers. Each sign-off is written down.
Checks we run every time:
- Trial balance in the new system equals the closing trial balance in the old system, account by account
- Total open receivables and payables equal the old system's aged reports, and a sample of individual invoices match
- Inventory quantity and value by warehouse equal the old system after any physical count adjustments
- Item counts, business partner counts and price list line counts match the cleaned source
- Sample documents recreated end to end: a quote to invoice, a purchase order to vendor invoice
6. Plan the cutover
Cutover is the sequence of steps between the last transaction in the old system and the first transaction in the new one. It is written down, with an owner and a time for each step, and it is rehearsed.
- Freeze date and time for the old system
- Final extract of master data and balances
- Load, validate, sign off
- User access switched on
- First transactions in the new system watched closely
- Old system set to read-only, not switched off
Have a rollback decision point. If validation fails at cutover, you need to know in advance who decides to continue or revert, and by when.
7. Watch the first close
Go-live is not the end of migration. The first month-end close is where migration errors surface: an opening balance in the wrong account, a customer with the wrong terms, an item costed incorrectly. Plan for the implementation team to be available through that first close, and treat the issues it surfaces as migration issues to be fixed properly rather than adjusted around.
The short version
Decide what moves. Clean it first. Map every field. Load three times. Validate with owners. Rehearse cutover. Stay through the first close.
If you are planning an SAP Business One implementation and want to talk through the data side before anything else, we are happy to do that. It is the conversation that most often changes the plan for the better.