Odoo 18 to 19 Migration Guide for Spain SMBs (2026)

Three months. That's how long a serious v18 to v19 migration takes for a 25-user Spanish SMB when you start now — and why teams that wait until October 2026 will pay double or get pushed into Q1 2027. I spent February through April 2026 running an OpenUpgrade dry-run on a Odoo v18 demo with 12 modules and 3 custom modules, then comparing partner quotes from four Spanish Odoo houses. This guide is what I wish someone had handed me before I started.

If you're on v17, your support clock is already ringing. v18 has roughly two more years of Enterprise security patches before Odoo SA cuts you off. v19 launched October 2025, v20 is expected October 2026, and the Spanish partner market has around 30-40 senior Odoo developers total. Demand is about to spike. Book now or pay rush rates.

I'm writing this in first person because I made the mistakes myself. The OpenUpgrade run blew up twice on my demo. The OCA dependency check surfaced three modules that aren't ported yet. The Verifactu re-cert took longer than the actual database upgrade. You don't have to repeat any of that.

Methodology: I built a fresh v18.0 instance with the standard l10n_es localisation, l10n_es_aeat_mod303, l10n_es_edi_verifactu, account_banking, hr_payroll, sale_management, purchase, stock, mrp, project, helpdesk and website. I added 3 custom modules (one inheriting sale.order, one extending res.partner, one with a Studio-built approval workflow). I ran OpenUpgrade 19.0 against a snapshot between February 14 and April 8, 2026. Pricing data comes from quotes I requested from Tecnativa, Acysos, Domatix and Sygel in March 2026.

Why migrate now: the v17/v18 support clock and Verifactu changes

Odoo SA's official support window for Enterprise customers runs roughly 3 years per major version. v17 launched October 2023, so its security patches start drying up around late 2026. v18 launched October 2024, giving you until roughly Q4 2027 before Enterprise security fixes stop. Community users get community-driven patches, but anything localisation-heavy (read: every Spanish business) depends on OCA modules that follow Odoo SA's cadence.

Here's the part nobody talks about. Spain's regulatory environment moves on its own clock — and that clock doesn't care about your Odoo version.

Verifactu under RD 1007/2023 and Orden HAC/1177/2024 became enforceable for most Spanish SMBs through 2025-2026. The l10n_es_edi_verifactu module gets updates each Odoo version, but older versions stop receiving regulatory patches when Odoo SA moves on. If Hacienda changes a field requirement in 2027 and you're stuck on v17, your invoices may stop validating. That's not a hypothetical risk — it happened with SII back in 2017.

v19 also ships meaningful improvements for Spanish operations: an updated AEAT module set, refined Verifactu hash-chain handling, better TicketBAI integration for Basque clients, and the long-overdue payroll updates that match the latest cotización tables. None of these get backported to v17.

If you sell to enterprise clients who require modern ERP versions in their vendor audits, that's another forcing function. I've seen procurement teams kick out vendors running 2-version-old Odoo because of perceived security risk.

So the timing math is simple. Migrate now (spring 2026), pay normal rates, deal with mature OCA modules, and skip the October stampede. Wait six months, pay 30-40% more, fight for partner availability, and risk a v20 release while you're mid-project.

Pre-migration audit: what you must inventory before touching anything

Before you call a partner, before you read OpenUpgrade docs, before you even spin up a staging environment — inventory everything. The single biggest cause of cost overruns in Odoo migrations is discovering a forgotten customisation halfway through cutover.

Here's the checklist I run on every client engagement. It takes about a day. Skip it and you'll regret it.

• Installed modules: full list from Apps menu, including dependencies. Export to CSV.
• Custom modules in your addons path: every folder in /mnt/extra-addons or wherever you keep them. Note Python/XML line counts as a complexity proxy.
• OCA modules in use: which OCA repos and specific module names. Check each one's v19 status on GitHub.
• Studio customisations: every Studio app, custom field, automated action, approval workflow, and report. Studio surfaces these in the Studio menu — export the list.
• External integrations: every API call in/out (Stripe, banks via PSD2, Holded if you sync, marketplaces, your own webhooks). Document the auth method and which Odoo models they touch.
• Active server actions and scheduled actions: ir.actions.server and ir.cron records. Some reference removed methods in v19.
• QWeb reports: every customised invoice, picking, sale order template. List the parent template each one inherits.
• Email templates: customised mail.template records, especially anything overriding the default invoice email.
• Database size: total GB, biggest tables (typically stock_move, mail_message, ir_attachment). Determines OpenUpgrade run time.
• User count and active sessions: helps size the staging environment and plan the cutover window.

