How to Choose an Odoo Migration Partner

Why this decision is different

Most software work can be inspected. You look at the interface, you use the feature, you form a view.

A migration resists that. When it goes well, nothing is visible: the same business running on a newer version with its history intact. When it goes badly, the damage surfaces weeks later in a reconciliation, a missing attachment, a report that quietly returns different numbers. By then the relationship, the budget and the go-live are all behind you.

That asymmetry is why choosing a migration partner has to be an evaluation of method rather than of finished work. The question is not whether they have done migrations. It is whether they can describe how they will prove this one is correct.

The five questions that actually sort the field

"What will you do before you give me a fixed price?"

The answer you want is a test conversion, or an assessment, or some concrete look at the real database. The answer you do not want is a number.

Nobody can price a migration accurately without seeing what is in the system. Databases carry things nobody remembers installing. A provider who quotes firm before looking has either padded heavily to cover what they cannot see, or is planning to raise it later when they find out.

This is also why we run assessments as their own fixed-scope piece of work. It is not a sales device, it is the only honest way to price the phase after it.

"How will you prove the data came across correctly?"

Listen for specifics. Reconciling the trial balance. Comparing open receivables and payables at the customer and supplier level. Checking stock valuation by location. Counting documents by type and date range. Verifying that attachments still resolve.

"We test thoroughly" is not an answer. Migration validation covers what a real comparison set looks like, and if a provider's plan is thinner than that page, ask why.

"What happens to my custom modules?"

A partner who has looked will name them. They will tell you which ones use view syntax that changed, which ones call core methods that moved, and which ones do something Odoo now does natively.

That last category is the valuable one. Porting a module forward that standard Odoo has since replaced means paying to maintain a feature you already own. Any provider who has never suggested retiring a customisation has not been looking for the saving.

Custom module migration covers the porting work in detail.

"What is the cutover window, and what is the rollback?"

The right answer describes a short planned window, not an absence of downtime. Most of a migration happens on a copy, invisible to your users, but there is a moment where the old system stops and the new one starts, and it needs a plan.

Rollback matters more than teams expect. The value is not that you use it. It is that the decision to abort was made in advance, calmly, against agreed criteria, instead of at 7am with everyone watching. See rollback planning.

"Who tests it, and as which user?"

The answer should include your people, in their own roles, doing their own work.

Testing as an administrator cannot find an access rights problem, because an administrator account bypasses the thing being tested. This is one of the most common ways a migration passes its own tests and then fails in production during the first week. Upgrade testing strategy covers how to structure this properly.

What separates migration work from implementation work

They are frequently sold by the same firms and they are not the same skill.

An implementation is a design problem. You are deciding how the business should run and configuring Odoo to match. The risk is choosing wrong, and it is evaluated the way you would evaluate any implementation partner.

A migration is a preservation problem. The design decisions are already made, often years ago by people who have left. The risk is losing something, and the hard part is knowing what you had. That means reading a database rather than interviewing a business, and it rewards a different temperament.

The two also differ in what "moving" means. Changing version is an upgrade; moving data between systems or servers is a migration, and the words get used interchangeably in quotes. Legacy data migration and hosting migration are separate projects again, and it is worth confirming which one a proposal is actually pricing.

Ask for references from migrations specifically. A firm with fifty implementations and three migrations is telling you where its experience actually sits, and there is nothing wrong with that as long as you know it.

A reasonable process for choosing

1. Shortlist on method, not on size. Ask each provider the five questions above before you ask for a price. The answers will separate them faster than any proposal.

2. Buy the assessment from your top two. It is a small, fixed, genuinely useful deliverable. You end up with a custom module inventory and a real understanding of your own system, which is worth having whoever you hire.

3. Compare the assessments, not the sales calls. One of them will have found something the other missed. That is the actual audition.

4. Check the scope lines match. Testing, parallel run, rollback, hypercare. If one quote is cheaper because those are absent, it is not cheaper.

5. Agree what "done" means in writing. Which reports reconcile, to what tolerance, verified by whom.

If you are several versions behind, read what staying on Odoo 12 or 13 costs first. It changes which of these questions matters most, because from that far back the discovery phase is the project.

Where we stand

We are an Odoo partner and we do this work, so weigh this page accordingly. What we can say with a straight face is that everything above is what we would want a client to ask us, and the assessment-first sequence is how we run our own migrations because we have not found an honest way to price one without it.

If you want to see how we scope this work, our migration and upgrade service sets out the phases and what each one produces.