How to Migrate from Odoo 14/15/16 to Odoo 17: Step-by-Step

Moving off Odoo 14, 15, or 16 is a data and code project. This guide uses Odoo 17 as the example target. The same steps apply when you are going on to 18 or 19.

Inventory the database before you pick a date

List every installed app, every OCA module, every custom addon, and every Studio field. Note the reports people actually open and the scheduled actions that send mail. Databases that have grown for years carry modules nobody uses. Removing those before the move shortens testing.

Choose an in-place upgrade or a fresh database

An in-place upgrade follows the version path and keeps the same database, including chatter, if the upgrade path supports it. A migration onto a fresh database extracts masters and open transactions and loads them into the new major version. The fresh database is easier to clean when custom modules have piled up. The in-place path is kinder when history must stay. Some projects upgrade the standard database and rewrite only the addons that will not load.

Port custom code on purpose

A module written for version 14 will not install on 17 or 19 unchanged. View syntax, ORM decorators, and asset bundles move between majors. Plan a developer pass and a functional pass for each addon you intend to keep. OCA modules need the branch that matches the target version, not a copy of the old folder. Our migration and upgrade service covers that port and the data load.

Map the data, then rehearse the load

Partners, products, the chart of accounts, open sales and purchases, unpaid invoices, and stock quantities are the usual minimum. Full invoice history is optional. If finance can live with opening balances and an archive of PDFs, say that early. Rehearse on a copy. The second rehearsal is where mapping mistakes show up. Cutover weekend is a bad time to meet them.

Parallel run, freeze, then cut over

For the flows that move money or stock, enter a sample day in the new database and compare the documents. Fix tax grids, rounding, and units of measure before you freeze the old system. During the freeze, stop new products and master edits, take a final extract, load it, and smoke-test login, a receipt, and a customer invoice. Leave the old database read-only for the first week.

A version move is usually shorter than a first implementation. A large custom codebase can still approach the same calendar. A first implementation runs from 4–8 weeks for a small scope to 4–12 months when the footprint is complex. Ask for a migration estimate from the addon inventory. When you are ready, talk to us with the version you are on and the list of custom modules.

Frequently Asked Questions