Odoo Migration Console

1Setup — source, destination and your custom code

📦 Source database

Source Odoo version (the customer's current version)

Pick the version of the backup you are migrating. The upgrade steps are prepared from here up to the target. After restore the console double-checks the backup really is this version.

Backup files in Upload_backup/ ↻ refresh

no backups found — drop a file into Upload_backup/

…or full path to a backup on this server

Testwithout filestore Productionwith filestore

🎯 Destination

Target Odoo version Name of the migrated database

The database created and migrated by this run (letters, digits, underscores). Created fresh in the Restore DB + neutralize step — an existing DB with this name is dropped and rebuilt from the backup.

Output folder migrated_db/

Every finished database is exported here as a timestamped .dump — nothing is ever overwritten, all test runs are kept.

🧩 Custom repositories

Path with ALL ported custom modules

Module lists (upload Excel or edit below)

Unused modules — not used by any client, uninstalled before the migration starts

Report modules to uninstall — reporting-only modules rebuilt on the new version (history not migrated)

Module renames — two columns: old name → new name (module was renamed in the new version)

Review / edit the uninstall list

One module per line. The job stops before doing any damage if other installed modules depend on a listed one.

Review / edit the module renames

old,new per line — same target twice = merge, old,new+extra = split (extra gets installed).

Optional steps

Uninstall unused / report modules before hop 1 — uncheck to skip this step and keep those modules installed (they migrate with everything else). Apply module renames before the final update — uncheck to skip and keep modules under their source names (module_renames.csv is not applied).

2Progress

Overall0%

Status: idle Mode: – Database at: – Time taken: – Est. remaining: –

3Finish & verify — in this order

1 Installs your real custom code on the migrated database (applies renames + data transforms). Unlocks when the hop chain has finished. If it fails, add a solution below and press it again — known fixes are re-applied first, then it continues.

🛠 Solutions applied automatically

These SQL fixes live in scripts/fixes/ and are replayed first on every run and every retry (each is idempotent). When a new failure is diagnosed, its fix is added here so the same issue never blocks a future migration again.

2 Compares record counts and accounting totals with the untouched source copy. Unlocks after the final update.

3 Removes migration debris and shrinks the database. Unlocks only after Postcheck has PASSED.

4 Boots the migrated Odoo so you can log in and verify. Unlocks after the final update.

Live log follow

📖 How to migrate — read this before your first run

Prerequisites

Test run: a database backup file — .dump / .backup (made with pg_dump -Fc) or .dump.gz, copied into the Upload_backup/ folder. No filestore needed; documents/images will be missing in the test result, which is fine for checking data.
Production run: a .zip that contains BOTH the database dump and the filestore/ directory from the old server (attachments, images, documents).
Your ported custom code for the target version, all repos in one folder (set its path in Setup → Custom repositories).
Docker must be running on this machine (green whale icon). The live database is never touched — everything happens on a copy.

The steps

Prepare — fill in the Setup card: pick the backup, choose the target version, set the custom-repos path, and upload/review the three module lists (unused modules, report modules to uninstall, renames). Press Save settings.
Start — choose Test or Production and press ▶ Start migration. The console restores a copy, disables e-mail and scheduled jobs (a test can never send customer mail), keeps an untouched reference copy for validation, audits every module, uninstalls the listed ones, then upgrades one Odoo version at a time. Each step below shows its own progress bar, time taken and time remaining.
Final update — the chain stops on purpose when the database reaches the target version. Press ▶ Run final update: module renames are applied, your real custom code is installed, and the changed-model data transforms run automatically.
Validate — press Postcheck: record counts and accounting totals are compared against the untouched source copy. Debit/credit must match to the cent.
Cleanup — press Cleanup (dry-run) to preview, then Cleanup to remove migration debris and shrink the database.
Check in the browser — press Start Odoo, open the URL, and log in (customer admin credentials, or press Reset admin password and use admin/admin).
Deliver — the finished dump is in migrated_db/ (every run is kept, timestamped). Restore it on the production server together with the migrated filestore.

If something fails

Where it failed	What to do
Unpack / Restore	Check the file is a `pg_dump -Fc` dump (or a zip containing one). Production mode needs `filestore/` inside the zip. Fix the file and press Start migration again.
Preflight	Open the log — usually a module list problem. Review `custom_modules.txt` (the suggested list is a starting point, not the truth), then Resume.
Uninstall unused modules	The log lists modules that DEPEND on something you want to uninstall. Either add those dependents to the uninstall list too (ask the client!) or remove the blocking entry. Then Resume — nothing was changed on failure.
An OpenUpgrade hop (e.g. → 16.0)	Read the error in the log (also in `logs/hop-<version>.log`). Typical causes: a module missing from `custom_modules.txt`, or a data problem needing a fix in `scripts/fixes/`. After fixing, press Resume — the failed hop is rolled back to its snapshot and retried automatically.
Final update	Read `logs/custom-update.log`. Usually an error in a ported module — fix the module code in your repos and press ▶ Run final update again (it is safe to repeat).
Postcheck shows MISMATCH	Any difference in journal items or debit/credit totals is a release blocker — investigate before going further. Small attachment-count differences are normal.
Odoo does not open	Wait 30–60 s after Start Odoo. Still nothing? Press Stop Odoo, then Start Odoo again and watch the live log.
The server/laptop restarted mid-run	Open this page again — the job state is remembered. Press Resume to continue from the interrupted step.

Rule of thumb: nothing here is destructive to the customer — every run works on a copy, every hop has a rollback snapshot, and mail/crons stay disabled until go-live.