The sequence
Stages 1 to 3 are the free technical review. Nothing is billed until scope is confirmed in writing.
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.
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.
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.
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.
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.
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.
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.