Odoo Implementation Methodology: Discovery to Hypercare

An Odoo ERP implementation runs through six phases: discovery, design, build, validation, cutover and hypercare. The methodology is not the list of phases, which every provider has, but the gate between each pair of them: a short set of conditions that must be true, written down and signed by a named person on your side, before the next phase spends money. This guide describes each gate, the artefact that proves it, who signs it, and what it looks like when a phase is quietly failing.

It leaves out two things covered elsewhere on this site. Durations by project size are in our Odoo implementation timeline, and the settings that are hard to reverse after go-live are in the Odoo implementation checklist. Every Odoo document quoted below is the 20.0 version, checked on 29 October 2026.

Why gates instead of a calendar

A plan with dates tells you when a phase is supposed to end. A gate tells you whether it has. The expensive mistakes in Odoo are taken early and invisibly, and surface at the first month-end or tax return. Odoo's own accounting guide warns that "the order in which accounting data is transferred into Odoo, whether manually or via import, is crucial", and that selecting another fiscal localization package "is only possible if no journal entry has been posted yet" (Odoo 20 accounting get started). A method that lets anyone post a test invoice in production before the localization is signed off has no gate where it needs one most.

The method at a glance

Phase	The question it answers	Exit artefact	Who signs	What becomes hard to undo
1. Discovery	How does the business actually run, and which decisions are irreversible?	Process map per flow, data inventory, decision register	Project owner	Hosting and edition
2. Design	Which rung of the fit-gap ladder does each process use?	Solution blueprint with decision records	Finance and operations owners	Localization, company structure, costing method
3. Build	Does each scenario run end to end with migrated data?	Configured copy of production, timed migration dry run	Key users per flow	Opening data structure, custom code
4. Validation	Will the people who do the job accept it?	UAT evidence, defect log, go/no-go record	Process owners	Trained habits
5. Cutover	Can the switch be executed inside the window, and reversed?	Rehearsed cutover runbook, reconciliations	Project owner and finance	Posted entries, lock date
6. Hypercare	Is the business running on Odoo without the old system?	Closed first month-end, defect trend, second-deployment list	Project owner	Nothing; that is the point

How it maps onto Odoo's own Quickstart method

Odoo publishes an implementation methodology of its own, and many proposals borrow its vocabulary. Odoo's description of the Quickstart approach gives five phases and a share of project time for each:

Odoo phase	Share of time	What Odoo says it covers
GAP analysis	10%	Business analysis, gap analysis, phasing and budget
Kick-off	5%	Align stakeholders on the methodology, plus standard training
Implementation	80%	Cycles of analysis, development, validation and key-user training
Go-live	5%	End-user training and bug fixes
Second deployment	Variable	Broaden scope or add custom features

Source: Odoo Quickstart implementation methodology, odoo.com blog, 20 October 2026.

Two ideas from that method carry into the gates below. The customer appoints a single point of contact, "your internal project ambassador and 'super key-user'", responsible among other things for "becoming an internal Odoo expert and ensuring the first level of support for their colleagues"; and "standard, out-of-the-box Odoo features should always take priority" (Odoo Quickstart methodology). The gates make both checkable: a decision has a named signer, and a customization must climb the fit-gap ladder before it is approved.

Phase 1: Discovery

The question: how does the business actually run, which parts of that are a process and which are a workaround of the old system, and which decisions ahead are irreversible?

How it is done well. Discovery is observation, not interview. The person who receives goods shows how receiving happens, on a real delivery, with the real paperwork. Each flow is written up as steps with its documents, systems and decisions, alongside an inventory of the systems to be replaced, integrated or left read-only, and the decision register: the choices that are hard to reverse, with an owner against each.

The hosting decision belongs here. Hosting determines what you are allowed to build. Odoo states that "Odoo Online is incompatible with custom modules or modules from the Odoo Apps Store" (Odoo Online documentation), and its upgrade service "does not cover" changing hosting type or switching editions (Odoo upgrade documentation).

Exit gate. Every in-scope flow has a written process map and a named owner. The decision register names, at minimum, hosting and edition, companies versus branches, fiscal localization per company, inventory costing method, and how much history to migrate. The project owner signs the scope, including what is explicitly out.

Signs it is failing. The process maps came from meetings with managers only. A "requirement" turns out to be a feature of the old system rather than a need of the business. The decision register is empty because "we will decide that during configuration".

Phase 2: Design

The question: for each process, which rung of the fit-gap ladder does it use, and what does that commit you to?

Every gap between the process map and standard Odoo is placed on one rung, and may only move up when the rung below has been shown, on screen, to fall short:

