Nobody's implementation failed because the software was bad
I've been in the SAP Business One world for years. I've seen implementations that went beautifully and ones that became cautionary tales. Here's the pattern nobody wants to talk about: not one of the failures was because SAP B1 couldn't do the job. The software is solid. It's mature, it's proven, it handles what it promises.
Every single failure I have witnessed came down to data. Specifically, the moment -- usually about three weeks before go-live, always too late -- when everyone discovers that the "clean" spreadsheets they've been working from are anything but clean. Duplicate items. Phantom customers. A chart of accounts that maps to nothing in the new system. Years of accumulated shortcuts, workarounds, and "we'll fix it later" decisions, all surfacing at once.
Data migration isn't the exciting part of an ERP implementation. Nobody demos it at conferences. No consultant leads with it in a sales pitch. But it's the phase that decides whether go-live is a celebration or a crisis. Here's what actually goes wrong and the fixes that work.
The item master: where good implementations go to die
The item master is the foundation everything else stands on -- inventory valuations, purchasing, sales orders, production, MRP. Every transaction touches it. And in most companies I walk into, it's a disaster.
The usual suspects: duplicate items ("WIDGET-001" and "Widget 001" and "WIDGET001" -- three records, one physical thing), descriptions in three different conventions (one of them the previous owner's personal shorthand that nobody else understands), units of measure that change by row (each, box, case, pallet -- sometimes on the same item), and pricing that's been manually overridden so many times nobody knows what the real price is anymore.
I audited one distributor with 14,000 item records. After deduplication: 8,200 real items. Over 40% of their item master was ghosts -- duplicates, discontinued products nobody removed, test records from 2019. They'd been carrying that dead weight through every inventory count, every purchasing decision, every financial report for years.
The fix isn't technical -- it's janitorial, and that's why everyone underestimates it. Before migration: deduplicate aggressively (fuzzy matching software catches what tired eyeballs miss -- budget for a tool, not just eyeballs), standardize every description with a naming convention you'll enforce forever after, and lock down units of measure to one per item with proper conversion factors.
Budget two to four weeks for a mid-size company. Everyone thinks this is excessive until they see the duplicate report. Then they wish they'd budgeted six weeks and started earlier.
The rule I give every client: if you wouldn't trust the spreadsheet to run the business today, don't migrate it and hope the ERP fixes it. The ERP amplifies whatever you feed it. Clean data in, clean system out. Garbage in, expensive garbage out -- and SAP B1 licenses aren't cheap enough to waste on amplifying garbage.
Duplicate business partners: the silent revenue killer
"We have 1,200 customers" usually means 800 real customers, 300 duplicates, and 100 records nobody can identify with confidence. "ABC Corp," "ABC Corporation," "ABC Corp." -- three records, one customer, three different payment histories scattered across the system. Your aging report is fiction. Your sales analysis by customer is fiction. Your credit limit enforcement is a suggestion. Nobody knows what's real.
The cleanup is tedious but mechanical: export the full business partner list, sort by name, tax ID, and phone number -- those three fields catch roughly 90% of duplicates. Merge ruthlessly. One record per real-world entity, no exceptions, no "but the Chicago office likes it separate." Then set the precedent going forward: new business partners get created through a defined process with a duplicate check, not by whoever's in a hurry on a Friday afternoon.
The payoff is immediate and sometimes dramatic. The first clean aging report a client sees usually surfaces real money -- the overdue balance that was split across two duplicate records, invisible to collections until someone merged them. I've seen a $47,000 overdue balance hiding across three duplicate customer records. Data cleanup literally pays for itself in found revenue. I've watched it happen a dozen times and it never gets old.
Vendors need the same treatment. Duplicate vendor records mean duplicate payments -- the same invoice paid twice because it was entered under two different vendor names. That's not a theoretical risk. That's a Tuesday in companies with messy vendor masters.
Chart of accounts mapping: the translation nobody wants to do
Your old system's chart of accounts and SAP B1's don't speak the same language. Account 4100 means "office supplies" in QuickBooks and "freight expense" in the new SAP B1 setup. Account 1200 is "accounts receivable" in one and "inventory" in the other. Somebody has to build the translation map -- account by account, every single one, no shortcuts.
This is the task everyone postpones because it's boring, it requires the accountant's time, and the accountant is always busy with month-end. Then migration week arrives, the mapping is half-done, and opening balances land in the wrong accounts. Reversing misposted opening balances takes roughly ten times longer than building the map correctly the first time. I've seen a controller spend three weeks untangling what a proper two-day mapping exercise would have prevented.
Do it early -- like, first-month-of-the-project early. Do it with the accountant physically in the room, not via email. Every account in the old system gets exactly one home in the new system. No "we'll figure it out later" accounts, no suspense accounts that become permanent. Later never comes, the auditors always notice, and the cleanup always costs more than the planning would have.
The 80/20 of migration testing
You can't test every record -- a mid-size company might migrate 50,000+ master data records and hundreds of thousands of transactions. But you can test the ones that determine whether the business can operate on Monday morning.
My 80/20 test protocol: your top 20 customers by revenue (are their balances correct to the penny?), your top 50 items by transaction volume (quantities and costs right?), and one full month of transactions reconciled end-to-end from the old system to the new. If those are clean, the rest is almost certainly fine. If those are wrong, stop. Do not migrate and hope. Hope is not a migration strategy.
I also insist on a full trial migration to a test database, always, no exceptions. Not a demo with sample data -- a complete trial migration with real production data, run two weeks before go-live. Every trial migration I have ever run has found something: a mapping error, a duplicate that slipped through, a custom field that didn't transfer. Every single one. The companies that skip the trial find the same issues on go-live Monday, except now the phones are ringing, orders are stuck, and the warehouse is standing around.
The trial migration costs a few days of consultant time. The go-live crisis it prevents costs weeks and sometimes the entire project timeline.
The bottom line
Data migration isn't the exciting part of an ERP implementation. Nobody demos it. Nobody brags about it at conferences. Nobody's LinkedIn headline says "Data Migration Specialist" (though maybe it should).
But it's the phase that decides whether go-live is a celebration or a crisis. Clean the items, merge the partners, map the accounts, test with real data, run the trial. Boring work, boring go-live -- and boring is exactly what you want when you're flipping the switch on the system that runs your business.