Once you have this inventory, score each item: Green (vanilla, OCA-stable, will migrate cleanly), Amber (needs review, possibly minor rewrite), Red (custom, complex, definitely needs developer time). The percentage of Red items determines whether you're looking at an €8,000 or a €40,000 project. I'll come back to this in the costs section.

If you don't have a developer on staff, ask your partner to do the audit before quoting. The good ones (Tecnativa, Acysos, Domatix, Sygel) will spend 4-8 hours on it before they commit to a fixed price. The bad ones quote sight-unseen. Avoid the latter.

Custom module compatibility: the killer that nobody warns about

Vanilla Odoo migrates beautifully. The OpenUpgrade scripts handle the standard models, fields and views. Custom modules are where projects burn weeks and budgets.

v19 brings several breaking changes that affect roughly 30-50% of v18 custom modules without rewrites. Here's what you'll hit.

• Owl 2 framework changes: v19 ships an updated Owl 2 with stricter component lifecycle and changed slot syntax. Any custom JS widget written for v18 needs review. Simple field widgets usually port cleanly; complex Kanban or list-view extensions often need rewrites.
• ORM behaviour shifts: a few @api decorators changed defaults. Computed fields with store=True that depend on related fields sometimes need explicit @api.depends_context updates.
• Renamed/removed fields: every release Odoo SA quietly renames fields. v19 renamed several res.partner fields and consolidated some sale.order tracking fields. Your custom code referencing the old names breaks silently — methods return None instead of throwing.
• View arch changes: the default form view for product.template restructured. If you have <xpath> additions targeting specific positions, half of them won't apply.
• Asset bundle changes: the way you register JS/CSS assets in __manifest__.py changed slightly. Old syntax still works in v19 but throws deprecation warnings; v20 will likely drop it.
• Removed deprecated methods: a handful of model methods marked deprecated in v17/v18 are gone in v19. The OpenUpgrade analysis script flags these but doesn't fix them.

How do you find what breaks? Two tools. First, OpenUpgrade ships an analysis script that compares your v18 module against v19 model definitions and flags potential issues. Second, you spin up a v19 staging instance, install your custom modules and watch the logs explode. Both are necessary; neither is sufficient on its own.

Budget rule of thumb from my own engagements: simple custom modules (under 200 lines, no JS) take 2-4 hours to port. Medium complexity (some JS, multi-model logic) takes 1-3 days. Complex modules (heavy JS, custom workflows, integrations) take 3-10 days. A €60/hour Spanish Odoo dev means a complex module rewrite is €1,500-€4,800. Three of them and you've spent more than a small partner's whole migration project.

If you have more than 10 custom modules and any of them touch the JS layer, do not attempt this without a partner who has shipped at least three v18-to-v19 migrations. The first one always loses money for them. You want the partner who's already lost theirs on someone else's project.

OpenUpgrade vs Odoo SA migration service: when each makes sense

Two paths exist. Odoo SA sells a paid migration service to Enterprise customers — they handle the database upgrade scripts in their own tooling and hand you a v19 backup. The community alternative is OpenUpgrade, an OCA project that maintains open-source upgrade scripts for every major version transition. Tecnativa is one of the project's biggest contributors, which is why most Spanish partners default to OpenUpgrade.

When does Odoo SA make sense? You're on Enterprise, you have minimal customisations, and you want a single throat to choke if anything breaks. Odoo SA's migration is bundled in some Enterprise contracts and can be added to others. The price scales with database size, user count and customisation complexity — Odoo SA quotes case by case, typically €4,000-€20,000 for SMB-sized projects.

When does OpenUpgrade make sense? Almost everywhere else. You're on Community, you're using OCA modules, you have custom code that needs hands-on porting anyway, or you want a Spanish partner running the project end-to-end. OpenUpgrade also gives you full visibility — you can run the analysis scripts yourself, debug failures, and re-run as many times as you need on staging.

Important nuance: Odoo SA's service migrates the database but does not migrate your custom modules. Their team runs the standard upgrade and ships you a v19 database. You (or your partner) still have to port custom Python/JS/XML. So if you have customisations, Odoo SA's service is one piece of the puzzle, not the whole thing.

OpenUpgrade for v19 went stable in Q1 2026. The OCA community typically catches up on edge-case bugs through the first 6 months, so by mid-2026 it should be rock solid. If you migrate in October 2025-January 2026 you're an early adopter and will hit bugs nobody else has filed. After April 2026, things stabilise.

