The Odoo data migration nobody budgets for
Moving the data is a week of work. Deciding what your data actually means, and fixing twelve years of accumulated inconsistency, is the project.
Data migration is quoted as a technical task and behaves like an archaeology project. The technical part is genuinely straightforward: read from the old system, map the fields, load into the new one. A competent person can do that in days.
What takes months is that your existing data does not agree with itself, and nobody has had to confront that until now.
What you find when you look
Every business that has been running more than a few years has the same set of discoveries waiting. They are not signs of a badly run operation; they are what happens when a system is used by real people under time pressure.
The same product exists three times. Once with a supplier code, once with a customer’s code, once with a typo. All three have stock against them. All three have sales history.
Customers are duplicated by punctuation. The same company as a limited, a Ltd, a Ltd. and once in capitals. Which one has the credit terms on it is anyone’s guess.
Units of measure are inconsistent. Something bought by the pallet, stocked by the carton and sold by the each, with a conversion held in someone’s head.
Codes carry meaning that is not in a field. A prefix that indicates a product range, a suffix that means seconds or clearance, a code beginning with X that everyone knows means do not reorder. None of this is data the old system understands and all of it is data the business relies on.
Historic transactions reference things that no longer exist. Suppliers gone, products retired, a warehouse that closed in 2019.
The decisions those force
Each of the above is a business decision disguised as a data problem, and nobody in IT can make it.
Which of the three product records is the real one, and what happens to the sales history on the other two? Does the range prefix become a product category, a tag, or nothing? What is the conversion factor, definitively, and who signs off on it?
This is the actual work, and the only people who can do it are the ones who use the data. It cannot be delegated to the implementer, and an implementer who says they will sort it out is either going to guess or going to come back with questions later at a worse moment.
How to make it manageable
Clean in the old system, not the new one. Deduplicating in the system people already understand, before the migration, is faster and safer than doing it after. It also means the old system stays usable as a reference.
Decide what you actually need to carry across. Open transactions and current master data, almost always. Full transaction history, usually not. Keeping the old system readable for historic enquiry is far cheaper than migrating twelve years of journal entries and reconciling them, and it is what most businesses end up doing anyway.
Take opening balances rather than history where you can. Stock on hand as a counted figure at go-live. Debtors and creditors as open items. It makes the first month reconcilable, which is the thing that matters.
Migrate more than once. A trial load, checked by the people who know the data, weeks before go-live. Then a second. Then the real one. The first trial always finds things, and finding them in a sandbox is the entire point.
Give someone the job of signing it off. Not a project manager. A person from the business who is prepared to say the product list is right.
What it costs if you skip it
The system goes live with data nobody trusts, so people keep the spreadsheet running alongside it, and within six months you have paid for an ERP and are still reconciling by hand.
That is the actual failure mode of most ERP implementations, and it is a data decision made too late rather than a software problem.
How we scope it
Separately from the build, and with a stated assumption about the state of your data that we then check early rather than discover late. If the cleanup turns out to be larger than expected, that is much better as a conversation in week two than as a delay in month five.