Skip to Content

Odoo Data Migration Checklist: Clean, Map, Test and Reconcile

Discover how to reduce Odoo migration risks by cleaning legacy data, mapping records, testing imports and reconciling results before go-live with BrowseInfo.
14 min read
September 1, 2026
Odoo Migration

Introduction

Moving data into Odoo is often treated as a technical exercise: export records from the old system, transform them into the required format, import them and move on.

That approach is risky.

ERP data is connected to business processes. A customer record can affect sales, invoicing, payments, deliveries and reporting. A product record can influence purchasing, inventory, manufacturing, pricing and accounting. If migrated data is incomplete, duplicated, incorrectly mapped, or poorly validated, the problem can continue long after go-live.

A reliable Odoo data migration process therefore needs more than an import script. It requires a structured lifecycle covering data discovery, cleansing, mapping, transformation, testing, reconciliation and final validation.

This checklist provides a practical framework for organizations preparing to migrate data into Odoo while maintaining data quality and operational continuity.

Why Odoo Data Migration Needs a Structured Process

Data migration is one of the most important parts of an ERP implementation because the new system depends on the quality of the information loaded into it.

Common migration problems include:

  • Duplicate customers
  • Incorrect product codes
  • Missing tax information
  • Invalid units of measure
  • Inconsistent addresses
  • Incorrect opening balances
  • Broken historical references
  • Missing supplier information
  • Incorrect inventory quantities
  • Unmapped fields
  • Incomplete transaction history

These problems can affect both daily operations and management reporting.

The objective should therefore be:

Move the right data, in the right structure, with the right relationships and prove that it is correct before go-live.

1. Define the Migration Scope

The first question should not be:

How do we import everything?

It should be:

What data does the business actually need in Odoo?

Not every legacy record needs to be migrated.

Possible categories include:

Master Data

  • Customers
  • Vendors
  • Products
  • Employees
  • Contacts
  • Warehouses
  • Locations
  • Pricelists

Open Transactions

  • Open sales orders
  • Open purchase orders
  • Outstanding invoices
  • Open manufacturing orders
  • Pending deliveries

Historical Data

  • Previous invoices
  • Payments
  • Sales history
  • Purchase history
  • Inventory movements

Reference Data

  • Payment terms
  • Taxes
  • Units of measure
  • Product categories
  • Fiscal positions

Each category should have an explicit migration decision.

2. Classify Data as Migrate Archive or Exclude

A practical migration strategy can divide legacy data into three groups.

Migrate

Required for current operations or financial continuity.

Archive

Useful for historical reference but not required in the active Odoo workflow.

Exclude

Obsolete, duplicate, incomplete, or unnecessary data.

This prevents the new Odoo database from becoming a copy of the old database—including its historical problems.

3. Identify Data Owners

Data quality should have business ownership.

For example:

DataOwner
CustomersSales
VendorsProcurement
ProductsOperations
InventoryWarehouse
Accounting balancesFinance
EmployeesHR

The technical migration team should not be solely responsible for deciding whether business data is correct.

The business owner should validate the meaning and accuracy of the data.

4. Profile the Existing Data

Before cleansing or mapping, inspect the source database.

Look for:

  • Record counts
  • Null values
  • Duplicate records
  • Invalid formats
  • Missing relationships
  • Inconsistent naming
  • Legacy codes
  • Obsolete records
  • Unexpected values

For example, customer records may contain:

ABC Industries Ltd.

A.B.C. Industries

ABC Industries Limited

These may represent one organization.

Data profiling helps identify such inconsistencies before they become Odoo records.

5. Clean the Data Before Import

Data cleansing is one of the most important stages of migration.

Typical cleansing activities include:

Remove Duplicates

Identify duplicate customers, vendors, products and contacts.

Standardize Names

Apply consistent naming conventions.

Validate Addresses

Correct incomplete or inconsistent addresses.

Normalize Phone Numbers

Use a consistent format.

Validate Email Addresses

Remove invalid or obsolete addresses where appropriate.

Clean Product Codes

Ensure product references are unique and meaningful.

Remove Obsolete Records

Exclude unnecessary legacy information.

The objective is not to make every historical record perfect.

The objective is to ensure the migrated dataset is usable and trustworthy.

6. Establish Data Standards

