Migrate from CONTPAQi, Aspel or Excel to Odoo — no data lost, no stamping gap
Two paths, one promise: we move you TO Odoo from your current system (SAP, QuickBooks, CONTPAQi, Excel or a custom legacy) or upgrade your Odoo BETWEEN versions with OpenUpgrade. Validated ETL, parallel run and reconciliation reports before go-live. No data loss, and the configuration is 100% your property.
What is migrating to Odoo?
Migrating to Odoo means moving your data and operation from a previous system —or from an old Odoo version— to a clean, supported instance, without losing information and without stopping the business.
See in detail
We cover two flavors: (a) migrating TO Odoo from legacy systems, SAP, QuickBooks, CONTPAQi or Excel, with data mapping, ETL and validation; and (b) upgrading BETWEEN Odoo versions —typically from one of the supported versions to the latest— using OpenUpgrade to migrate the schema and the custom modules. In both cases we run a parallel run: the old and new systems coexist until reconciliation matches 100%.
The three fears of migrating, and how we neutralize them
We do not promise magic: we promise method. Each fear has a concrete, verifiable answer.
Losing data along the way
We work in a mirror environment, never on production, and close with record-by-record reconciliation at 100%: balances, catalogs and transaction sampling. We do not call a record migrated until it matches.
A weekend blackout
The parallel run lets the old system and Odoo coexist with real data until the results match. The final load goes in a short, controlled cutover window, with a tested rollback plan.
Being unable to stamp at cutover
We design the cutover so you are never left unable to invoice or to issue CFDI: we leave l10n_mx_edi_40 ready to stamp from day one on Odoo. What we do not do is re-stamp already-issued documents — the SAT prohibits it.
How we migrate, step by step
101 · Audit and mappingDeliverabledata map and phased scopeNot includedmigrating without first seeing the real state of your data
We inventory catalogs, balances and history of the source system and build the field-by-field data map.
202 · ETL in a mirror environmentDeliverablea built, repeatable migration in testingNot includedmigrating directly over production
We build and run the migration in a test environment. For Odoo upgrades we use OpenUpgrade and port the custom modules.
303 · Validation and reconciliationDeliverable100% reconciliation of balances, catalogs and samplesNot includedcalling a record migrated without it matching
Reconciliation reports comparing source and target record by record. We iterate until it matches.
404 · Parallel run and cutoverDeliverablea validated parallel run and a cutover with a rollback planNot includeda weekend blackout
We run in parallel with real data, set the cutover date and do the final load in a controlled window.
505 · Go-live and stabilizationDeliverablea stabilized operation, stampingNot includedre-stamping already-issued CFDI — the SAT prohibits it
We support the first weeks of production with monitoring and support.
The timeline comes from the analysis, not a promise
Migrating catalogs, balances and recent history usually takes 4 to 8 weeks including validation and parallel run; a source with many years of dirty history takes longer. The migration analysis reviews your real data and hands you the timeline and budget in writing, credited if you move forward.
We do not give a blind date or a magic "no data is ever lost": we give 100% reconciliation and a parallel run, with a timeline in writing after seeing your data.
Request the migration analysisWhen you need it
What the migration includes
Data audit
Inventory of catalogs (customers, vendors, products), accounting balances, transaction history and dirty records. We find duplicates, inconsistencies and gaps before touching anything, and define what gets migrated, archived or cleaned up.
Data mapping
We translate every source field to the Odoo model: accounts to the SAT chart of accounts, taxes to l10n_mx, units of measure, price lists and the structure of your custom modules. Documented and validated by your business team.
ETL and ingestion
Repeatable, versioned extract-transform-load processes in Python against the Odoo API (XML-RPC) or directly to PostgreSQL. For version upgrades we use OpenUpgrade to migrate the schema and port the custom modules.
Validation and reconciliation
Reconciliation reports that compare source and target record by record: balance totals, catalog counts and transaction sampling. We do not call a record migrated until the report matches 100%.
Parallel run
A period where the previous system and Odoo operate in parallel with real data, to verify the results match before turning off the old one. If something does not add up, we fix it without pressure and without ever stopping operations.
Cutover and rollback plan
We define the cutover date and window, the final load order, the success criteria and a tested rollback plan, so switching to the new system never leaves you unable to invoice or to stamp CFDI.
Training and launch support
Per-role sessions —sales, warehouse, accounting and management— with manuals and videos, plus intensive support during the first weeks of production so the team operates with confidence from day one.
We migrate our own operation first
We run iTech on Odoo 19; we know the fiscal cutover from the inside because we did it for ourselves. The firm's data-migration experience is real and transferable — without inventing a client case with metrics.
erp.itechdev.com.mxHonest transferable experience, not an invented client case.
Frequently asked questions
Can't find your question? Talk to an engineer — no sales script.
Contact us →Is there a risk of losing data during the migration?
The process is designed so there is not. We always work in a mirror environment —we never migrate directly over production— and every migration ends with reconciliation reports that compare source and target record by record: accounting balances, catalog counts and transaction sampling. We do not call a record migrated until it matches 100%, and the previous system stays alive during the parallel run as a backup. If something does not match, we fix it before the cutover.
How long does a migration to Odoo take?
It depends on the volume and cleanliness of the data. Migrating catalogs, balances and recent history usually takes 4 to 8 weeks including validation and parallel run; a source with many years of dirty history or complex business rules takes longer. An upgrade between Odoo versions with OpenUpgrade is more contained when there are few custom modules. We give you a detailed timeline after the data audit.
Which systems can you migrate to Odoo from?
We migrate TO Odoo from SAP (including Business One), Dynamics, QuickBooks, CONTPAQi, Aspel, AdminPAQ, custom legacy systems and Excel spreadsheets used as an ERP. We extract catalogs, balances and history, map them to the Odoo model (SAT chart of accounts, l10n_mx taxes) and load them with repeatable ETL. If your source is not on the list, we can almost always export it to CSV or read it through its API; we confirm this in the audit.
Can you upgrade my Odoo between versions and from Community to Enterprise?
Yes. We upgrade between Odoo versions —typically from one of the supported versions to the latest— using OpenUpgrade to migrate the database schema, and we port your custom modules to the new version. We also migrate from Community to Enterprise (or the other way around), moving data and configuration without starting from scratch. In both cases we validate with reconciliation and a parallel run before the cutover.
Does the operation stop during the migration?
No. The migration is built and validated in a test environment while you keep operating normally. The parallel run lets you confirm Odoo produces the same results as your current system, and the final load happens in a short, controlled cutover window with a rollback plan ready. We design the cutover so you are never left unable to stamp CFDI or to invoice.
Do you also migrate the tax localization and historical CFDI?
Yes. We map the chart of accounts to the SAT grouping standard and taxes to l10n_mx, and leave Odoo configured with l10n_mx_edi_40 so it stamps CFDI 4.0 from the cutover. As for fiscal history, we import issued and received CFDI as reference records (with their XML stored when available) so you keep accounting traceability; what we do not do is re-stamp already-issued documents, because the SAT prohibits it. We define the exact scope of the history in the data audit.
Request your migration analysis
Tell us where you are migrating from and we schedule the analysis: data map, timeline and a budget in writing.
What we do guarantee
- Mirror environment: we never migrate directly over production.
- Record-by-record reconciliation at 100% before cutover.
- Parallel run: the old system stays alive as a backup.
- We do not re-stamp already-issued CFDI — the SAT prohibits it.
Leave your trapped system, with no blackout
The migration analysis gives you the data map, the timeline and the budget in writing.