What an Odoo migration involves
Migrating to Odoo means moving three kinds of data from the source system into an Odoo database: master data such as customers, vendors, products, chart of accounts and tax codes; open transactions such as unpaid invoices, open purchase orders and stock on hand; and the history your finance team needs for reporting and audit. The source might be QuickBooks, SAP Business One, a set of spreadsheets or another ERP. Each source stores these records differently, so the first job is an inventory of what exists, where it lives and who owns it.
Most organizations start a migration because they are retiring a legacy system, consolidating several legal entities into one database, or moving off spreadsheets that have stopped scaling. In each case the Odoo setup is usually the shorter part of the work. The pace is set by the data: agreeing the chart of accounts across entities, deciding which history is worth carrying over, cleansing duplicate vendors and inconsistent product codes, and reconciling balances to the source system. Ask any prospective partner to show how they will handle these decisions before they quote build effort.
In-house or partner? Teams with a dedicated finance and data owner, and prior experience moving ERP data, often keep most of the work in house. Teams without that experience usually bring in a partner for the mapping specification, trial loads and reconciliation, because errors in these steps surface only after go-live. Either way, the business owner for each data domain should sign off the mapping rules in writing.
Edition and hosting decisions shape the target environment, so settle them before mapping starts. The plan you choose determines whether you can use custom modules, external API access and on-premise or Odoo.sh hosting, and those features change which fields and workflows the mapping must cover. Confirm current plan and edition details with Odoo, since they change over time.
What the migration work includes
A migration to Odoo is a set of linked work packages, each ending in evidence the finance owner can check. The scope depends on which data types move and how much history is kept, so the written scope should name both.
Source system assessment and data inventory
The team inventories every table, report and file that holds business data in the source system, including spreadsheets and add-on tools. It records volumes, owners, data quality and which records are still active. This inventory decides how much history moves and which data is retired. Ask for it to be listed by data type in the written scope.
Field-level mapping to Odoo models
Each source field for contacts, products, chart of accounts, open invoices and orders, stock and history is mapped to a target Odoo model and field. The mapping records transformations, default values and fields with no target. The mapping specification is the reference that every load script and reconciliation check is built against.
Cleansing rules and extraction scripts
Cleansing rules define how duplicate contacts, inconsistent product codes, unmatched tax codes and orphaned records are resolved, and who approves each decision. Extraction scripts pull data from the source in a repeatable way so every trial run starts from the same extract. Expect cleansing to take longer than the technical load in most projects.
Repeated trial loads into a neutralized copy
Trial loads run against a neutralized copy of the Odoo database, so test data never reaches users, email or payment integrations. Each run is logged with row counts, rejected records and error reasons, and the team repeats the load until the errors are understood. Ask how many trial cycles are included in a fixed-scope quote.
Reconciliation reports and finance sign-off
Reconciliation compares record counts and control totals between the source and Odoo for receivables, payables, inventory valuation and the trial balance. Differences are explained or corrected before sign-off. The finance owner signs the reconciliation evidence, which becomes a record of what was accepted for go-live.
Cutover runbook and rollback plan
The cutover runbook lists the freeze point, final extract, final load, reconciliation checks, user access changes and go or no-go decisions, with an owner and timing for each step. The rollback steps state what is reversed and how the source system stays available until the business accepts the new ledger. Rehearse the runbook at least once against a trial copy.
Handover and post-go-live support
Handover covers the mapping specification, load scripts or import templates, trial load logs, reconciliation evidence, the cutover plan and operating notes for the team that will run Odoo. Post-go-live support covers defect fixes and corrections to migrated records during an agreed window. Confirm in writing who owns each artifact after handover and how long support runs.
What drives migration cost and duration
Each row names a factor that changes the effort of moving data into Odoo, why it matters, and how to keep it under control before the written scope is agreed.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Source system count and quality | Each source system needs its own extraction, mapping and cleansing rules. Duplicate customers, inconsistent codes and manual spreadsheets multiply the rework at every trial load. | Name the system of record for each data domain early. Retire or freeze unused sources and agree which records are in scope before mapping starts. |
| Years of history to carry | More history means more records to extract, validate and reconcile. Historical postings also raise questions about old tax rates, closed periods and renamed accounts. | Decide with finance how many years of transactions to load. Often opening balances plus recent open items are enough. Confirm this with your auditors and tax advisers. |
| Number of companies and currencies | Each legal entity needs its own chart, journals and reconciliations. Multiple currencies add exchange rate history and revaluation checks. | Confirm the entity structure and the multi-company need before design. Multi-company requires the Odoo Custom plan, so settle it in the plan decision. |
| Chart of accounts complexity | Account mapping decisions affect every journal, report and tax line. Large or inconsistent charts require finance sign-off on each mapping. | Simplify or consolidate accounts before migration where possible. Ask the implementer to show the mapping table as a deliverable for sign-off. |
| Product and variant volume | Products, variants, units of measure, bills of materials and pricing lists each need mapping. Attribute structures that differ from Odoo's model need redesign. | Clean the product master in the source system. Agree which products are active and which are archived before extraction. |
| Open transactions at cutover | Open invoices, purchase orders, sales orders and stock moves must carry over with correct status and balances. Each open item adds a reconciliation check. | Plan the cutover window so open items are minimized. Decide which items to close in the old system and which to recreate in Odoo. |
| Custom fields and workflows in the source | Custom fields, approval steps and scripts have no direct equivalent in Odoo. Each one needs a configuration, a Studio field, or a custom module decision. | Inventory custom fields and workflows before design. Drop unused ones and map the rest to standard Odoo features where they fit. |
| Integrations that feed the source | Banks, eCommerce sites, payroll and logistics systems that write into the old ERP must be rewired to Odoo, which affects both scope and testing. | List every feeding system and its data direction. Confirm which integrations move in the same release and which can follow later. Odoo external API access requires the Custom plan. |
| Number of trial load cycles | Each trial load exposes new mapping errors. Teams often need several cycles before the data is accepted, and each cycle repeats extraction and validation. | Agree the number of trial loads and the acceptance criteria in the written scope. Fix mapping rules centrally rather than patching records by hand. |
| Reconciliation depth | Reconciling balances, stock quantities, receivables and payables to the source is the proof that the migration is correct. Deeper checks take longer but reduce post-go-live disputes. | Define the reconciliation checks, owners and tolerances before the first trial load. Ask for a reconciliation report per trial load. |
| Edition and plan choice for the target | Custom modules, external API access and multi-company require the Custom plan according to Odoo's pricing page. Plan choice changes which migration features and integrations are available. | Confirm required features against Odoo's pricing page before design. Ask the implementer to state which plan the scope assumes. |
| Hosting target | On-premise or Odoo.sh hosting requires the Custom plan according to Odoo's pricing page. Hosting also determines who runs trial databases and the production cutover environment. | Decide the hosting target with IT and security before the migration plan is written. Ask for hosting responsibilities in the written scope. |
Migration phases and what each produces
The sequence moves data from the old system into Odoo in controlled stages, and each stage closes with a document or database state you can check before the next one starts.
Inventory sources and data
We list every source system, export, spreadsheet and report that holds master data or open transactions, with owners and record volumes. You receive a data inventory that names each source, its owner and the Odoo area it feeds, and the step is done when your business owners have confirmed it in writing.
Design target model and mapping
We map source fields to Odoo models, chart of accounts, products, partners and warehouses, and record decisions on what migrates, what is summarized and what is archived for read-only reference. You receive a signed mapping specification and a decision log, and the step closes when finance and operations leads approve both.
Cleanse and extract source data
Your team and ours fix duplicates, invalid codes and incomplete records in the source, and we extract clean files on a repeatable basis. You receive extract files with a cleansing log and a list of records excluded, and the step is complete when row counts and control totals match the inventory.
Build load tooling
We write the import scripts or transformation jobs that take the extracts through the mapping into Odoo, with validation rules and error reports for rejected rows. You receive versioned load code and a runbook, and the step is done when the tooling runs cleanly against a sample set.
Run trial loads and reconcile
We load repeatedly into a neutralized copy of the database, following Odoo's on-premise documentation for database duplication and neutralization so test copies cannot send email or reach live integrations. You receive reconciliation reports for balances, open documents and stock, and sign-off closes when the differences are explained and accepted.
Rehearse cutover
We run the full cutover sequence at least once against a copy that matches production timing, including freeze, final extract, load, reconciliation and rollback decision points. You receive a timed cutover plan with owners and go or no-go criteria, and the step is done when the rehearsal results have been reviewed and the plan updated.
Go live and stabilize
We execute the approved cutover, confirm reconciliation on the production database and support users through the first period of live operation. You receive a signed cutover record, a list of open issues with owners, and a stabilization handover. Durations for each phase depend on scope, so confirm them in the written quote.
What stays in-house and what goes to a partner
This table shows who owns each part of an Odoo migration, the skills each part needs, and whether teams usually keep it in-house or hand it to a partner, so you can decide where to draw the line.
| Migration task | Owner and skills needed | In-house or partner | Notes for the decision |
|---|---|---|---|
| History to keep | Business owners and finance lead. Knowledge of reporting needs, audit trail expectations and retention rules. | Usually in-house | Decide which closed years, customers and documents move. Partners can advise, but the rules belong to your organization. |
| Opening balances sign-off | Finance owner. Accounting close process and authority to accept balances. | Usually in-house | The finance owner must accept reconciled balances even when a partner runs the loads. Acceptance is a business decision, not a technical task. |
| Source data extraction | Source system administrator or partner engineer. Knowledge of the old ERP, QuickBooks, spreadsheets or other sources and their export formats. | Often shared | Your team confirms what the source holds and which records are current. A partner often writes and runs the extracts. |
| Mapping and transformation code | Odoo developer or data engineer. Odoo data model, import methods and scripting in Python. | Often partner | Field mapping rules need business sign-off. Scripts that transform data are often built by a partner and reviewed by your team. |
| Trial load execution | Data engineer with Odoo import skills and access to test databases. | Often partner | Repeated trial loads are where most defects surface. Ask who fixes failed rows and how each run is logged. |
| Reconciliation | Finance and operations staff, with a partner analyst to compare totals and explain differences. | Shared, finance-led | Totals for balances, open invoices, stock and customers must match the source. Finance signs off the result. |
| Cutover coordination | Project manager and technical lead from both sides. Knowledge of freeze windows, access changes and rollback steps. | Often shared | Agree in writing who decides go or no-go and who can stop the cutover. Your team owns business communication. |
| User training | Process owners and trainers. Knowledge of the new Odoo workflows and your own procedures. | Usually in-house | Partners can build materials, but staff who know daily tasks should deliver the training and answer questions. |
| Post-go-live fixes | Support lead and the partner or internal developers. Knowledge of issues found in live use. | Often partner under a support agreement | Confirm response expectations and who pays for fixes in writing before go-live, since none are implied by the migration itself. |
What goes wrong in Odoo migrations
Most failed ERP migrations break at the same few points. Each risk below names the prevention step and the artifact that shows it was handled before cutover.
Opening balances that do not match the source
Opening balances in Odoo often differ from the source system at cutover because of timing, currency rounding or unposted entries. Prevention is a balance-by-account reconciliation signed off by finance, run on the exact cutover date. The artifact is a reconciliation workbook showing source totals, Odoo totals and every variance with its explanation.
Duplicate or wrongly merged contacts and products
Customers, vendors and products often appear under several names across QuickBooks, spreadsheets or another ERP. Merging on fuzzy matches can combine unrelated records, and splitting them breaks open invoices and stock history. Prevention is a matching rule set reviewed by the data owners. The artifact is a signed match log listing each merge and split with its source identifiers.
Chart of accounts mapped without accounting review
Mapping legacy accounts to Odoo accounts by name alone can move revenue, tax or clearing balances into the wrong ledger. Odoo's account types and tax setup must match how your reports and filings are produced. The prevention step is a line-by-line mapping review by an accountant who owns the reports. The artifact is an approved account mapping table with tax and report-line assignments.
Open orders and invoices migrated without payment status
Migrating open invoices, bills or sales orders without their partial payments, credit notes or allocations leaves receivables and payables that do not match the customer or vendor statement. Each open document needs its settled amount and payment link carried across. The artifact is an open-item aging comparison per partner, checked against source statements before go-live.
Legacy codes with no Odoo equivalent
Item codes, cost centers, warehouse locations or custom fields in the source may have no direct field in Odoo, so data is dropped or stuffed into unrelated fields. Decide per code whether it becomes a product attribute, analytic account, tag, internal reference or archived history. The artifact is a field-level crosswalk that records each legacy code and its target, with the owner who approved it.
History decisions made late in the project
If the team has not decided how much transaction history to load, trial loads and reporting checks are built against an unclear target, and the decision often gets reopened near cutover. Settle the history window, the level of detail and whether older data stays in an archive early. The artifact is a signed history scope decision that lists which periods, documents and attachments are loaded or archived.
Trial loads run on a stale database
Trial loads run against a database that was not refreshed or rebuilt from the same extract give results that do not reflect the final cutover. Each trial should start from a clean, restored environment and use the same scripts and source snapshot as the last run. The artifact is a trial load log that records the environment, extract date, row counts and error totals for each run.
Custom modules built on a version that needs an upgrade
Custom modules written against a version that will reach the end of standard support soon after go-live force an early upgrade and porting work. Check the chosen version against Odoo's published support dates and plan the upgrade window before the build starts. The artifact is a version decision record that names the support end date, the planned upgrade date and the module list affected.
Cutover without a tested rollback path
A cutover plan that cannot return to the source system leaves the business with no safe option if reconciliation fails on the day. Define the freeze point, the last source extract, the criteria for reverting and who decides. Rehearse the full sequence on a copy of production. The artifact is a rehearsal report with timings, reconciliation results and a signed rollback decision point.
How the work changes by starting point
Extraction is usually export-based: reports, lists and transaction files from the desktop or online edition, because direct database access is generally not available. Confirm which export formats your edition supports and whether its API covers every object you need.
- Chart of accounts: Accounts are often reorganized over the years, so decide which legacy accounts map to Odoo account types and which become analytic dimensions.
- Duplicate contacts: Customers and vendors are frequently entered twice under slightly different names, so merge rules must be agreed before loading.
- Open items: Partially paid invoices and bills need reconciling against bank data before cutover.
- Tags and classes: Class, location and project tags need a deliberate mapping to Odoo analytic accounts.
The mapping decision that dominates is how much history to load at transaction level versus summarizing it into opening balances.
Extraction commonly runs through the Data Transfer Workbench, the DI API or read-only queries against the company database. Confirm with your SAP Business One partner which method your version and license position support, and agree a read-only account before any extract runs.
- User-defined fields: Customized fields and tables are common and must each be mapped or deliberately dropped.
- Item master complexity: Variants, batch and serial tracking, and multiple price lists need a clear Odoo product model before loading.
- Document series: Numbering often differs across series and branches, which affects duplicate detection and references.
- Warehouses and bins: Bin locations and stock valuation need mapping to Odoo inventory locations and costing methods.
The mapping decisions that dominate are the item and bill of materials structure and how general ledger posting periods carry into Odoo.
There is no system extract, so the work is file handling: collecting workbooks, paper-based records and exports from several tools, then converting them into import templates for each Odoo object. Ownership of each file must be named, because the data owner often signs off the final load.
- Inconsistent formats: Mixed date formats, numbers stored as text and merged cells break imports.
- Duplicate keys: The same customer or product often appears under several codes or spellings.
- Competing versions: Several copies of one list may exist, and the current one must be confirmed.
- Missing relationships: Invoices may not link to their customers or products, so references must be rebuilt.
The mapping decisions that dominate are the canonical template for each Odoo object, the external identifiers used so re-runs update records instead of duplicating them, and how opening balances are entered as journal entries.
Extraction usually comes from a database dump or the source system's API. Schema and workflow differences matter more than the export format, and any custom apps, scripts or reports in the source must be inventoried first, since they often hold business rules that nobody has written down.
- Document states: Draft, submitted and cancelled states in the source need explicit mapping to Odoo statuses.
- Soft deletes: Flagged or archived records may still be referenced by live transactions and must be resolved.
- Units of measure: Conversions between units and packaging levels must be checked against Odoo's unit model.
- Tax and valuation: Tax rules and stock valuation methods often differ, so each needs a documented equivalent.
The mapping decisions that dominate are the status model, the tax and valuation equivalents, and whether source-specific business rules are rebuilt through configuration or custom code.
The data already lives in Odoo, so this path has no extraction step and little field-level mapping. The work centers on whether the database contains custom or third-party modules that must be reviewed against the Enterprise code base. The Odoo Community to Enterprise migration topic covers those steps.
- Module inventory: Custom and third-party modules need a compatibility check before the switch.
- Subscription status: Enterprise on-premise use requires a subscription, and the upgrade service depends on it.
- Data integrity: Existing records should be verified after the switch, especially those touched by custom code.
The decisions that dominate are whether the move is combined with other changes, such as a version upgrade or a hosting change, and how much of the test effort is spent on custom code rather than data.
What you need to provide before work starts
Migration timelines are mostly set by what the client can provide and decide, not by Odoo itself. Before work starts, confirm in writing which Odoo edition and plan the target will run on. The Odoo pricing page lists One App Free, Standard and Custom plans, and only Custom can be hosted on Odoo.sh or on-premise and includes custom modules and external API access. If the migration needs custom modules, a hosting choice other than Odoo Online, or Studio, the plan must be settled first. Ask Odoo or your partner to state the edition and plan on the order, and keep the subscription code and the hosting model in the project file.
On the source side, provide read access or full exports from the system you are leaving, and record its version and export options. QuickBooks, SAP Business One, spreadsheets and other ERPs each export differently, and some limit history or attachments. Name one data owner for each domain: customers, products, finance and inventory. Name one finance sign-off owner who accepts the chart of accounts review and the reconciliation totals. Without these names, mapping decisions stall during trial loads.
Make three decisions early. First, how much transaction history moves into Odoo and how much stays in an archive with read-only access. Second, your archive policy and retention period for the source system, which is often a legal or audit question rather than an IT one. Third, the business calendar: month-end, tax filing and peak trading dates that constrain the cutover window. Also provide a neutralized copy of the production database for test loads, so no live customer data or sign-in details reach non-production environments.
Finally, provide hosting access in the environment you have chosen, whether a cloud account, a data center or on-premise servers, and name the user acceptance testers who will check balances, open invoices and stock levels against the source system. Ask your partner to confirm in the quote which of these items are assumed and which are the client's responsibility, so that a late export or an unnamed tester does not move the go-live date.
Questions buyers ask about Odoo migration
How much does it cost to migrate to Odoo from another ERP?
The cost depends on the written scope, not on a list price. Odoo's own licensing is billed separately: the Standard and Custom plans are priced per user per month on Odoo's pricing page, and the Community edition is free to download but has no upgrade service. The implementation fee covers mapping source data, cleansing it, building load scripts, running trial loads, reconciling balances and supporting cutover. Ask any quote to list each of these as a separate line, state which parts are one-time and which recur, and name what is excluded, such as custom modules, integrations or training. DeployOpen does not publish prices, so request a quote from a written scope.
How long does an Odoo data migration take?
Duration is set by the state of the source data, the number of systems being moved and how many cycles of testing the business needs. The main drivers are how many years of history must be kept, how many open transactions exist at cutover, how messy the master data is, and whether the source system exposes clean exports or needs custom extraction. Each trial load usually reveals mapping issues that take another cycle to resolve, so the number of rehearsals matters more than the number of records. Ask for a timeline that shows each trial load, the reconciliation sign-off and the cutover window as separate milestones.
Can our internal team migrate to Odoo without a partner?
Yes, a capable internal team can migrate to Odoo, but it needs people who know both the source ERP's data model and Odoo's accounting, inventory and sales models. The work requires skills in data extraction, field mapping, scripting or import tooling, PostgreSQL basics and financial reconciliation. Most teams underestimate reconciliation, where opening balances, stock valuation and tax totals must agree to the source at a set date. Before deciding, inventory which of those skills already exist, how many people can give the project sustained time, and who will own the result after go-live.
What do our staff have to do during an Odoo migration?
Your staff must make business decisions that the migration cannot make for them. Finance must approve the chart of accounts mapping and opening balances. Operations must confirm which products, customers, vendors and open orders are still active. Process owners must review sample records in each trial load and sign off on the results. Expect recurring review time during testing and a short freeze on source-system changes near cutover. Agree on named owners for each dataset before the first trial load, because unresolved ownership is one of the most common causes of delay.
Do we have to move all historical data into Odoo?
No. Most organizations move master data, such as customers, vendors, products and chart of accounts, plus open transactions and opening balances. Older closed transactions are often kept in an archive, a read-only reporting database or the legacy system, which avoids paying to clean and load records nobody uses. Decide by reporting, audit and tax requirements, since regulators or auditors may need access to certain periods. Document the retention rule for each data type and confirm it with finance and your auditors before mapping begins.
Does the Odoo version we choose affect the migration?
Yes. The target version determines the data model, the available apps and how long the system will receive security patches. Odoo's standard support runs for three years after a major release on its supported deployments, so a version nearing the end of standard support creates a near-term upgrade the migration will not avoid. SaaS releases follow a faster cycle and cannot use extended support. Confirm the target version against Odoo's support dates before scoping, and ask the implementer how custom modules and mappings will be carried into later upgrades.
How DeployOpen scopes and delivers Odoo migrations
DeployOpen moves master data, open transactions and history from QuickBooks, SAP Business One, spreadsheets or another ERP into Odoo inside infrastructure you control. The work is planned as a written, fixed-scope engagement with trial loads and reconciliation before go-live.
How we scope
- Inventory every source system, export format and report that feeds the business before any mapping begins.
- Agree in writing which master data, open transactions and history move, and which stay archived.
- Define the Odoo apps, edition and hosting target so data mapping matches the chosen modules.
How we build
- Map source fields to Odoo models, then cleanse duplicates, missing references and invalid tax or currency codes.
- Run repeated trial loads into a test database and log every rejected or transformed record.
- Reconcile balances, open invoices, stock valuations and counts against the source system after each trial.
How we hand over
- Document the field mapping, cleansing rules, load scripts and reconciliation results for your finance and operations teams.
- Run a rehearsed go-live cutover with a written freeze, final load and sign-off checklist.
- Hand over runbooks for re-running loads, rolling back a failed cutover and archiving source data.
How we support
- Ongoing support, upgrades and testing after go-live are available as a retainer if you want them.
- Plan the first Odoo version upgrade early, since upgrades reuse the same mapping and test discipline.
- Confirm with us which support responsibilities end at handover and which continue under a retainer.