Rung	What it means	Decision criterion	Upgrade consequence
Standard	The process runs on Odoo as installed	Default; the business adapts its habit	None
Configuration	A setting, a route, an approval rule, a report layout	Prefer whenever the outcome is the same	None
No-code tools (Automation Rules; Studio on Enterprise)	Fields, views and automations without code	When configuration cannot express it and the change is small	Re-test at each upgrade
Third-party or community module	Someone else maintains the gap	On Odoo.sh or self-hosting, after a maintenance check	Depends on the maintainer
Custom development	Code written for this business	Only for a documented, costed competitive need	You pay to adapt it at every version
Integration	Another system owns the data	When the other system stays the system of record	Interface re-tested at each upgrade

The upgrade column is not decoration. Odoo's upgrade documentation states that a database with custom modules "cannot be upgraded until a version of your custom modules is available for the target version of Odoo", and that compatibility "is the responsibility of the maintainer of your custom module" (Odoo upgrade documentation).

The blueprint is the design artefact: per process, the rung and the apps and settings it uses; a signed decision record for every item in the register, stating the options, the choice, what it rules out and how it will be verified; the migration scope, with objects, history cut-off and field mapping; and the rollout shape, phased or single cutover. One structural decision Odoo settles for you: branches "always follow the parent company's localization", so "entities operating in different countries should be set up as companies, not branches" (Odoo fiscal localizations).

Exit gate. The finance owner has signed the localization, chart of accounts, tax and costing decisions. The hosting decision is final. Every gap sits on a rung with a reason. The parking lot exists, a written list of everything deferred to the second deployment, so that scope additions have somewhere to go other than into this phase.

Signs it is failing. The blueprint is a slide deck with no Odoo screens. Most gaps sit on the custom rung. The migration scope says "everything".

Phase 3: Build

The question: does every in-scope scenario run end to end, with migrated data, in a copy of what production will be?

Build in cycles, each ending with a real scenario. Odoo describes its implementation phase as a series of cycles: analysis, development, validation, key-user training (Odoo Quickstart methodology); what makes a cycle real is its closing demo. Each cycle configures a slice of the blueprint and ends with the key user for that flow running one real scenario on real data while the implementer watches. A cycle that ends with the implementer demonstrating has not ended.

Migration runs as its own track from the first week. The steps are fixed: extract, clean with a named owner per data domain, map to Odoo fields with an External ID column carried from the old system's key, test-import, import into a duplicate, reconcile. Odoo's import documentation describes a Test button to "verify that the data is valid", explains that an ID column lets you "import the same file several times without creating duplicates", warns that "imports are permanent and cannot be undone", and orders related records: "first import the companies, and then the people" (Odoo import and export).

Opening entries follow Odoo's clearing-account method. The accounting guide recommends importing each open invoice or bill "with only the total amount due, rather than individual invoice/bill lines", posting the opening trial balance through clearing accounts, then checking that "the sum of open invoices minus the sum of open credit notes equals the balance of the accounts receivable" and that "all clearing accounts are now balanced" (Odoo 20 accounting get started). Those two checks are the migration's acceptance test.

Exit gate. Every in-scope scenario has been run end to end in a copy of the production database with migrated data, by the key user, with the evidence kept. The migration dry run has been timed. No item in the decision register is open.

Signs it is failing. Configuration was done in a sandbox set up by hand rather than in the database that will become production, so what was tested is not what goes live. Someone posted a test document in the live database "just to see". Scope has grown and the parking lot is empty.

Phase 4: Validation

The question: will the people who do the job accept the system, and does it behave correctly off the happy path?

Where to test. In a neutralized copy of production, with a plan that accounts for what neutralization switches off. Odoo describes a neutralized database as "a non-production database on which several parameters are deactivated", among them planned actions, outgoing emails, bank synchronization, payment providers, delivery methods and IAP tokens (Odoo neutralized database). On Odoo.sh, scheduled actions must be triggered manually or re-enabled, and emails "are instead intercepted using a mail catcher" (Odoo.sh branches). A plan that never triggers a scheduled action by hand and never opens the mail catcher has not tested automated invoicing, follow-ups or customer emails at all.

The environments also expire. On Odoo Online, duplicates "expire after 15 days" and "a maximum of five duplicates can be created per database" (Odoo Online documentation); on Odoo.sh, staging databases "are automatically deleted after one month" and "are not automatically backed up" (Odoo.sh branches).

Who tests and what. The testers are the people who will do the work, not the implementer and not the project owner. Each gets scripted scenarios with expected results. Half the scenarios should be the unhappy path: a credit note, a cancelled delivery, a wrong tax corrected, a partial payment, a return. Every failure goes into one defect log, classed blocking or non-blocking. Key users are trained before they test, and the single point of contact is trained to answer first-line questions, because, as Odoo puts it, "there is no better trainer than a colleague who knows your internal processes" (Odoo Quickstart methodology).

Exit gate. Zero open blocking defects. Each process owner has signed the UAT record for their flow. The go/no-go meeting has happened with the evidence on the table, and the decision is recorded with the non-blocking defects that will go live.

