Migration is not upgrading

Two words get used interchangeably and mean very different things.

Migration is moving from a different system into Odoo. From spreadsheets, from Tally, from SAP, from a homegrown application.

Upgrading is moving from one Odoo version to a newer one.

This article is about migration. Upgrading is a separate topic with its own risks.

The part people underestimate

Ask anyone who has done this: the software is not the hard part.

The data is. Cleaning it, deciding what comes across, agreeing which file is authoritative, and getting your accountant to sign off the opening balances.

Most migration projects that go badly went badly here. The configuration was fine. The data going into it was not.

What to bring across

The instinct is to bring everything. Resist it.

Bring:

• Active customers and suppliers
• Products you still sell or buy
• Opening balances, agreed with your accountant
• Current stock quantities and values
• Open orders — sales and purchases still in progress
• Open invoices and bills

Leave behind:

• Customers you have not traded with in years
• Discontinued products
• Completed historical transactions
• Anything you cannot explain

Old history stays in the old system, archived and read-only. You can still look at it. It does not need to be inside Odoo, where it will slow searches and carry old errors forward.

The test: would you actually query this in Odoo? If not, archive it.

Cleaning, before anything else

Four categories of problem, and all four appear in almost every project.

Duplicates

“ABC Trading”, “ABC Trading Ltd” and “abc trading” are three records. In Odoo they will be three customers, with the balance split between them, unless they are merged first.

Inconsistent units

Some products listed in pieces, some in boxes, some by weight. Decide the rule now.

This is the one that is hardest to fix later. Odoo blocks changing a product’s base unit of measure once it has transaction history. Getting it wrong means clearing history on a live system.

Missing required fields

Blank cells that a spreadsheet tolerated will be rejected. Customer names, tax details, product units.

Rules hidden in formulas

Your spreadsheets contain business logic nobody has written in words. A nested IF that is really a discount policy. A lookup table that is really a customer tier structure.

Get these into plain sentences before configuring. This document is the single most useful thing you can hand an implementation partner.

The order of import

Each step depends on the one before it. Doing them out of order produces errors that are hard to read.

Odoo imports from CSV and Excel directly and can match on an external ID. Use those IDs — they let you re-run an import to update records rather than creating duplicates. This alone saves hours when the first attempt is imperfect, which it will be.

Testing before you trust it

Never import straight into your live database.

Import into a test database. Then take five real transactions from last month and process them end to end — quotation, delivery, invoice, payment. Compare the result with what actually happened.

If the numbers match, your setup is sound. If they do not, you have found a configuration problem while it is still cheap.

This is the step that gets shortened when a project runs late, and it is the one that should not be.

Going live

Two approaches. Choose deliberately.

Clean cut. Pick a date, usually the start of a month. Everything before it stays in the old system. Everything after happens in Odoo.

Simpler, and right for most small and medium businesses. There is no ambiguity about where a transaction lives.

Parallel run. Both systems for a period, compared.

Sounds safer and often is not. It doubles the work at exactly the moment your team is learning something new, and people quietly retreat to the familiar system. If you do it, keep it short and set a firm end date in advance.

What goes wrong

No internal owner. Somebody in your company must own this and be able to make decisions. Not the consultant — someone who knows how the business really works.

Trying to recreate the old system. People ask for Odoo screens that look exactly like the old software. Resist this. Some things will work differently, and usually better.

Dirty data imported anyway. Because cleaning felt slow. It poisons everything built on top and is far harder to fix afterwards.

Skipping training. People who do not understand the system will keep a spreadsheet on the side. Then you have both, and trust in neither.

Going live without a rollback plan. Know what you will do if the first week goes badly.

A realistic timeline

Assuming your side gives it proper attention:

Simple — a few apps, clean data, no customisation: several weeks.

Typical — core apps, some custom work, real cleaning: a few months.

Complex — multi-company, multi-warehouse, significant development: longer, and it should be phased.

The biggest variable is not the software. It is how quickly your side can clean data and make decisions. Projects rarely stall on code. They stall waiting for someone to confirm the chart of accounts.

Signs it went well

Six months on, the picture is simple.

Nobody is keeping a private spreadsheet. Questions about stock and margin are answered in a minute. Month-end is a review rather than an investigation. And when someone asks where a number came from, there is one clear answer.

That is the point of the whole exercise — not newer software, but one version of the truth.