A rollout run as a programme phases, approval gates and clear governance

As a programme, not an installation. We start with mobilisation and governance, then current-state analysis and fit-gap, then the approved blueprint, then configuration and build — with data, integration and change running in parallel — then testing and training, then cutover and hypercare. Between phases there is a gate: we do not move on until the phase’s deliverables are earned, and the decision at that gate belongs to the steering committee rather than to the vendor.

We give no binding duration before the scope analysis, and anyone who gives one before that is selling a promise rather than a plan. What this page gives are planning ranges per phase to help you build your own schedule. The real duration is set by the number of legal entities and sites, the number of business processes, the volume of data and its migration path, the number of integrations with other systems, and the speed of the client’s own decisions — the last of which delays projects more than anything else in practice.

Migration is a parallel track that starts in phase two, not at the end of the project, and it is selective rather than total: open balances, reference data, items and active customers — not every transaction of the past ten years. We clean before migrating and reconcile after: record counts and open values are compared between the old and new systems before go-live, and anything excluded is documented with the reason. Systems that remain — a warehouse, a production line, a government portal — are connected through interfaces designed in advance rather than workarounds.

Governance and participation, not the software. Projects that land have three things in common: a process owner inside the company for each scope (not from our side), a steering committee that meets on a fixed cadence and decides at the gates, and a client team that takes part in analysis and testing rather than receiving the result at the end. The projects that slip are rarely missing technology — they are projects whose decision maker did not show up at the right time.

Yes, and we often recommend it: launch a limited, high-impact first scope (accounting, purchasing and inventory, for instance) in one entity, then expand by module and by entity. That lowers risk, produces a tangible result early, and lets the team learn on a small scope before scaling. The one condition is that the foundation is built to expand from day one — a unified chart of accounts, items and units — otherwise scaling later becomes a clean-up project.

Yes: multiple legal entities with separate or shared databases depending on your case, multi-currency with exchange differences, taxes and e-invoicing, and consolidated group reporting. Before committing we verify the details of your situation — ownership structure, intercompany transactions and transfer-pricing policy — because those details decide the design far more than the name of the system.

Odoo licence fees, hosting, infrastructure, networking and hardware; legal, tax and regulatory advice; audit; redesigning business policies on management’s behalf (we design with you, but the decision is yours); and running your legacy systems for you. We build, configure, test, train, document and support the launch; the items above stay out of scope and are contracted directly with the vendor or the relevant specialist.