Signs it is failing. The "UAT" was a demonstration users watched. Testers ran only the scenarios that worked in the build demos. The sign-off came from the implementer, or from a manager who did not run a scenario.

Phase 5: Cutover

The question: can the switch to Odoo be executed inside the agreed window, and reversed if it cannot?

The runbook is a timed script with an owner per line: the freeze date after which nothing enters the old system; the final delta import; opening balances posted and reconciled (trial balance line by line, aged receivables and payables per partner, stock valuation against the inventory account); the old system set to read-only, never switched off; scheduled actions reviewed before they are enabled, because an imported open invoice can trigger a reminder email on day one; the first lock date; and the rollback decision, with the time by which it must be taken. Rehearse the whole runbook with a clock running on a fresh copy of production.

Two settings need care. Access rights are checked by logging in as each role, not by reading the configuration; Odoo warns that "making changes to access rights can have a detrimental impact on the database", including leaving "no user" able to change them (Odoo access rights). Lock dates are set deliberately: a Lock Everything date "prevents modifications to any posted journal entries with an accounting date on or before the lock date", while the Hard Lock date "is irreversible to ensure inalterability and to meet accounting requirements in certain countries" (Odoo year-end closing).

Exit gate. The rehearsed runbook completed inside the window. On the day, every reconciliation agrees, the first lock date is set, and the rollback window closed unused.

Signs it is failing. The runbook was written but never rehearsed. The old system was switched off rather than frozen. Nobody can say who decides a rollback, or by when.

Phase 6: Hypercare, then the second deployment

The question: is the business running on Odoo without the old system, and has the project learned enough to plan what comes next?

Hypercare is a fixed period with named people: a responder who answers user questions within an agreed time, and daily triage against the defect log from validation. The real test is not go-live day but the first month-end close and the first tax period filed from Odoo, which is why Odoo's accounting guide advises against switching "in the middle of a tax period", noting that splitting a period between two systems "complicates the tax filing process" (Odoo 20 accounting get started). Plan hypercare to end after that close, not before it.

Exit gate. The first month-end has been closed in Odoo and signed by finance. The defect log shows a falling trend with no open blocking item. The parking lot has been turned into a second-deployment scope. Support transitions to a steady arrangement, an internal administrator or a support and maintenance agreement.

Signs it is failing. Users have quietly reopened the old system or a spreadsheet beside Odoo. Hypercare ended on a calendar date rather than after the first close. The second deployment is the same wish list as discovery, which means the gates never held.

Who signs what

Role	Side	Signs
Project owner	Customer	Scope, discovery exit, go/no-go, cutover, hypercare exit; may delay go-live
Single point of contact	Customer	Day-to-day decisions, test scheduling, first-line support (often the project owner in a small company)
Finance owner	Customer	Localization, chart of accounts, taxes, costing, opening balances, lock dates
Process owners	Customer	Process maps, decision records in their area, UAT for their flow
Data owners	Customer	Cleaning and reconciliation of their data domain
Implementation lead	Provider	The blueprint, the build evidence, the cutover runbook

Two rules keep the table honest: whoever signs a gate has run or watched the evidence behind it, and the provider never signs its own gate.

Reading a proposal against this method

If you are comparing implementation proposals, including ours, ask each provider to show rather than describe five things: the exit criteria for each phase; who on your side signs them; where testing happens and how neutralization is handled; what the parking lot is and who controls it; and what event, rather than what date, ends hypercare. Hold any provider, ours included, to these gates; if you want to see how they apply to your scope, send us the process list from your discovery.

Frequently Asked Questions

What is the Odoo implementation methodology?

Odoo's own Quickstart methodology has five phases: GAP analysis, kick-off, implementation run as cycles of analysis, development, validation and key-user training, go-live, and a second deployment, with a customer-side single point of contact and standard features preferred over customization (Odoo Quickstart methodology). The method in this guide follows that shape and adds a written exit gate, with a named signer, between each phase.

Which decisions must be made before the first journal entry is posted?

Fiscal localization per company and the company-versus-branch structure, because Odoo only allows selecting another localization package "if no journal entry has been posted yet" and branches always follow the parent company's localization (Odoo 20 accounting get started; Odoo fiscal localizations).

Where should user acceptance testing for Odoo take place?

In a neutralized copy of the production database: a duplicate on Odoo Online with the default For testing purposes option left on, a staging branch on Odoo.sh, or a backup restored on your own server with the database manager's Neutralize box ticked (or odoo-bin neutralize run on it); a restore without that option keeps scheduled actions, outgoing email and payment providers live. Because neutralization deactivates planned actions, outgoing emails, payment providers and delivery methods (Odoo neutralized database), the test plan must trigger scheduled actions by hand and read emails from the mail catcher, or those flows go untested.

When does hypercare end?

When the first month-end has been closed in Odoo and signed by finance, the defect log shows no open blocking item, and the parking lot has become a second-deployment scope.