A data migration checklist for Odoo

Migrating data is not moving files; it is rebuilding the foundation the inventory and accounting cycles will run on from day one. The difference between a calm migration and a painful one is never the import tool. It is the decisions taken before importing: what genuinely has to move, in what order, who verifies it and who signs it off. What follows is a checklist drawn from practical projects, and every duration mentioned is a planning range rather than a commitment.

Start with an inventory of what really has to move

The first mistake in any migration is trying to move everything. Detailed history is heavy and is not read in daily work, and closed documents are only needed for an old audit that can still be served from the legacy system. Take the inventory first, then classify:

• Master data without which the system cannot run: units of measure, product categories, products, partners, taxes, accounts and payment terms.
• Opening balances: stock quantities and their valuation, partner balances and account balances.
• Open documents: unfulfilled sales and purchase orders, unpaid invoices and manufacturing orders still in progress.
• What stays in the legacy system: closed invoices, detailed historical stock moves, bills of materials no longer used and discontinued products.
• Attachments: they are not all copied automatically; decide what has to remain reachable on a partner or product record and what is adequately retained in the old archive.

This inventory turns a migration from an unknown into a scope: every line becomes a file, every file becomes an owner and a field, and every field becomes a verification. Without it, the team starts loading and discovers the gaps halfway through, when fixing them costs more than doing it properly at the start.

The order of master data, and why no other order works

Every object in Odoo references objects that must already exist, so loading a product before its category, or an invoice before its tax, produces errors and then rework. The practical order is:

1. Units of measure and their conversions, with one base unit agreed for each product family.
2. Product categories with their accounts, because they carry valuation and inventory settings.
3. Products with their types, units, barcodes and routes.
4. Partners: customers and vendors with their addresses and tax registration numbers.
5. Payment terms, taxes and pricelists.
6. Accounts and journals needed for entries, then the opening balances.
7. Open documents, then the opening stock moves.

Each step depends on the one before it, and any shortcut is repaired later at a higher cost than doing it in place. This is why any work on data migration starts by reviewing this order before a single import template is written.

Cleaning before loading: duplicates, units and categories

An import does not clean data; it freezes its errors. Review before loading:

• Duplicate partners: the same party under different names or spellings, where matching has to rely on the tax registration number or commercial registration rather than the name.
• Inconsistent units of measure: kilogram, tonne, metre and carton used for the same products, so quantities appear doubled or divided for no visible reason.
• Unmapped categories: legacy products that fit no category, and leaving them in a generic category damages reporting later.
• Inconsistent tax: a product carrying one tax when another is correct, or an old tax that no longer applies.
• Missing fields: barcode, route or vendor for every purchasable product.
• Duplicate account names in the chart of accounts: two accounts with the same name and the same use, so entries split between them with no rule.

Document the cleaning decisions in writing, because they will be questioned at the first reconciliation, and an undocumented decision is reopened in every cycle.

Opening balances: stock and accounting must agree

An opening stock balance is not only a list of quantities; it is a quantity, a value and a counterpart account. In Odoo the quantities are entered through a stock adjustment on a fixed date, valuation entries follow from the product category settings, and the account balances are then entered so that total stock valuation agrees with the stock account in the trial balance. If the two disagree, the error is in the entry rather than in the reports, and moving the difference into a permanent suspense account only hides it.

Review partner balances and open invoice balances as well, because they represent live obligations rather than history, and record the cut-off date for every balance, since a balance without a date cannot be matched later. To see how these quantities and movements are read after loading, review inventory management in Odoo.

The trial migration and reconciliation with the trial balance

Never load real data into the live environment before a complete rehearsal in a test environment. A trial migration tests the order, the files and the transformations, reveals the fields that reject values as supplied, and surfaces the decisions that stayed implicit. Make it a full migration rather than a small sample, then reconcile the result against the legacy trial balance line by line, examine partner and stock balances, and document every difference with its cause: a transformation error, a line that was never moved, or a difference in the cut-off date.

It helps when the trial migration fails at least once, because failure in a test environment is cheaper than correcting a live one, and a migration normally needs more than one cycle before reconciliation comes back clean. Attachments are loaded after the records they belong to, since the link depends on the partner, product or invoice existing first, and it is better to limit them to what serves daily work and what retention requirements demand.

Cutover, freeze and verification: who signs what

The moment work moves to the new system needs an announced sequence: fix the cutover date, freeze entry in the legacy system, take the final count, load the differences since the trial migration, then open the system for real use. The freeze window has to be known to every department, and any entry inside it must be handled through a documented path, otherwise differences appear that nobody can explain afterwards.

Verification is not reading the import log; it is counting rows and comparing balances: the number of products, the number of partners, the total quantities and the total balance for each account. Every line has one owner who signs for its correctness, with a written sign-off record, because shared responsibility with no named owner means in practice that nobody verified anything. Every duration mentioned here remains a planning range that is settled after a written scope, and we always recommend reviewing Odoo implementation as one path from migration through to operation.

What we do not guarantee

• We do not guarantee a commercial result or a reduction in cost; a good migration means correct data, not promised financial outcomes.
• We do not offer a binding price or a binding duration before a written scope signed by both parties.
• We do not guarantee that the system will be free of every difference after migration; verification is a shared responsibility recorded by signature.
• We do not provide a legal or tax opinion, nor a regulatory interpretation; those questions remain with the competent authorities.
• We do not provide any professional certificate and we do not claim any official status with software vendors.
• We do not guarantee a search-engine ranking or appearance in any particular results; everything offered here is professional explanation open to review.