Before transformation, define standards.

For example:

Product Code

One unique internal reference per product.

Customer Name

Consistent legal or operational naming convention.

Country

Use standardized country values.

Currency

Use valid currency definitions.

Units of Measure

Ensure source and Odoo units are compatible.

Tax

Map legacy tax logic to the appropriate Odoo configuration.

Standards reduce ambiguity during transformation.

7. Build a Data Mapping Document

Data mapping connects the legacy database to Odoo.

A basic mapping table might look like:

Legacy FieldOdoo FieldTransformationValidation
Customer_IDExternal ReferencePreserve IDUnique
Customer_NameCustomer NameTrim/standardizeRequired
Phone_NoPhoneNormalizeFormat check
Product_CodeInternal ReferenceStandardizeUnique
Tax_CodeTaxMap legacy codeValid tax
Warehouse_IDWarehouseMapping tableExists

This becomes a key technical and functional reference.

8. Do Not Assume Field Names Have the Same Meaning

Two systems may contain fields with similar names but different business meanings.

For example:

Status

in the legacy system may represent payment status.

In Odoo, the corresponding workflow may use different fields and states.

Similarly:

Customer Type

could mean:

  • Individual/company
  • Retail/wholesale
  • Domestic/export
  • Tax classification

The mapping process should compare business meaning, not just field names.

9. Map Relationships Not Just Fields

ERP data is relational.

A product may connect to:

  • Vendors
  • Pricelists
  • Categories
  • Inventory
  • Sales
  • Purchase
  • Manufacturing

A customer may connect to:

  • Contacts
  • Sales orders
  • Invoices
  • Payments
  • Deliveries

Therefore, migration must preserve relationships.

A technically successful import that creates disconnected records is still a failed migration.

10. Establish a Migration Sequence

Data should generally be loaded in dependency order.

For example:

Foundation Data

  • Companies
  • Users
  • Currencies
  • Countries
  • Taxes
  • Units of measure

Master Data

  • Customers
  • Vendors
  • Products
  • Warehouses
  • Locations

Supporting Configuration

  • Pricelists
  • Payment terms
  • Routes
  • Product categories

Open Transactions

  • Sales orders
  • Purchase orders
  • Inventory
  • Open invoices

Historical Data

Where required.

The exact sequence depends on the Odoo implementation and data model.

11. Handle External IDs Carefully

External or legacy identifiers can be extremely valuable during migration.

They help establish:

  • Record matching
  • Duplicate detection
  • Relationship mapping
  • Reconciliation
  • Repeatable imports

For example, retaining a legacy customer ID can help identify the same customer across multiple migration cycles.

Avoid creating new random identifiers without maintaining a reliable mapping to the source system.

12. Handle Product Data Carefully

Product migration deserves particular attention because product records can affect multiple workflows.

Review:

  • Product name
  • Internal reference
  • Barcode
  • Product type
  • Category
  • Units of measure
  • Purchase information
  • Sales information
  • Vendor relationships
  • Taxes
  • Tracking
  • Routes
  • Reordering information

For manufacturing businesses, also consider:

  • Bills of materials
  • Work centers
  • Operations
  • Component relationships

Incorrect product configuration can create downstream operational problems.

13. Validate Customer and Vendor Data

Business partners should be reviewed for:

  • Name
  • Address
  • Contact details
  • Tax identification
  • Currency
  • Payment terms
  • Pricelist
  • Customer/vendor classification
  • Credit-related information where applicable

Duplicate contacts can create major operational confusion after migration.

A good cleansing process should establish matching rules before records are loaded.

14. Inventory Migration Requires Special Care

Inventory is not simply a list of products and quantities.

You may need to consider:

  • Warehouse
  • Location
  • Product
  • Lot
  • Serial number
  • Quantity
  • Unit of measure
  • Ownership
  • Inventory date

If tracked products are involved, lot and serial information may be operationally important.

Inventory quantities should also be reconciled against the source system at an agreed cutoff point.

15. Accounting Migration Needs Strong Reconciliation

Financial data requires particularly strong controls.

Depending on the implementation strategy, migration may involve:

  • Opening balances
  • Outstanding receivables
  • Outstanding payables
  • Bank balances
  • Tax balances
  • Customer/vendor balances
  • Fixed assets
  • Historical transactions

