The answer in brief
For an Odoo migration, data sources are inventoried, target objects and responsible parties are defined, duplicates are cleaned up, and mappings are documented. Several test migrations check for completeness and subsequent processes. An Odoo version upgrade is to be distinguished from this: it upgrades an existing Odoo database to a newer version.
A migration does not take over the past – it prepares for future operations
The most important migration decision is not how all data is imported, but which data is actually needed in the new system. Active regular customers, open processes, inventories, and relevant history serve different purposes. Duplicates, outdated addresses, and incomplete items should not be automatically taken over. Cleaning is professional work and requires responsible individuals from the respective areas.
Mapping describes more than column names. Units, taxes, price lists, variants, relationships, and statuses must fit the target process professionally. Several test imports help to stabilise transformations and understand runtimes. After each run, control totals, samples, and critical relationships are checked. Technically imported means successful only when users can continue real processes with it.
For the transition point, a cutover plan is needed. It defines data stop, final export, import, reconciliation, release, and fallback decision. Non-migrated history receives a controlled archive with access and retention end. This keeps the new system clear, without losing legal or operational documentation obligations.
Make migration acceptance-ready
- Selection and cleaning before import
- Technical mapping of values and relationships
- Multiple test runs with control totals
- Cutover, archive, and fallback concept
Distinguishing between system migration and version upgrade
In a system migration, data and processes move from a foreign system or multiple sources to Odoo. Data models, terms, and processes must be reassigned. A version upgrade, on the other hand, moves an existing Odoo database to a newer supported version.
Both projects require testing but have different risks. In migration, data quality and mapping are central. In the upgrade, individual modules, technical dependencies, and changes in the new version must also be assessed.
1. Inventory data sources and owners
At the beginning, there is a complete list: ERP, inventory management, CRM, accounting, shop, files, databases, and personal Excel lists. For each source, content, format, quality, volume, timeliness, and responsible specialist are documented.
The technical responsibility must not lie solely with IT. Sales decides which customer characteristics are relevant; warehouse and purchasing check items, units, and supplier references; finance assesses open items and historical requirements.
2. Decide what will really be migrated
Not every legacy data belongs in the new system. Active master and transaction data, open processes, and legally or operationally required history are prioritised. Old detailed data can remain in a secure archive if it is not needed in day-to-day operations.
This selection reduces effort and improves usability. However, it must be documented and aligned with retention, information, and reporting requirements.
- Active customers, suppliers, and products
- Open offers, orders, and purchases
- Stocks, batches, and serial numbers
- Open financial transactions according to an agreed concept
- History only with clear usage or obligation
3. Clean and document mapping
Duplicates, missing keys, inconsistent units, outdated addresses, and free text values are typical problems. Cleaning should ideally take place at the source or in a controlled transformation process – not through spontaneous corrections during the final import.
A mapping document describes which source field goes into which Odoo field, how values are converted, and which mandatory fields are supplemented. Relationships between customers, contacts, products, variants, and documents must also be maintained.
4. Test migrations with real processes
A technical success message only means that data has been loaded. Functional tests check whether it can be worked with: Can an order be generated from a migrated customer? Are units and taxes correct? Is stock in the right place? Do search, variants, and document relationships work?
Multiple test runs are normal. Each run receives measurable acceptance criteria, a list of errors, and a decision on whether the source, mapping, configuration, or process needs to be adjusted.
5. Prepare cutover and go-live
The cutover plan specifies when legacy systems will be frozen, which delta data will still be adopted, who will review the final import, and from when Odoo will be leading. Fall-back criteria, communication channels, and support staffing are also included.
No new data rules will be invented just before the start. Critical deviations must either be resolved or secured with a transparent manual transition process.
Checklist for acceptance
The release should occur in a professional, technical, and organisational manner.
- Data totals and samples match
- Mandatory fields and relationships are complete
- Core processes function with migrated data
- Permissions and data protection have been checked
- Cutover, support, and responsibilities are confirmed
- Archive access and legacy system shutdown are regulated
Measurable acceptance of data quality
Completeness is checked with control totals, samples, and relationships. The number of active customers, open orders, inventory values, and mandatory fields should be traceable between source, transformation stage, and target.
Additionally, departments check usability: Are units correct, contacts findable, price lists assigned, and open processes executable? Technically imported does not mean professionally accepted.
- Control totals per object
- Sample of critical data records
- Relationships and references
- Mandatory fields and value ranges
- Acceptance by designated subject matter experts
Archive, deletion and data protection
Non-migrated history requires a controlled storage location with access rules, search capability, and a defined end. Allowing an old system to run indefinitely is rarely a good archiving concept.
Personal data is assessed based on purpose, retention, and legal basis. Test environments require appropriate protection; productive data should not be copied uncontrollably into training or development instances.
In conclusion
Frequently asked questions on the topic
How many test migrations are necessary?+
There is no fixed number. Several iterations are common until technical and functional acceptance criteria are met reproducibly.
Do all historical data need to be migrated to Odoo?+
No. History should only be transferred if it is needed operationally, analytically, or legally. A suitable archive may be more sensible for older data.
What is the difference between Odoo migration and upgrade?+
Migration usually refers to the switch from another system to Odoo. An upgrade updates an existing Odoo database to a newer version.