Every Zoho-to-Odoo migration we’ve scoped or run shares a pattern: the platform switch itself is the easy part. Odoo’s import tool is genuinely good — CSV mapping, field matching, error reporting on failed rows. What breaks isn’t the tool. It’s the data underneath it, and the fact that most of these mismatches only get discovered one import cycle at a time, days or weeks apart, instead of all at once before anyone touches production.
Here are the eight places we see it happen most, in the order they usually surface.
1. State and region names that don’t match Odoo’s master list
Zoho, Tally and most legacy CRMs let you type a free-text value into a “state” field. Odoo validates against its own res.country.state table. The two most common breaks: a custom value like “Overseas” that has no equivalent in Odoo, and Indian states typed with inconsistent capitalisation or spelling (a stray lowercase letter is enough to fail a match). Both produce the same symptom — an entire batch of leads or customers rejected on import, with an error message that doesn’t obviously point at the state field.
2. Duplicate or missing serial and lot numbers
If you track serialised inventory, your historical serial-number sheet almost never matches your live stock count exactly. Common causes: units sold and re-entered under a new serial after a return, demo units never formally moved out of sellable stock, and simple duplicate entries from years of manual tracking. Odoo will accept the import, then your first stock take will disagree with the system — and by then it’s a reconciliation project, not a five-minute fix.
3. Missing GST/HSN codes on product masters
Zoho Books and Tally both let a product exist without a valid HSN code attached, especially for older SKUs. Odoo’s Indian localisation (l10n_in) will let you create the product too — but it blocks invoicing until the code is filled in. That means the gap doesn’t surface at import time. It surfaces the first time your sales team tries to bill that product live, in front of a customer.
4. Currency fields with no historical FX rate attached
If any part of your operation invoices or purchases in a foreign currency, your historical cost data is often stored in that original currency with no attached conversion rate for the date of the transaction. Migrating it as-is means Odoo either blocks the import or silently applies today’s rate to a transaction from eight months ago — which quietly corrupts your opening inventory valuation.
5. One-GST-per-contact assumptions
Odoo’s default contact model expects one GSTIN per company record. Distributors and multi-branch operations frequently have the same legal customer operating under several GSTINs for different states. If your source system stored these as one contact with multiple tax IDs, you’ll need a deliberate decision — separate contact records per GSTIN, or a customisation — before import, not after 200 invoices have already gone out under the wrong structure.
6. Custom fields that don’t have an Odoo equivalent
Zoho’s custom-field system is extremely permissive — teams add fields for years without much governance. When you map those to Odoo, some genuinely need a new field (via Studio or a proper module), and some are actually duplicates of something Odoo already tracks natively under a different name. Importing every custom field literally, without that audit, means you end up maintaining two versions of the same data point going forward.
7. Deal/opportunity amounts that don’t reconcile with invoiced totals
This one isn’t really an import bug — it’s a modelling gap. Your historical “closed-won” deal amounts in Zoho were often adjusted after the fact (discounts, partial fulfilment, returns) without the CRM record being updated to match the final invoice. Import those deal amounts into Odoo’s CRM as-is, and your first sales dashboard will show numbers that don’t match your accounting — a confusing, hard-to-explain gap that erodes trust in the new system in week one.
8. Duplicate contacts under slightly different names
“Acme Pvt Ltd”, “Acme Private Limited”, and “ACME PVT LTD” are the same customer to a human and three different contacts to an importer. Zoho’s free-text account-name field lets this drift happen for years unnoticed. Left unmerged, it fragments your customer history, your outstanding-balance reports, and your sales-person attribution the moment go-live starts.
The fix isn’t a smarter import. It’s a pre-flight check.
Every one of these is catchable with a straightforward validation pass over your export files — before anything touches Odoo. That’s the gap we kept running into on real migrations: the tooling to import data into Odoo is mature, but there’s no standard step that validates a Zoho-shaped (or Tally-shaped, or QuickBooks-shaped) export against Odoo’s actual constraints first.
If you’re mid-migration and recognise any of these symptoms, or you’re about to start one, get in touch — we’ll run your export files through the same checks before you commit to a go-live date.