The appropriate accounting migration approach should be agreed with finance and validated against the organization's accounting requirements.

The key principle is:

The opening position in Odoo must reconcile with the approved closing position of the legacy system.

16. Define the Cutoff Date

A migration needs a clear point in time.

For example:

All transactions through 31 December are included in the legacy system.

Odoo becomes operational from 1 January.

The exact approach varies, but the cutoff must be explicit.

Without a controlled cutoff, transactions can be missed or duplicated.

17. Build a Migration Trial Run

Never make the first migration attempt the production migration.

Perform one or more trial migrations.

A trial should test:

  • Extraction
  • Transformation
  • Import
  • Relationships
  • Validation
  • Reconciliation
  • Error handling
  • Performance

The first trial is likely to expose issues.

That is precisely why it should happen early.

18. Validate Record Counts

One of the simplest migration checks is record-count comparison.

For example:

DatasetSourceOdooDifference
Customers25,00024,98020
Vendors4,5004,5000
Products12,00012,0000
Open invoices2,1502,1500

A difference is not automatically an error.

Twenty customer records may have been intentionally excluded because they were obsolete.

The important point is that the difference is known and explained.

19. Reconcile Totals Not Just Record Counts

Record counts do not prove data correctness.

For financial transactions, compare totals.

Examples:

  • Total receivables
  • Total payables
  • Inventory valuation
  • Bank balances
  • Open sales order value
  • Open purchase order value

For inventory, compare quantities and valuation where appropriate.

For accounting, reconcile against approved financial balances.

20. Validate Sample Records Manually

Automated validation is important, but business users should also inspect representative records.

Select samples such as:

  • High-value customers
  • Major suppliers
  • Frequently sold products
  • Products with tracking
  • Open invoices
  • Open orders
  • Complex customers
  • Multi-address contacts

Verify the records in Odoo against the source system.

21. Test Business Workflows With Migrated Data

This is critical.

Do not only verify that records exist.

Use migrated records in actual workflows.

For example:

Customer

Create a quotation.

Product

Create a purchase order.

Inventory

Process a delivery.

Vendor

Create or validate a vendor bill.

Invoice

Process payment and reconciliation.

The objective is to prove that migrated data works correctly inside the new ERP.

22. Test Exceptions

Normal workflows are not enough.

Test:

  • Duplicate records
  • Missing information
  • Partial deliveries
  • Returns
  • Invoice mismatches
  • Invalid tax data
  • Inactive customers
  • Product substitutions
  • Lot/serial tracking
  • Multi-company records

Exception testing often reveals problems that standard validation misses.

23. Validate User Permissions

Migrated data should also be tested against security requirements.

Check whether users can:

  • View appropriate records
  • Edit permitted fields
  • Access the correct company
  • Access appropriate warehouses
  • Perform authorized actions

Data migration and access control should be considered together.

24. Validate Multi-Company Data

For multi-company environments, verify:

  • Company assignment
  • Warehouses
  • Journals
  • Taxes
  • Customers
  • Vendors
  • Products
  • Accounting data
  • Access permissions

Shared and company-specific records should be clearly understood before migration.

Incorrect company assignments can create operational and accounting problems.

25. Reconcile After Every Trial Migration

Do not wait until the final migration.

After each migration cycle:

  1. Compare record counts.
  2. Compare totals.
  3. Validate relationships.
  4. Test workflows.
  5. Review exceptions.
  6. Record defects.
  7. Correct mappings.
  8. Repeat.

This turns migration into an iterative quality process.

26. Maintain a Migration Issue Log

Track migration defects systematically.

IssueDatasetSeverityCauseResolutionStatus
Duplicate customersPartnersHighMatching ruleUpdated deduplicationResolved
Missing tax mappingProductsHighLegacy code mismatchMapping updatedResolved
Incorrect UoMProductsMediumTransformation issueConversion correctedTesting
Missing invoiceAccountingCriticalExtraction filterQuery correctedResolved

This creates accountability and prevents repeated mistakes.

27. Define Migration Acceptance Criteria

Before go-live, define what "successful migration" means.

