Operations that survive the launch
Adoption planned in. Stabilisation funded. Reporting holds up under month-end pressure from week one.
When implementations are rated by year three, not by launch day,
The build is the easy part. The handoff is the work.
We deliver end-to-end implementations built around the handoff, not just the build.
Stabilisation and ownership are part of the engagement, not phase-two negotiations.
Adoption planned in. Stabilisation funded. Reporting holds up under month-end pressure from week one.
Runbooks. ADRs. Knowledge transfer. The day the original engineers leave is part of the design.
Phased budget aligned to phased rollout. Phase 2 scope visible during Phase 1, not negotiated under pressure after launch.
Audit trail, approvals, access controls, encryption designed in from discovery, not retrofitted.
The launch worked. The team applauded. Then the slow erosion began.
The architecture is sound. The configuration is done. Go-live happened. Then the delivery team disperses, the original engineers move on, the client's internal team is left with documentation and a Slack channel, and somewhere around month four the system starts to drift. Reporting gets manually repaired again. Audit cycles need special preparation. Custom modules without tests start gathering bug reports nobody fixes.
The system inherits their absence.
Real production load surfaces issues nobody has bandwidth to fix.
Documentation exists. The conversations that would teach the system don't happen.
Bespoke modules without test coverage become the first thing nobody dares refactor.
It becomes a handoff decision.
That's where implementation stops being a delivery decision.
Each shows up in leadership meetings well before anyone formally says "the implementation didn't land."
Numbers that matched at go-live diverge by month three. No one explains it.
The customisations from launch start accumulating issues nobody addresses.
One person who built it knows everything. When they're unavailable, escalations stall.
Each compliance cycle requires special effort because the operating model wasn't designed for ongoing audit.
Teams quietly invent spreadsheet bridges around parts that don't fit them.
What was supposed to extend the system turns into a separate budget conversation that never resolves.
These aren't build problems. They are handoff problems wearing implementation-failure disguise.
Implementations fail in patterns. The patterns are handoff problems, not build problems.
Treated as out-of-scope. Real production load surfaces issues nobody has bandwidth to fix.
Documentation exists but the conversations that would teach the system don't happen.
Operational scenarios live in the original engineer's head.
Architecture decisions live in commit messages. The "why" disappears with the engineer.
Build plans are detailed. Adoption plans are an afterthought. Users revert to spreadsheets.
Bespoke logic ships without automated coverage. The first refactor everyone is afraid of.
The next phase becomes a project re-do because the first phase didn't leave room for it.
Implementation failure looks like a delivery problem. It is almost always a handoff problem in disguise.
Every implementation that disappoints after launch shows some version of the same mistake.
The engagement ended at go-live instead of at confident ownership.
When stabilisation is out-of-scope, knowledge transfer is theoretical, and the original team disperses on the launch date, the implementation becomes a deliverable instead of a system. Day-one works. Day-one-hundred drifts.
The build is rarely where implementations fail. The handoff is.
Four principles separate implementations that hold at year three from ones that drift.
Go-live is the start of stabilisation, not the end of the engagement. The 6 to 12 weeks after go-live are funded, scoped, and staffed from day one.
Pair sessions, shadowing, runbook drills. The internal team operates the system before the original team leaves.
Not the configuration, not the integration, not the launch. The deliverable is confident internal ownership.
Phases close when the business is ready, not when the project schedule wants them to.
Four blocks: internal proof, the phased build cadence, the implementation architecture, and where this work shows up in our existing book.
Weeks 1 to 4. Systems, workflows, approvals, reporting, ownership gaps. Output: written operating model.
Weeks 4 to 8. Solution design reflecting how the business should operate. Deliberate before any module is configured.
Weeks 8 to launch, in 2 to 4 phases. Each phase production-stable before the next starts.
Parallel weeks 6 to launch. Treated as data-quality and ownership work, not just technical mapping.
Weeks 10 to launch. Training, sandbox time, process refinement before go-live, not as an after-thought.
6 to 12 weeks post go-live. Adoption, defect resolution, reporting confidence, process refinement. Included.
4 weeks after stabilisation. Runbooks, ADRs, training, escalation path. The internal team takes the keys with confidence.
Business context at the top, operating model in the middle, implementation team underneath. Beneath that, the handoff bridge to the internal team. The bridge is the part most engagements forget to design — and the part that determines whether the implementation still works at year three.
Four outcomes plus the six numbers we measure across an implementation engagement.
Reporting holds up. Customisations stay maintained. Audits stop being projects.
The day the delivery team leaves is not a risk event.
Phase budgets reflect phase readiness. Phase 2 scope is visible during Phase 1, not negotiated under pressure after launch.
The next wave is planned during Phase 1, not negotiated after.
Knowledge coverage per subsystem is the single most informative — it tells leadership whether the internal team can actually operate the part of the system that's nominally theirs.
An implementation engagement is the right move when you are committing to multi-month delivery and care what happens after, leadership can name an internal owner who will inherit the system, and you're willing to fund stabilisation as part of the engagement.
It's too early when you want the cheapest delivery for the launch date, no one inside the business will own the system post go-live, or you expect the original team to operate the system indefinitely — in which case a Long-Term Support engagement layered alongside is the honest shape.
A typical end-to-end implementation runs 12 to 36 weeks of delivery, plus 6 to 12 weeks of stabilisation, plus 4 weeks of handoff. Multi-entity or multi-region engagements typically run 6 to 12 months end-to-end.
Operating model in writing. Solution design deliberate before any module is configured.
2 to 4 phases. Each phase production-stable before the next starts.
Adoption, defect resolution, reporting confidence, process refinement. On our time, not as change orders.
Runbooks, ADRs, paired sessions, runbook drills. The internal team takes the keys with confidence. Then either an engagement close or a transition to Long-Term Support.
Stabilisation isn't a phase you bolt on. It's the part of the engagement where the system earns trust.
Six engineering non-negotiables. Each is the floor, not the ceiling.
6 to 12 weeks after go-live, funded and staffed before launch.
Not after the first incident. The team writes the runbook for what they just built.
Architecture decisions documented at the moment they're made, not reconstructed later.
Pair sessions, shadowing, runbook drills scheduled and tracked, not assumed.
The next phase has architecture room reserved before the current phase closes.
Target-user usage is measured before "done." If adoption is below threshold, stabilisation continues.
Direct answers for executives committing to a multi-month implementation.
A single-entity, single-region Odoo implementation typically takes 12 to 18 weeks from discovery to go-live, plus 6 to 12 weeks of stabilisation. Multi-entity or multi-country implementations are usually 6 to 12 months end-to-end including stabilisation and handoff. Timelines depend more on the readiness of internal process decisions than on the software itself.
A phased rollout deploys in waves aligned to business readiness (finance first, then sales, then manufacturing, then advanced reporting). A big-bang launches everything at once. Phased reduces risk; big-bang reduces dual-running cost. We default to phased; big-bang is appropriate only when dual-running cost is genuinely prohibitive.
The 6 to 12 weeks after go-live are scoped, funded, and staffed in the original engagement, not billed as a separate phase. Adoption, defect resolution, reporting confidence, and process refinement happen on our time, not as change orders.
Pair sessions, shadowing, runbook drills, and ADR walk-throughs scheduled across stabilisation. Knowledge transfer is practiced, not just documented. The internal team operates the system in production before our team leaves.
Phase 2 is architected during Phase 1, with room reserved in the operating model for what's coming next. If Phase 2 turns out larger than Phase 1, the cause and the scope discussion happen up front — not as a surprise change order mid-build. Our discipline is to scope honestly during Phase 1; budget conversations on Phase 2 then happen on evidence, not on optimism.
A realistic Odoo implementation for a growing operation varies with module scope, customisation, data migration scope, and rollout phasing. Multi-entity or multi-region implementations extend beyond that. Licensing is separate. Concrete pricing ranges are confirmed in the consultation conversation.
Most fail at the handoff, not the build. Stabilisation under-funded, knowledge transfer skipped, customisations without tests, the original engineer becomes a dependency. The pattern is governance and ownership more than technology.
Yes — we implement integrations, AI workloads, cloud infrastructure, custom applications, and customer-facing platforms on top of and alongside Odoo. Most implementation engagements include multiple of the Solutions pages.
Trained on the system. Has runbooks. Knows the escalation path. Has at least one engineer who has operated each subsystem during stabilisation with our team alongside. Knowledge coverage is greater than one for each subsystem.
Yes, when the project state is recoverable. We handle that under the System Rescue engagement model, which starts with a forensic audit to understand what's recoverable and what should be replatformed.
Some clients move into a Long-Term Support engagement so the operating discipline continues. Others take full internal ownership with documented runbooks and ADRs. Either path is supported; the choice is yours, not bundled into the implementation contract.
Implementations fail at the handoff, not the build. The discipline that separates successful implementations from disappointing ones is the plan for who owns the system after the delivery team leaves.
Stabilisation is the 6 to 12 weeks after go-live where adoption, defect resolution, and reporting confidence build. Treating it as out-of-scope is the most common cause of post-launch drift.
Phased rollout aligns delivery to business readiness. Finance and inventory first. Then sales and procurement. Then advanced reporting. Each phase production-stable before the next starts.
No fixed-price-and-disappear pitch. Fit-first.