The meeting where the number looks great
I have sat in this meeting more times than I can count, on both sides of the table.
The proposal looks clean. Software: handled. Services: a tidy block of hours. Go-live: a confident date a few months out. Everybody shakes hands, and somebody — usually the owner — says the sentence that should make any honest implementer sit up straight: "And our data just moves over, right?"
"Sure," is the answer they get. "We do an extract, some mapping, an import."
Here is what that sentence is hiding. The first real extract out of a legacy system is an archaeological dig. The same customer exists four times because four different people typed the name four different ways. Vendors who went out of business during the flip-phone era are still sitting there, active. There are items in the master that nobody can identify — the description field says "MISC" or somebody's initials. Units of measure are a crime scene: the same product sold by the each, the case, and something called "BX?" that exactly one retired employee understood.
None of that is the software's fault, and none of it is unusual. It is what ten or fifteen years of doing business looks like when nobody's job was keeping the masters clean. But it is all billable reality, and if it is not in the budget as its own line, it does not disappear. It just shows up later, wearing a fake mustache, calling itself a "go-live delay."
Migrating is moving house, and nobody budgets the attic
Think about moving house. The quote from the moving company covers the truck and the crew. It does not cover the weekend you should have spent cleaning out the attic before they arrived.
You have two choices. You can pay movers to box up fifteen years of accumulated stuff — including the broken lamp, the three paint cans from a room that is no longer that color, and a box labeled "cords" that nobody has opened since two houses ago — and then unpack all of it into the new place, where it will occupy your new garage exactly the way it occupied the old one. Or you can do the honest sort first: keep, donate, trash. The sort is work. It is also the only part of the move that actually improves your life.
An ERP migration is the same decision with databases. "Lift and shift everything" sounds cheaper because the cleanup line is zero. It is not cheaper. It just defers the sort to the most expensive possible moment — after go-live, when your team is trying to run a business on the new system and every duplicate customer and mystery unit of measure is now a live operational problem instead of a weekend chore.
The cleanup list nobody puts in the proposal
Here is the work, itemized the way it should appear in your budget.
Deduplicate the masters. Customers, vendors, items. The same business partner under multiple spellings splits your sales history, your credit picture, and your reporting. Merging them is judgment work, not button work — somebody who knows the customers has to say which record survives and which balances and contacts fold into it.
Kill the dead records. Items with no movement in years. Customers who bought once, a decade ago, from a salesperson who retired. Vendors you will never order from again. Every dead record you migrate is a record your team will trip over in the new system forever. Archive them outside the new system if you need the reference. Do not move them in as live data.
Decide how much history actually moves. This is the most consequential call in the project, and it should be a decision, not a default. Moving every transaction since the beginning of time is slow, expensive, and mostly pointless — almost nobody runs operational reports against seven-year-old invoices inside the ERP. The common pattern: bring opening balances and a defined window of recent history into the new system, and keep the old system (or a clean archive of it) available read-only for the lookups and the auditors. Decide the window on purpose, with your accountant in the room.
Fix units of measure and item codes. If your items carry three different units for the same thing, or codes whose meaning lives in a retired employee's head, the new system inherits the confusion at full price. Cleaning this means agreeing on one unit scheme and sane codes before the import — not discovering mid-cutover that "case" means 12 to purchasing and 24 to the warehouse.
Map the chart of accounts like it matters. Your legacy chart grew over years — an account for this, a near-duplicate for that, a few nobody can explain. Mapping it to the new chart is a workshop with your finance lead, not a spreadsheet someone fills in alone. Every account needs a deliberate destination or a deliberate burial, because this mapping decides what your financial reporting looks like for the next decade.
Close out the open documents. Open purchase orders, open sales orders, open invoices, half-received shipments — they do not migrate themselves. Each one gets closed, completed, or consciously carried into the new system with a plan. Discovering two hundred stale open orders on cutover weekend is a tradition I would love to see die.
Validate the trial balance before cutover. Not after. Before. The opening trial balance in SAP Business One has to tie to the closing trial balance in the old system, account by account, and somebody signs off on the differences they can explain. This is the cheapest insurance in the entire project, and it is the step rushed projects skip — right before they spend weeks arguing about whose numbers are wrong.
Put a name and a date on it
Cleanup fails as a concept and succeeds as an assignment. Three things make it real.
Give it an owner on your side. Not the partner — you. The partner knows the target system. Your people know that "ACME," "Acme Inc," and "ACME (old)" are the same customer. Cleanup needs one named person with the authority to say "this record dies."
Start it months before cutover, in the old system. The work is faster and cheaper where the knowledge lives, and it can run in parallel with configuration and training instead of competing with them on the one weekend everything must go right.
Freeze the mess factory. Agree on standards for new customers, vendors, and items the day the project starts — naming, units, required fields — or your team will manufacture fresh duplicates faster than the cleanup crew can kill them. Cleaning without a freeze is mopping with the tap running.
The bottom line
The data cleanup is not a surprise cost. It is a predictable cost that proposals leave invisible because a smaller number wins the signature. Then it arrives anyway — as delay, as weekend work, as a new system that feels suspiciously like the old one's problems with better fonts.
Budget it as its own line item. Owner, start date, and a number you chose with your eyes open. Your go-live date will suddenly become the most honest thing in the proposal.
Frequently asked questions
How much history should we actually move into SAP Business One?
Less than you think, decided on purpose. The usual pattern is opening balances plus a defined window of recent transaction history in the new system, with everything older kept in an archive or the legacy system in read-only form for lookups and audits. Moving a decade of transactions is slow and expensive, and almost nobody runs daily operations against it. Pick the window with your accountant, not by default.
Who should own the data cleanup — us or the partner?
You should, with the partner guiding. The partner knows the target system and the import mechanics, but only your people know your customers, your items, and which of those three similar vendor records is the real one. Cleanup is judgment work about your business, so it needs a named owner on your side with authority to merge and delete.
Can we just clean the data after we go live?
You can, and plenty of companies do — but you will pay for it twice: once in the migration, when the dirty data complicates testing and cutover, and again in daily operations, when duplicates and bad units of measure are live problems instead of a pre-project chore. Cleaning in the old system, before the move, is the cheapest version of the work that exists.
What should we clean first?
Start with the masters: customers, vendors, and items. Deduplicate them, deactivate the dead records, and agree on one unit-of-measure scheme. Then map the chart of accounts with your finance lead, work down the open documents, and finish with trial-balance validation. Masters first because everything else — history, balances, open orders — hangs off them.
Why didn't the original quote include any of this?
Because cleanup hours are the easiest line for a quote to omit and the hardest for a buyer to compare. Software and services look similar across proposals; cleanup depends on the state of your data, which nobody has looked at yet when the quote is written. Ask for it as a separate line — even an estimated range with the assumptions written down — and you will learn a lot about how honest the rest of the proposal is.
