"Six Weeks and You're Live" — and Other Timeline Myths
Walk into any Odoo sales demo and you will hear some version of the same promise: "Most companies are live in six to eight weeks." That statement is not technically a lie — it is just incomplete. A 10-user services firm with one entity, a clean chart of accounts, and zero integrations can absolutely go live in six weeks. A 60-user distributor with three warehouses, a legacy ERP migration, EDI requirements, and a custom commission plan cannot. The gap between those two realities is where most Odoo implementations quietly fall apart.
At Octura Solutions we have delivered more than 100 Odoo implementations as an Odoo Ready Partner, with a 95% on-time go-live rate. The single biggest predictor of whether a project lands on time is not the partner, the module list, or even the budget — it is whether the timeline the client signed up for matched reality. A 14-week plan that delivers in 14 weeks feels like a win. A "6-week" plan that delivers in 14 weeks feels like a failure, even though the work is identical.
We call the most common failure mode the "two-month honeymoon, then reality" pattern. Weeks 1–8 look great: demos are crisp, configuration screens fill up, stakeholders are excited. Then UAT begins and the cracks appear. Data imports fail on edge cases. Finance discovers the tax matrix is wrong for half the product catalog. Operations realizes the shipping integration was never actually built. What was sold as a six-week sprint becomes a four-month scramble, and the executive sponsor — who has been promising go-live for 90 days — starts losing credibility internally.
This guide is the timeline conversation we wish every prospective client had before signing a statement of work. It covers our four-phase methodology, realistic ranges for 10-, 25-, 50-, and 100-user deployments, what actually speeds a project up, what quietly slows it down, and the preparation checklist that turns an optimistic plan into an achievable one.
The Octura Four-Phase Methodology: What Actually Happens Week by Week
Every Odoo implementation timeline we publish is built on the same four-phase structure. The phases are sequential in intent but overlapping in practice — configuration starts before discovery formally closes, and training begins before the last test script is signed. Understanding what each phase is actually for is the difference between a plan that holds and a plan that slips.
Phase 1 — Discovery (1–2 weeks for small, 3–4 weeks for enterprise)
Discovery is where we turn a signed statement of work into an executable plan. It is not a sales exercise and it is not "requirements gathering" in the old waterfall sense. Discovery produces five concrete artifacts: a process map for every in-scope workflow, a data migration plan with source-to-target mappings, an integration inventory with authentication owners, a gap list separating standard configuration from custom development, and a week-by-week schedule with named client resources committed to each deliverable.
The most common discovery failure is ending too early. Teams under pressure to "start building" skip the gap list or defer the integration inventory. Three weeks into configuration, someone discovers that the EDI connector for a top-three customer was never scoped. That single omission can add four weeks to the timeline and 20% to the budget. Our rule: no discovery sign-off without all five artifacts, even if it means pushing the phase by a week.
Phase 2 — Configuration (3–8 weeks for standard, 10–16 weeks for enterprise)
Configuration is the longest phase and the one most prone to optimistic estimation. It covers company and chart of accounts setup, product catalogs, tax matrices, warehouse structures, pricing rules, journal definitions, user access and security groups, report templates, email flows, and every custom module. For a 25-user services firm this is four to six weeks. For a 100-user multi-entity manufacturer with 12 integrations, it is 10 to 16 weeks — and that is with a dedicated team of three consultants plus a developer.
The discipline that keeps configuration on schedule is build-in-slices. Instead of configuring all of Sales, then all of Inventory, then all of Accounting, we deliver end-to-end slices: one product category from quote to cash, then a second, then a third. Each slice is reviewed with the business before the next begins. This catches process misunderstandings in week three instead of week ten, when rework is cheap.
Data migration runs in parallel with configuration, not after it. By the end of week two of configuration we want a first dry-run of customer, product, and open-balance imports into a dev environment. Real data surfaces real problems — duplicate SKUs, inconsistent tax codes, orphaned records — and every one of those problems is an issue we do not want to discover the week before go-live.
Phase 3 — Testing and Training (2–3 weeks for standard, 3–5 weeks for enterprise)
This phase has two tracks running simultaneously. Track one is user acceptance testing — structured test scripts executed by real end users against production-like data. Track two is end-user training, which is deliberately hands-on: users complete their own job scenarios in a training environment, not a sandbox with demo data.
The unit of progress in UAT is the signed-off scenario, not the logged defect. A defect list is noise; a scenario that finance has explicitly signed off on ("I can close the month using this system") is signal. We target 100% scenario sign-off before go-live authorization. For a 25-user project that is roughly 40 scenarios across sales, purchasing, inventory, and accounting. For a 100-user project it can exceed 150.
Phase 4 — Go-Live and Hypercare (2–4 weeks for standard, 3–5 weeks for enterprise)
Go-live is a weekend, not a moment. The typical sequence: freeze the legacy system Friday at end of business, execute final delta data migration Friday evening, run parallel checks Saturday morning, authorize go-live by Saturday afternoon, bring users online Monday morning with on-site or remote floor support. The first week post-cutover is triage — not new development, not scope additions, just keeping the business running while users adjust.
Hypercare is the three-to-five weeks after cutover where our team remains attached to the project at reduced but still significant capacity. We fix defects, tune performance, adjust reports, retrain users on confusing flows, and produce a post-implementation punch list. Skipping hypercare — or treating it as optional — is the single biggest driver of implementation regret. See our companion guide on navigating the first 90 days after Odoo go-live for what comes next.
Realistic Odoo Implementation Timelines by Company Size
The single variable that most reliably predicts Odoo project duration is user count, because user count is a decent proxy for organizational complexity: more users usually means more roles, more processes, more edge cases, more stakeholders to align, and more data to migrate. The four ranges below are drawn from our internal delivery data across 100+ implementations. They assume a competent partner, a committed client, and a scope that matches the company's actual operating complexity — no heroics required.
| Company Size | Total Duration | Discovery | Configuration | Test + Train | Go-Live + Hypercare |
|---|---|---|---|---|---|
| 10 users (SMB) | 6–8 weeks | 1 week | 3–4 weeks | 1–2 weeks | 1 week |
| 25 users (mid-SMB) | 8–12 weeks | 2 weeks | 4–6 weeks | 2 weeks | 2 weeks |
| 50 users (mid-market) | 12–16 weeks | 2–3 weeks | 6–8 weeks | 2–3 weeks | 2 weeks |
| 100+ users (enterprise) | 20–30 weeks | 3–4 weeks | 10–16 weeks | 3–5 weeks | 3–5 weeks |
10-User Implementation: 6–8 Weeks
The 10-user profile is typically a single-entity services or small-trading business: one company, one currency, one warehouse (or none), a standard chart of accounts, one or two integrations (usually Stripe or an email marketing tool), and a finance lead who doubles as the executive sponsor. Modules are usually Sales, Invoicing, Accounting, CRM, and perhaps Project or Inventory.
At this size, discovery can realistically compress to one focused week — two workshops, a data review, and a signed scope. Configuration runs three to four weeks because the surface area is small: one product structure, one sales workflow, one AR process. Testing and training overlap heavily since the same 10 people are doing both. Hypercare is a single week because the blast radius of any issue is small. Projects at this size slip when the client treats the timeline as casual — missed data exports and delayed decisions turn 6 weeks into 12 faster than any technical problem.
25-User Implementation: 8–12 Weeks
The 25-user profile almost always adds organizational complexity that 10 users does not have: a separate accounting person, an ops/inventory owner, a sales manager with pipeline requirements, sometimes a marketing stakeholder. The scope typically widens to full Sales + Purchase + Inventory + Accounting, with two or three integrations (payment processor, shipping carrier, and sometimes a CRM or marketing tool), and occasionally a second warehouse or a simple multi-currency setup.
Discovery extends to two weeks to accommodate multiple departments. Configuration runs four to six weeks with two consultants covering finance and operations in parallel. Testing becomes formalized — we start using signed-off UAT scenarios here, not just ad-hoc walkthroughs. Training splits by role: finance, ops, and sales each get dedicated sessions. Hypercare is two weeks because issues in one department tend to surface issues in another.
50-User Implementation: 12–16 Weeks
At 50 users we are usually in mid-market territory: two or more entities or branches, multi-currency, multi-warehouse, departmental budgeting, a formal month-end close, four to six integrations, and often the first real custom development (a commission engine, a customer portal, a bespoke report). The executive sponsor is now distinct from any operational lead, and there is a steering committee that meets bi-weekly.
Discovery takes two to three weeks because the process maps are non-trivial and the integration inventory has real authentication complexity. Configuration stretches to six to eight weeks with three consultants — finance, operations, and a developer — and we deliver in slices aligned to business units. Testing includes formal test data sets, regression scripts, and integration testing across every external system. Go-live is still a weekend, but hypercare runs two weeks with a named support lead assigned to each business unit. For cost planning at this size, our Odoo implementation cost calculator gives a defensible budget range.
100+ User Implementation: 20–30 Weeks
At 100+ users the project is no longer an implementation — it is a program. There are multiple entities, often across jurisdictions. Manufacturing, distribution, or field service modules are in scope. Integration counts reach double digits (ERP-adjacent systems, EDI, PIM, WMS, BI, HRIS, SSO, e-commerce, etc.). Data migration covers several million records from two or three legacy systems. Custom development is substantial and often includes modules that will outlive the initial project.
Discovery is three to four weeks with two senior architects, because a misread requirement here costs months later. Configuration is 10 to 16 weeks with a team of four to six and deliberately phased milestones. Testing and training extend three to five weeks because the number of scenarios is in the hundreds and user training cohorts have to be scheduled around operations. Go-live is almost always phased — one business unit or geography per cutover weekend, with hypercare rolling with the waves. Projects at this size that try a single "big bang" go-live fail more than half the time; see why Odoo implementations fail for the detailed pattern.
What Actually Speeds Up an Odoo Implementation
When we look at the projects that finished on the low end of their size-band estimate, five client-side factors appear again and again. None of them are glamorous, and none of them involve writing a single line of code.
Clients who deliver the first full export of customers, products, and open balances by the end of discovery typically go live two to four weeks faster than those who deliver it mid-configuration. Clean data means deduplicated records, consistent tax codes, reconciled open AR/AP, and a single source of truth per entity. Messy data is not a technical problem — it is a time tax paid at every subsequent phase.
Projects with a single decision-maker who can resolve scope disputes within 48 hours outperform projects with a committee every single time. The sponsor does not need to know Odoo — they need to have budget authority and the credibility to say "we are not adding that to scope" and have it stick.
End users who see the system in week three — not week nine — catch process misunderstandings while rework is cheap. We push clients to expose a configured slice to a small UAT group as soon as it is testable, even if it is incomplete. The feedback compounds.
Every hour not spent on custom development is an hour not spent on specification, build, test, and regression. Clients who treat custom code as a last resort — not a default answer to process quirks — consistently finish on time. Odoo's standard modules cover 85–95% of most business requirements; the remaining 5–15% is where discipline pays off.
At 50+ users, splitting go-live into two or three waves (by module, geography, or business unit) reduces the failure surface and gives the project team a real-world feedback loop between waves. A phased go-live takes one to two weeks longer in aggregate than a big-bang, but it succeeds far more often — and a successful phased cutover still beats a failed big-bang restart by months.
What Quietly Slows Down an Odoo Implementation
The inverse of the accelerators is just as useful — often more so, because the patterns below are the ones clients underestimate going in. Each of these has added four or more weeks to a project we have delivered, and every one was preventable.
"While we're at it, can we also…" is the most expensive phrase in any implementation. New fields, new reports, new workflows added during configuration compound — each addition affects testing, training, and data migration. Every change request should be priced in calendar days, not just hours, and the executive sponsor should approve any scope change that extends the go-live date.
Clients often underestimate the time required to deduplicate customers, normalize product SKUs, reconcile open invoices, and retire stale records. When this work slips into the test phase, every test cycle re-surfaces the same bad data, UAT sign-offs stall, and the go-live date has to move.
Integration work always takes longer than it looks because it depends on a third party: their credentials, their sandbox, their response times, their outages. Integrations confirmed in discovery are manageable. Integrations remembered in week seven are the single most common reason for a missed go-live date.
Some teams treat every standard Odoo behavior as a negotiation. Weeks disappear into debating whether a custom field, a custom button, or a custom report is strictly necessary. The antidote is a standing rule: default to standard, document the business cost of the gap, and only authorize customization when that cost is material and explicit.
It sounds trivial but it is not. A two-week absence of the finance lead in the middle of UAT can add three weeks to the overall timeline because nothing downstream can sign off. Map the project schedule against every key resource's planned time off before signing the SOW, and adjust the plan rather than pretending the absence will not matter.
Client Prep Checklist: Do These Six Things Before the Kick-Off
The checklist below is the single most reliable lever a client has to compress an Odoo implementation timeline. None of it requires technical knowledge. All of it requires decisions made before discovery starts — which is exactly when clients have the most leverage and the least pressure.
| Checklist Item | Who Owns It | When |
|---|---|---|
| Draft chart of accounts (even if imperfect) | Finance lead | Before kick-off |
| Final user list with roles and access levels | Executive sponsor | Before kick-off |
| Integration inventory with system owners and auth notes | IT lead | Week 1 of discovery |
| Data source export (customers, products, open balances) | IT + finance | Week 2 of discovery |
| Stakeholder RACI for every in-scope process | Executive sponsor | Week 1 of discovery |
| Week-by-week commitment calendar from each key user | Department leads | Before kick-off |
The full Octura Odoo Implementation Prep Pack — chart of accounts template, user list template, integration inventory worksheet, and RACI matrix — is available as a PDF from our services page. Use it as a working document during pre-kick-off; we update the shared version weekly during discovery.
Frequently Asked Questions About Odoo Implementation Timelines
Across our 100+ delivered projects, the average is approximately 11 weeks. Small deployments (under 15 users) cluster around 7 weeks, mid-market (25–50 users) around 12–14 weeks, and enterprise projects typically run 22–28 weeks. "Average" is a weak predictor for any single project — size and scope dominate.
Yes — but only for a narrow profile: under 15 users, a single entity, standard chart of accounts, no or minimal integrations, and committed client resources. Outside that profile, any six-week promise is a marketing number, not a delivery number.
Configuration is the longest phase in every size band, representing roughly half of the total calendar time. This is where modules are set up, processes are built, data is migrated, and customizations are written. It is also the phase most exposed to scope creep.
Data migration runs in parallel with configuration and typically takes two to six weeks of elapsed calendar time depending on data volume, quality, and the number of source systems. The technical migration itself is usually a fraction of that — most of the time is spent cleaning and validating.
Hypercare is the 2–5 weeks of elevated support immediately after go-live, where the implementation partner remains closely engaged to resolve issues, tune performance, and retrain users. Two weeks is the minimum for small projects; enterprise deployments should plan for four or five.
A competent Odoo partner consistently delivers faster than an in-house-only team, because methodology, reusable configuration, and known patterns outweigh hourly rate differences. The right question is not "partner or not" but "which partner and with what governance."
Missing a go-live date is not automatically a failure — it is a signal. The right response is to pause, diagnose the root cause (scope, data, testing, or resources), reset the plan with the executive sponsor, and communicate transparently. Projects that miss and re-plan succeed; projects that miss and hide fail.
Under 30 users with a single entity: big-bang is usually appropriate. At 50+ users, multi-entity, or heavy integrations: phase by business unit or geography. The extra week or two of calendar time is far cheaper than a botched cutover affecting the whole company simultaneously.