For example:

  • Required master data migrated
  • Approved exclusions documented
  • Record counts reconciled
  • Financial balances reconciled
  • Inventory reconciled
  • Critical relationships validated
  • Business workflows tested
  • High-severity defects resolved
  • Business owners have signed off

Without acceptance criteria, migration can remain subjective.

28. Plan the Final Migration

The production migration should be treated as a controlled event.

Define:

Freeze Period

When does legacy data entry stop?

Extraction

When is the final dataset extracted?

Transformation

Which final cleansing and mapping steps occur?

Import

What is the sequence?

Validation

Which checks must pass?

Business Sign-Off

Who approves the results?

Go-Live

When does Odoo become the operational system?

A detailed cutover plan reduces uncertainty.

29. Keep a Rollback or Contingency Strategy

The team should know what happens if a critical migration problem is discovered.

Possible contingency measures include:

  • Delaying go-live
  • Re-running migration
  • Correcting specific datasets
  • Continuing limited legacy operations
  • Reverting to an agreed fallback procedure

The exact strategy depends on the organization's risk profile.

The key is to decide before the migration event rather than during an emergency.

30. Reconcile After Go-Live

Migration validation does not stop when users log into Odoo.

After go-live, monitor:

  • Sales transactions
  • Purchase transactions
  • Inventory movements
  • Invoices
  • Payments
  • Accounting balances
  • Integration activity

Compare expected results with the legacy cutoff position.

This helps identify residual migration or cutover issues early.

Odoo Data Migration Checklist

Use the following checklist before approving migration:

Scope

  • Migration scope defined
  • Migrate/archive/exclude decisions documented
  • Historical data requirements agreed

Data Quality

  • Duplicate records identified
  • Invalid data corrected
  • Naming standards applied
  • Obsolete records excluded

Mapping

  • Source fields mapped to Odoo
  • Transformation rules documented
  • Relationships mapped
  • External IDs preserved where appropriate

Master Data

  • Customers validated
  • Vendors validated
  • Products validated
  • Warehouses validated
  • Units of measure validated
  • Taxes validated

Transactions

  • Open orders validated
  • Open invoices validated
  • Inventory validated
  • Financial balances validated

Testing

  • Trial migration completed
  • Record counts reconciled
  • Financial totals reconciled
  • Inventory totals reconciled
  • Sample records verified
  • End-to-end workflows tested
  • Exception scenarios tested

Cutover

  • Cutoff date defined
  • Legacy freeze planned
  • Final extraction tested
  • Production import sequence documented
  • Sign-off criteria established
  • Contingency plan documented

Common Odoo Data Migration Mistakes

Migrating Everything

More data does not necessarily mean better data.

Skipping Cleansing

Bad source data becomes bad ERP data.

Mapping by Field Name

Similar field names can have different business meanings.

Ignoring Relationships

Disconnected records can break workflows.

Testing Only Record Counts

Records can exist while containing incorrect information.

No Financial Reconciliation

Accounting migration requires stronger validation than simple imports.

No Business Ownership

Technical teams should not decide whether business data is correct.

Testing Only the Happy Path

Exceptions frequently expose migration problems.

Migrating Once

Trial migrations should identify defects before production.

How Integration Fits Into the Migration Strategy

Migration and integration are related but different.

Migration moves data into Odoo.

Integration keeps systems synchronized after go-live.

For example:

Legacy ERP → Odoo

is a migration.

But:

Ecommerce → Odoo

may be an ongoing integration.

The project should clearly distinguish the two.

Otherwise, teams may accidentally design a migration process where continuous synchronization is actually required.

Data Migration and Odoo Automation

Clean data is a prerequisite for automation.

Consider an automated replenishment workflow.

If product:

  • Units of measure are incorrect
  • Supplier lead times are missing
  • Reordering rules are wrong

the automation may produce poor purchasing decisions.

Likewise, customer automation depends on accurate:

  • Customer classification
  • Contact information
  • Sales ownership
  • Pricelist
  • Payment terms

Data quality should therefore be treated as an operational foundation, not merely a migration concern.

Using AI in Data Migration

AI can potentially support parts of the migration process, including:

  • Duplicate detection
  • Address normalization
  • Classification
  • Field mapping suggestions
  • Data-quality anomaly detection
  • Record summarization

However, AI-generated transformations should be validated before production use.

