Seven stages. One rollback plan at every one of them.

Typically 2–5 business days

We start with what the instant quote wizard couldn't see: your actual database and codebase, not self-reported ranges. You get read access to a staging copy or a scoped export — never production credentials, never a live-system login. We confirm current version, edition, hosting, and every custom module and Studio change, then reconcile that against what was originally estimated.

• Full module inventory: which are OCA/community add-ons, which are bespoke, which touch core models
• Confirm target version and edition with you in writing before any code is touched
• Flag anything that changes the estimate — this is when a quote gets revised, not after work starts

Typically 3–7 business days

We take a full backup and run it through Odoo's own upgrade utilities where a managed path exists, or our own migration tooling for CE→CE jumps. This surfaces the real risk factors early: orphaned records, broken foreign keys from old customizations, ir.model.data references pointing at modules that no longer exist, and any table bloat that will slow the actual cutover window.

• Schema diff between your current version and target version's data model
• Identify deprecated fields and models that need explicit migration scripts
• Size the actual cutover window based on real record counts, not estimates

Timeline scales with custom module count

Every custom module gets read, not just re-installed and hoped for. We check Python constraints and ORM calls against the target version's API (deprecated methods get flagged here, not discovered at go-live), review any overridden core methods for compatibility, and audit XML views and QWeb reports for markup that no longer renders correctly. Studio customizations are handled as structured data, not treated like hand-written code — they get their own review pass since they migrate differently.

• Line-by-line review of custom Python models and overrides for target-version compatibility
• Third-party module compatibility check against the target version's app store listing
• Written list of exactly what changes and why, before we write a single migration script

Run at least twice before UAT

The actual migration runs first against a full copy of your real database on an isolated staging environment — never synthetic test data, since synthetic data hides the exact edge cases (unusual character encodings, years-old partial records, orphaned attachments) that break real migrations. We run it, log every warning and error, fix what broke, and run it again. Most projects run this cycle two to three times before anyone outside Hadoopt sees it.

• Full migration log reviewed line by line, not just checked for a "success" exit code
• Timed dry runs, so the real cutover window has a tested duration, not a guess
• Rollback tested here too — restoring the pre-migration backup is rehearsed, not assumed

Typically 3–10 business days, set by you

The migrated staging environment goes to your team, not just ours. Your people run the workflows that actually matter to your business — closing an invoice, running a manufacturing order, generating the report your finance team pulls every month — because that's the testing our own QA checklist can't fully replace. Every issue gets logged to one shared list, triaged, and fixed before we schedule the production cutover.

• Your team gets a dedicated staging login for the full UAT window
• Single tracked issue list — no chasing separate emails or chat threads
• Cutover isn't scheduled until UAT sign-off, not on a fixed calendar date

Scheduled around your acceptable downtime window

Go-live happens in the window you tell us works for your business — evenings, weekends, whatever disrupts operations least. A final backup is taken immediately before the migration starts. We run the exact same rehearsed sequence from the test migration stage, with the rollback plan staged and ready the entire time, not written down as a theoretical fallback.

• Final pre-migration backup taken and verified before anything else happens
• Same migration sequence already rehearsed in Stage 4 — no improvisation
• Live status updates for the duration of the cutover window

14 days of priority response, standard from here

The two weeks after go-live are when the issues UAT didn't catch tend to surface — a report that only runs at month-end, an integration that only fires on a specific trigger. We stay on fast-response priority support through this window at no extra charge. After hypercare, the system transitions to whatever ongoing support arrangement you choose, or none at all if you're comfortable taking it from here.

• Priority response for anything surfacing post-launch, no separate support contract needed yet
• Clear handoff document: what changed, what to watch for, who to contact

01

Answer four short steps

Version, edition, complexity, apps. Under two minutes.

02

Get a range immediately

Generated from your answers, on screen, no waiting.

03

Free review confirms it

We look at the real thing within 24 to 72 hours, then lock the price.