Data Migration Horror Stories (And How to Avoid Becoming One)

Data migration goes sideways when you try to move everything at once without mapping fields first. The fix: map every field before you import, test in a copy of the database, and move one module at a time. Slow is smooth, smooth is fast.

I once watched a client migrate three years of customer data from spreadsheets into Odoo in a single weekend. One weekend. Three years of data. The field types did not line up, half the dates came in as text, and the import tool rejected 4,000 rows. They spent the next two weeks untangling it.

Here is the truth nobody on the sales call tells you: data migration is not a technical task. It is a business task. The software part is easy. Knowing what your data actually means is the hard part.

Horror story #1: the big-bang import

A distributor came to me after their first migration attempt failed. Their team had dumped every spreadsheet they owned into Odoo at once, customers, vendors, items, open invoices, history. Odoo's contact model splits names into first and last. Their old system stored full names in one field. Phone numbers had extensions glued on. SKUs were inconsistent. The import blew up in a dozen ways, and because everything went in together, nobody could tell which failure caused which.

We scrapped it and started over. One module at a time. Customers first. We mapped every column to its Odoo field, ran a small batch of 50 records, and fixed the mapping before touching the rest. Then vendors. Then items. Boring? Completely. It worked? Completely.

Horror story #2: the dirty-data denial

A services company insisted their data was clean. "We keep good records," they said. Their records had three different spellings of their biggest client, duplicate vendors with different payment terms, and price lists that had not been updated since 2019. Garbage in, garbage out, and an ERP does not forgive garbage. It institutionalizes it.

The rule: if you would not bet money that a record is correct, do not migrate it. Archive it or leave it behind. A fresh start with clean data beats a faithful copy of a mess.

The playbook that actually works

1. Map fields first, import second. Before you touch the import tool, make a spreadsheet that maps every old column to its Odoo field. No mapping, no import.

1. Test in a copy. Never import into the live database first. Load your data into a test copy, check the results, then do it for real. Two passes costs you an afternoon. One botched pass costs you weeks.

1. One module at a time. Customers, then vendors, then items, then open transactions. If one import fails, the rest are untouched.

1. Clean before you move. Duplicates, stale records, dead contacts, deal with them in the old system, not in Odoo. Migration is the one time you get to start fresh. Take it.

1. Keep the old system readable. Do not delete the legacy data until the new system has run a full financial close. You will need to cross-check something. You always do.

Where this fits in the ERP decision

Here is the part that matters for the Odoo vs. SAP Business One question: migration complexity is a function of your data, not your software. A small business with clean data migrates to Odoo in days. A small business with dirty data has a dirty-data problem, not a software problem. Picking a bigger, more expensive system does not clean your data. It just gives you a more expensive place to store the mess.

Odoo's open model is an advantage here: you can stand up a test database, run imports, break things, and start over without license-meter anxiety. Use that. The freedom to experiment is the cheapest insurance in the project.