A particularly useful approach is to use AI to identify candidates for review, while retaining deterministic rules for critical transformations.

For financial and compliance-sensitive data, human validation remains important.

A Practical Four-Stage Migration Model

A simple way to structure an Odoo data migration is:

Clean

Remove duplicates, correct invalid values and standardize source data.

Map

Define relationships between legacy fields and Odoo fields.

Test

Perform trial migrations and validate workflows.

Reconcile

Compare counts, balances, quantities and business outcomes against the source system.

These four stages should be repeated as necessary rather than treated as a single linear exercise.

How BrowseInfo Can Support Odoo Data Migration

BrowseInfo can support organizations with Odoo data and integration initiatives, including:

  • Data migration planning
  • Data cleansing
  • Field mapping
  • Legacy ERP migration
  • Odoo implementation
  • Data transformation
  • Import automation
  • Third-party integrations
  • Ecommerce integrations
  • Inventory migration
  • Accounting migration
  • Manufacturing data migration
  • Multi-company data migration
  • Migration testing
  • Reconciliation
  • Odoo upgrades
  • Post-migration support

The appropriate migration strategy depends on the source system, data volume, business processes, historical requirements, integrations and accounting structure.

A workflow assessment can help identify which data is operationally critical and how it should support the target Odoo processes.

Executive Data Migration Questions

Before approving an Odoo migration, leadership should be able to answer:

  1. What data are we migrating and why?
  2. What data will remain in the legacy system?
  3. Who owns each dataset?
  4. What cleansing is required?
  5. How will legacy fields map to Odoo?
  6. How will relationships be preserved?
  7. How will inventory be reconciled?
  8. How will financial balances be reconciled?
  9. What are the migration acceptance criteria?
  10. What happens if the final migration fails?

If these questions are unanswered, the migration is not yet ready for production.

Frequently Asked Questions

1. What is the most important step in Odoo data migration?

There is no single step, but data cleansing and mapping are foundational. Poor source data or incorrect mapping can affect every downstream process.

2. Should all historical data be migrated to Odoo?

Not necessarily. Businesses should determine which historical information is required operationally, financially or legally and decide whether other records should be archived.

3. How do you validate migrated data?

Use multiple methods: record-count comparison, financial and inventory reconciliation, relationship checks, sample validation and end-to-end business workflow testing.

4. Why is data mapping important?

Mapping establishes how source-system fields and values correspond to Odoo's data structure and business meaning.

5. How should inventory be validated after migration?

Compare quantities and relevant valuation information with the approved source-system position at the migration cutoff, then test actual inventory workflows using migrated records.

6. How should accounting data be migrated?

The approach should be agreed with finance based on the required level of historical detail and reporting continuity. Opening balances and outstanding transactions should be reconciled against the approved legacy position.

7. Can AI help with Odoo data migration?

AI can assist with data-quality analysis, duplicate detection, classification and mapping suggestions, but critical transformations should be validated before production migration.

8. What should happen if migration validation fails?

The affected dataset should be investigated, corrected and migrated again. Critical defects should not simply be accepted because the go-live date is approaching.

Conclusion

A successful Odoo data migration is not defined by how quickly records can be imported. It is defined by whether the resulting data is accurate, connected, usable and reconcilable. Organizations should begin by establishing migration scope and ownership, then cleanse the source data, create explicit mapping rules, preserve relationships and validate the transformed records through multiple trial migrations.

Testing should go beyond checking whether records exist. Financial balances, inventory quantities, transaction totals and critical master-data relationships should be reconciled against the approved source position. Migrated records should also be used in real Odoo workflows so that the business can confirm that the data works correctly in practice.

The safest approach is to treat migration as a controlled business transformation rather than a one-time technical import. Clean the data, map it carefully, test repeatedly, reconcile the results and obtain business sign-off before production cutover. If your organization is preparing an Odoo implementation or migration, a workflow assessment can help identify the data, integrations, dependencies and validation requirements that should be addressed before go-live.

Odoo Data Migration Checklist: Clean, Map, Test and Reconcile
Varsha VS Odoo Functional Consultant

About the Author

I am an Odoo Functional Consultant specializing in ERP implementation, business process improvement, and system configuration. I works closely with businesses to streamline operations and maximize the value of their Odoo investment.
Book a Consultation

Share this post