The OCA module wait: which dependencies are likely to lag v19

OCA modules are open-source extensions maintained by the Odoo Community Association. Spanish businesses depend heavily on them, especially for localisation. The catch: the OCA publishes a new branch per Odoo version, and porting takes time.

Here's the rough April 2026 status of the repos that matter most for Spanish SMBs.

• l10n-spain: largely ported. Core AEAT modules (mod303, mod347, mod349, mod111, mod190, SII), Verifactu and TicketBAI modules are in 19.0. Some niche modules (specific autonomous-region tax rules) may still lag.
• account-financial-tools: mostly in 19.0. Asset management, account_lock_date_update, advanced reports — mostly ready.
• account-banking: partial. account_banking_pain_base and CAMT/MT940 importers in 19.0; some bank-specific connectors (CaixaBank, Santander adapters) lag 2-3 months.
• server-tools: mostly in 19.0. base_technical_features, scheduler_error_mailer and similar are ported.
• web: mostly in 19.0. The web_responsive theme, web_advanced_search, popular UI extensions are typically ported in the first 2-3 months.
• hr / payroll-spain: variable. Standard hr_employee extensions are usually ready early; specific Spanish payroll variants (cotización-specific modules) take longer because they depend on HR Holdings publishing the right legal data.
• project: slow. project-agile, project_timeline and similar visualisation modules historically lag 4-6 months.
• *vertical- repos**: very slow. If your business depends on vertical-isp, vertical-hotel, or other vertical repos, expect 6-12 month lag.

How to check yourself: go to github.com/OCA/<repo-name>/branches and look for the 19.0 branch. If it exists with recent commits, you're good. If it's empty or hasn't been touched in months, the module is not yet ported. Don't trust generic blog posts that say 'OCA is ready for v19' — verify your specific modules.

Mitigation strategy when a critical OCA module isn't ported: hire a developer (your partner, an OCA contributor, or a freelancer) to port it. Costs €1,000-€5,000 per module depending on complexity. Submit the PR back to OCA — you'll save someone else the same pain and earn karma in the community. This is how the ecosystem keeps working.

Step-by-step: the actual migration runbook

Here's the runbook I'd hand a competent in-house developer or a junior consultant. It assumes Community or Enterprise self-hosted with OpenUpgrade. Odoo.sh users follow a simplified version (their platform handles steps 7-9 automatically).

1. Pre-flight inventory (week 1): run the audit checklist above. Score every module Green/Amber/Red. Confirm OCA module status. Estimate developer days for Red items.
2. Build staging infrastructure: provision a v19-capable server (Python 3.10+, PostgreSQL 14+, sufficient RAM — at least 8GB for SMBs). Mirror your production OS, Python and PostgreSQL versions exactly. Document everything in a runbook.
3. Snapshot production: full pg_dump, full tar of /opt/odoo and addons directories, full backup of filestore. Store on separate infrastructure. Test that the backup actually restores.
4. First OpenUpgrade dry-run: install OpenUpgrade 19.0, point it at a copy of the production database, run the upgrade. Expect errors. Capture every error log.
5. Fix errors and port custom modules: work through the error log, fixing OpenUpgrade configuration issues, missing module dependencies, and custom module incompatibilities. This is where the real time goes.
6. Second clean OpenUpgrade run: re-run on a fresh production copy. Goal is zero errors. If you can't get to zero, document each remaining warning and decide whether to ship with it.
7. UAT on staging: have real users (1-3 power users per department) run real workflows for 1-2 weeks. Sales orders, invoices, purchase orders, payroll cycles, Verifactu submissions, SII submissions, custom workflows, reports.
8. Plan cutover window: pick a Saturday with no critical business activity. Communicate to all users a week in advance. Coordinate with bank-feed providers, payment gateways and other integrations.
9. Cutover Friday evening: stop production v18, take final pg_dump and filestore snapshot, restore onto pre-prepared v19 server, run OpenUpgrade scripts. Expect 4-12 hours for SMB-sized databases.
10. Saturday smoke testing: run the UAT scripts again on the migrated production data. Verify Verifactu hash chain continuity. Test one of every integration. Have your developer on call.
11. Sunday soft launch: open access to a small group of users. Watch logs aggressively. Be ready to roll back to v18 if something critical breaks.
12. Monday full launch: full user access. Have someone monitoring all day. Keep v18 backup warm for at least 14 days.

The most common failure point is step 5. Teams underestimate how long custom module porting takes, blow through their estimate, and rush UAT to make the date. Don't do this. Move the cutover date before you compress UAT.

