Migration to Odoo: How to Move Data from 1C, Excel and Other Systems

A migration to Odoo does not fail where the script is written. It fails the moment somebody says “move everything”. Because “everything” comes with the errors, the duplicates, the closed partners and the history nobody will ever open again. A migration is first of all a decision about what not to move.

Where companies usually migrate from

• from 1C — the most common case: the books and master data live there, and the company needs a system it can actually develop;
• from Excel — where the real work is not moving the data but making it usable in the first place;
• from QuickBooks and other accounting systems;
• from in-house systems — data quality here is impossible to predict, so we look at it on site;
• from an older Odoo version — a category of its own, covered below;
• from Odoo Online to Odoo.sh or your own server — when you hit the limits of the cloud and need access to the code.

The most important decision: what not to migrate

In nine cases out of ten half the history should stay behind. Seven years of sales history does not make your accounting more accurate — it makes the database heavy, the migration long and the reconciliation impossible.

The working rule: balances and active data go into the new system, history stays in the old one in read-only mode. If the old system is being switched off for good, export the history to files and put it in an archive. That costs a few hours instead of a few weeks.

What is worth moving:

• master data — partners, products, units of measure, prices;
• stock on hand together with its valuation, not just quantities;
• debt — receivables and payables, broken down by document;
• bank and cash balances;
• opening balances on the chart of accounts as at the cut-over date;
• active open operations without which the business stops on day one.

Stages of a migration

The order matters — every step builds on the one before it.

1. Data inventory

What actually exists in the old system, in what volume and in what condition. This is the step where it usually turns out there are not 3,000 products but 900 plus 2,100 duplicates.

2. Cleaning and de-duplication

Done before the transfer, not after. Merging two identical partners in the old system is routine; doing it in Odoo once documents are already attached to both is a project of its own.

3. Mapping

Where every field lands, how warehouses, taxes, accounts, units of measure and statuses correspond. It is the most tedious stage and the only one that genuinely determines the outcome.

4. A trial run on a copy

A full transfer into a test database, using the same scripts that will go live. The scripts must be repeatable: running them a second time must not create duplicates.

5. Reconciliation

Control figures: number of partners and products, total stock value in money, receivables and payables balances, totals per account. Not “about right” — exact, with an explanation for every discrepancy.

6. The live transfer

In an agreed window, with a fixed cut-over date and a freeze on changes in the old system after it.

7. A parallel period

For the first month or two the old system stays available read-only. It is cheap insurance that removes most of the panicked questions.

Stock: quantity without valuation is not a migration

The most common mistake, and its consequences only surface a quarter later: stock is loaded by quantity while the valuation is left “to be fixed later”. Then the very first sale writes off the wrong cost, gross margin in the reports becomes fiction, and fixing it means reworking the whole chain retroactively.

The right way is to load the stock together with its valuation, its lots (if lot tracking is used) and its receipt dates. For FIFO the receipt date is decisive: it defines the order of consumption, not the date of the document you used to create the opening balance.

Receivables and payables: by document, not as one lump sum

The temptation to post one balancing entry per partner is strong — and it ends with no payment ever reconciling properly afterwards. Debt is migrated document by document: every unpaid invoice as its own record, with its own date and number. Then the bank statement reconciles automatically from day one.

The cut-over date

The most convenient point is the start of a reporting period: the first day of a month, better still a quarter or a year. Then the opening balances match a closed period in the old system and there is something to reconcile against. Cutting over mid-month is technically possible but doubles the reconciliation work.

An Odoo version upgrade is a migration of its own kind

Here the data is already in Odoo and the work shifts towards the code: custom modules have to be brought up to the new version, changed mechanics checked, and the data verified after the standard upgrade procedure.

The order is: upgrade on a copy first, then adapt the custom modules, then test with business processes rather than just checking that pages open. Only then the live upgrade. The biggest risk is not Odoo itself but modules written with no thought for upgrades — which is exactly why it is worth looking at them in advance.

Common mistakes

• Moving everything. The main reason migrations overrun.
• Cleaning the data after the transfer. Several times more expensive.
• Scripts that cannot be run twice. Every migration is run more than once — that is normal, and you have to be ready for it.
• No control figures. With nothing to reconcile against, a migration counts as successful right up until the first period close.
• No freeze date. Data keeps changing in the old system while you transfer, and the numbers never match.
• No data owner on the business side. A contractor can move the data, but only your person can decide which of two duplicates is the correct one.

How long it takes

For a small business with clean master data — one to two weeks including reconciliation. For a mid-sized company with several warehouses, lot tracking and years of history spread across several systems — from a month, and most of that time goes not into scripts but into deciding what counts as correct data.

I work hourly (T&M) and start with the inventory — after it the real scope is visible and further estimates stop being guesswork.

Next steps

The full list of services is in Odoo Services. If you are migrating from an older version with custom modules, it is worth running a technical audit first. And if you are still deciding whom to trust with it — what to look for in a contractor.

Frequently asked questions

Can all the history be moved from 1C?

Technically, mostly yes. In practice it is almost never worth it: cost and timeline multiply while the value of old history inside the new system is minimal.

Can we run both systems in parallel?

A short read-only period — yes, and you should. Keeping books in two systems in parallel for longer than a few weeks is something no team survives.

What if the data in the old system is poor?

Clean it before the transfer. That time is not wasted: you end up with an accurate master data set that will serve you for years.

Who is responsible for data correctness?

I do the technical part, but the decision about which record is right is made by your person — usually the accountant or the head of the function.

Can we migrate without downtime?

Fully without downtime, no — but the window normally fits into a weekend. It is planned in advance together with the data freeze date.