IN SHORT: Migrating from CONTPAQi or Aspel to Odoo is done in parts: catalogs (customers, products, suppliers), opening balances, and historical CFDI do migrate; the full transactional accounting history, customizations, and reports are usually rebuilt or archived for reference. A typical project runs 4 to 12 weeks and $120,000 to $600,000 MXN depending on volume and data cleanup. What weighs most isn't technology — it's the quality of your information.
CONTPAQi and Aspel solved accounting and invoicing in Mexico very well for years. The problem shows up when the company grows and needs sales, inventory, purchasing, production, and finance to talk to each other in a single system. That's when many leadership teams decide to migrate to Odoo. This guide tells you, without spin, what to expect from the process.
Why companies leave CONTPAQi/Aspel for Odoo
It's not that CONTPAQi or Aspel are "bad": they solve one part of the business. The recurring reasons to migrate:
- Information islands. Invoicing on one side, inventory in Excel, CRM somewhere else. Odoo integrates everything on a single data model.
- Operations beyond accounting. Manufacturing (MRP), projects, e-commerce, point of sale, HR — modules that purely accounting software doesn't cover.
- Scale without licensing everything. In Odoo Community you don't pay a per-user license, which changes the economics as the team grows.
- Real customization. With a software factory behind it, a specific workflow gets built to measure instead of forcing your operation into the system's mold.
What migrates and what doesn't (the honest table)
This is the conversation worth having before signing, not after:
| Item | Migrates to Odoo? | Comment |
|---|---|---|
| Customer catalog (with RFC/tax regime) | ✅ Yes | Validated against the Tax Status Certificate |
| Product/service catalog | ✅ Yes | Used to map ClaveProdServ and ClaveUnidad |
| Supplier catalog | ✅ Yes | Includes payment terms |
| Opening balances (AR/AP) | ✅ Yes | As initial balances at a cutoff date |
| Opening inventory (stock and costs) | ✅ Yes | Physical count recommended before cutoff |
| Historical CFDI (XML/PDF) | ✅ Yes | Loaded for reference/archive; not re-stamped |
| Trial balances at cutoff date | ✅ Partial | Balances yes; transactional detail is archived |
| Full transactional accounting history (years) | ⚠️ Rarely | CONTPAQi/Aspel kept in read-only mode |
| Custom reports and formats | ❌ Rebuilt | Reconstructed in Odoo (a chance to improve them) |
| Prior-system customizations/macros | ❌ No | Reimplemented as Odoo modules if applicable |
Golden rule: you migrate what you need to operate going forward (catalogs + balances + inventory at a cutoff date). The deep past stays in the old system in read-only mode. Trying to migrate 8 years of transactional entries usually costs more than it's worth.
The step-by-step process
1. Assessment and cutoff date (week 1)
Scope, modules, and the cutoff date are defined (ideally the start of a month or fiscal year). Everything before that date lives in the old system; everything new, in Odoo.
2. Data extraction and cleanup (weeks 1–3)
Catalogs and balances are exported from CONTPAQi/Aspel. This is where the real work happens: de-duplicating customers, unifying products (the famous "14 versions of the same SKU"), and validating RFC/tax regime against the certificates. Clean data = fast migration; dirty data = 40–60% of the effort.
3. Odoo and localization setup (weeks 2–5)
In parallel, Odoo is configured: chart of accounts, taxes mapped to SAT, PAC (Finkok/Factura.com), CSD installed, tax regime, CFDI uses, and workflows. Community or Enterprise is decided.
4. Loading and validation (weeks 4–8)
Catalogs, opening balances, and inventory are loaded. A test stamping of CFDI is done before touching production, and balances are reconciled against the old system's trial balance.
5. Training and go-live (weeks 6–12)
Role-based training, parallel or "big bang" go-live depending on risk, and support through the first closes. The first 30–60 days determine adoption.
Real costs in MXN
Reference ranges for a migration (implementation included; the Enterprise license, if applicable, is added separately):
| Profile | What it involves | Estimated range (MXN) | Timeline |
|---|---|---|---|
| Simple SMB | Clean catalogs, PUE invoicing, 1–3 key users | $120,000 – $250,000 | 4–6 weeks |
| Standard company | Several modules, PPD/REP, inventory, data to clean | $250,000 – $450,000 | 6–10 weeks |
| Complex operation | Manufacturing, multi-warehouse, integrations, heavy migration | $450,000 – $600,000+ | 8–12+ weeks |
Recurring costs: PAC stamps (packages from ~$0.50 to $3 MXN per stamp by volume), Enterprise license per user/month (if you choose that edition), and the partner's support/maintenance. The factor that moves the number most isn't Odoo: it's how much your data needs cleaning.
Mistakes that raise the cost (and how to avoid them)
- Migrating "the whole history" out of fear of losing it. It's almost always enough to keep the old system for reference. Migrate balances and catalogs, archive the rest.
- Not cleaning before loading. Loading duplicates and expired RFCs guarantees CFDI rejections on day 1. With CFDI 4.0 the recipient's data must match their certificate EXACTLY.
- Skipping test stamping. Never go to production without stamping in a test environment first.
- Underestimating training. Technology is 30% of success; team adoption is the other 70%.
Why migrate with iTechDev
Migrating an ERP isn't copying data: it's redesigning how your company operates. At iTechDev we're a software factory and Odoo Ready partner, with CMMI Level 2, REPSE, more than 200 projects delivered, 5.0★ on Clutch, and bilingual nearshore operation between Monterrey and Texas. We work with a fixed-price budget and, when something needs development, we build it as our own Python/OWL module with 100% of the code yours, no lock-in.
And the proof we don't invent: we run our own company on Odoo 19. We migrate knowing what it's like to operate the system every day.