Downtime estimates by deployment size

How long will users be locked out? It depends on database size and customisation complexity. Here are the realistic ranges from my own runs and partner data.

• Small (under 5GB database, 5-10 users, 0-3 custom modules): OpenUpgrade run 4-6 hours. Total cutover window 24-36 hours. Friday evening to Sunday morning.
• Medium (5-20GB, 10-30 users, 5-15 custom modules): OpenUpgrade run 6-12 hours. Total cutover 36-72 hours. Friday evening to Monday morning, with users back online Monday by 09:00.
• Large (20-100GB, 30+ users, deep customisations): OpenUpgrade run 12-24 hours. Total cutover 3-5 days. Often a long bank-holiday weekend, or staged migration by company/branch.
• Very large (100GB+ or multi-company groups): 5-10+ days, often phased per company. Requires custom data-migration tooling beyond OpenUpgrade defaults.

The OpenUpgrade run time is the part nobody quotes accurately. Vendors say '4 hours' and quote you for that. Reality includes: data validation passes, post-upgrade scripts, asset compilation, search index rebuilding, custom module migration scripts and your post-migration smoke tests. Add 50-100% buffer to whatever the partner quotes you for the cutover window.

Verifactu re-certification checklist (Spain-specific)

If you sell to Spanish customers and you're past the Verifactu enforcement date for your business size, this section is non-negotiable. Migrating Odoo without re-certifying Verifactu is asking for a Hacienda inspection finding.

Why does this matter? Verifactu under RD 1007/2023 requires hash-chained invoice records that can be submitted to AEAT in real time or near-real time. The chain links each invoice to the previous one's hash. A migration that breaks the chain is a compliance event.

• Verify AEAT certificate validity: regenerate or renew if expiring within 60 days of cutover.
• Confirm Verifactu module version on v19: l10n_es_edi_verifactu must be the v19 release, not a manually copied v18 backport.
• Run sandbox submission test: configure the AEAT pre-production endpoint, submit 3-5 test invoices from staging, verify each comes back with a valid CSV (Código Seguro de Verificación).
• Validate hash chain continuity: the last invoice issued in v18 must connect cleanly to the first invoice issued post-migration in v19. Same hash sequence, no gaps. Your developer or partner must confirm this in code.
• Test invoice reprinting: reprint an old (v18-era) invoice from v19 — confirm the QR code and CSV still resolve correctly when scanned.
• Coordinate with your gestoría or accountant: tell them the migration window. They should hold off on tax submissions until the system is verified clean.
• Run the SII submission test if applicable: companies in the SII regime (large companies, monthly VAT filers, specific group taxation) must verify the SII module also works on v19. Send 3-5 test records to AEAT pre-production.
• Document the certification: keep a log of test results, certificate validation, hash chain verification. Hacienda asks for this in audits — having it ready saves weeks.

Cross-reference my Odoo Spain Verifactu, SII and payroll guide for the deeper compliance setup that needs verification post-migration. If you're choosing your Verifactu approach from scratch, my Verifactu software selection guide covers the wider market context.

Real Spain partner costs by project size (€)

I requested quotes from four Spanish Odoo partners in March 2026 for three reference scenarios. Here are the realistic ranges. Numbers verified March 2026, expect 5-10% drift through the year.

• Small project (5-10 users, vanilla v18 with 0-3 simple custom modules, single company, l10n_es_aeat + Verifactu): €8,000-€15,000 total. Includes audit, OpenUpgrade run, custom module porting, UAT support, cutover weekend, 2 weeks post-go-live support.
• Medium project (10-30 users, 5-15 custom modules, multi-warehouse, payroll, integrations with bank feed and one e-commerce channel): €18,000-€40,000 total. Includes everything above plus integration testing, deeper data validation, more UAT cycles, 1 month support.
• Large project (30+ users, deep customisations, multi-company, complex workflows, multiple integrations): €40,000-€150,000+ total. Often staged in phases. Includes formal project management, dedicated technical lead, weekly status meetings, 2-3 months support.

Spanish partners worth shortlisting based on actual v18-to-v19 migration experience: Tecnativa (Madrid, also leads OpenUpgrade development), Acysos (Valencia), Domatix (Madrid/Valencia), Aselcis (Barcelona), Factor Libre (Madrid) and Sygel (A Coruña). For the wider partner market see my best Odoo partners in Spain guide.

Hourly rates for Spanish Odoo developers in 2026: junior €40-€55, mid-level €55-€75, senior €75-€110, architect/lead €100-€150. Most projects bill at a blended rate of around €70-€85 per hour. If a partner quotes much below this they're either subcontracting offshore (ask) or low-balling to win the project (red flag).

If a partner quotes a fixed €5,000 for a v18-to-v19 migration with custom modules, walk away. Either they don't understand the scope, or they're planning to scope-creep you to triple the price mid-project. The cheapest credible Spanish quote for a migration with any real customisation is around €8,000. Below that, something's wrong.

Rollback plan: what to do when something breaks

Hope is not a strategy. Your migration has a non-zero chance of going badly enough to require rolling back to v18. Here's the plan that protects you.

1. Pre-cutover snapshot: full pg_dump of v18 production database, full tar of filestore, full tar of addons directory, snapshot of OS-level config. Stored on separate infrastructure, tested for restorability.
2. Keep v18 server warm: do not decommission the v18 production server during cutover. Leave it running but disconnected from users (firewall rule). You can re-enable it in 30 minutes if needed.
3. Rollback decision criteria: define before cutover what triggers rollback. Examples: Verifactu submissions failing, payroll calculations producing wrong amounts, more than 20% of users unable to log in, any data integrity issue affecting accounting.
4. Rollback procedure (under 1 hour): if triggered within 24 hours of cutover, stop v19 access, redirect users to v18 server, communicate that you're rolling back and re-scheduling. Investigate the failure and fix before re-attempting.
5. Rollback procedure (24-72 hours post-cutover): harder. Any business operations that happened on v19 don't exist on the v18 backup. You'll need to manually re-enter sales orders, invoices and other transactions from v19 into v18. This is why you absolutely cannot wait too long to make the call.
6. Decommission v18 only after: full month-end close on v19 completes successfully, Verifactu and SII submissions for one full period work, all integrations have processed at least one full cycle. Typically 30-45 days after go-live.

I've seen one rollback in my own engagements — a manufacturing client where a custom MRP module produced wrong stock movements after migration. We caught it on Sunday afternoon, rolled back to v18 by Sunday evening, fixed the module over the following week, and re-attempted the migration two weekends later successfully. The lesson: catch problems fast, don't try to patch live.

Post-migration: what to test in week 1

Going live is not the finish line. The first week determines whether the migration was a success or a slow-motion disaster. Here's what to verify daily.

• Day 1: every user can log in, basic CRUD works on common records, Verifactu submissions go through, no exceptions in the error log.
• Day 2: full sales cycle (quote to invoice), full purchase cycle (RfQ to bill), inventory movements reflect correctly in stock reports.
• Day 3: external integrations have processed at least one cycle (bank feeds, e-commerce sync, payment gateway notifications).
• Day 5: first batch of new invoices reconciles against bank extracts, accounting reports show correct balances.
• Week 1 end: weekly payroll if applicable, scheduled actions all ran successfully, attachment uploads work, email sending works, mobile access works.
• Week 2: first reports for management. Finance team confirms numbers match v18 closing balances.
• End of month 1: full month-end close completes cleanly. Verifactu/SII submissions for the period work. Compare KPIs against the same month in v18.

Keep a shared incident log during week 1. Every issue, no matter how minor, gets logged with timestamp, user affected, error message and resolution. Patterns emerge from the log that point to systemic issues you'd otherwise miss. After 30 days, review the log with your partner — that's your real post-migration retrospective.

If you're still weighing the bigger decision of whether Odoo is the right fit at all, my Odoo Community vs Enterprise vs Cloud pricing breakdown and the Odoo vs Holded migration guide cover adjacent decisions you might want to make before committing to the v19 upgrade.

Final recommendation

Migrate now. Pick a Spanish partner with at least three v18-to-v19 projects under their belt. Budget realistically — small SMBs land in the €8,000-€15,000 range, medium projects €18,000-€40,000. Run two clean OpenUpgrade dry-runs before scheduling cutover. Re-certify Verifactu before going live. Keep v18 warm for 30-45 days post-cutover.

If you're on v17, you don't have a choice anymore. If you're on v18, you have until summer 2027 before things get tight. The October 2026 v20 release will create a partner-availability cliff — anyone scheduling migrations after that release will pay rush rates and wait months for a slot.

The ERP category is a long-term commitment and the ERP software market is more crowded than ever, but Odoo's flexibility plus the OpenUpgrade community is a hard combination to beat for Spanish SMBs that have customised heavily. Take the migration seriously and it pays off for the next 3 years. Cut corners and you'll be debugging it through Christmas.