Implementation · Business
Business: several departments on one system
The package for a company replacing scattered tools or an ageing ERP. Scope built with you in workshops, configuration close to standard, real data migration, and the change management without which a good configuration is still a failed project.
Who it is for
The project is the change, not the configuration
Mid-market companies rarely fail a ERP project on the software. They fail it on two things: data that nobody owned, and people who were told about the new system a fortnight before go-live. This package puts the weight where the risk actually is.
It suits you if several departments have to work on the same records, if you are carrying years of history in tools you want to retire, and if you can name the people who will be key users — because we are going to need them.
Scope
What is included, and what is not
No price on this page: what you can hold us to is the scope. Here it is, from both ends.
Included
- discovery workshops per department, and a written specification you validate or amend;
- configuration of the Odoo apps your processes need, kept close to standard;
- the customisations that earn their keep, each documented with what it will cost at the next version;
- data migration: audit, cleaning, mapping, test loads and open transactions;
- a pre-production environment loaded with your own data, for real testing;
- training per user profile, and change support around go-live;
- a named project manager and a steering committee with written status updates.
Not included
- licences, billed by Odoo per user and per app;
- the cleaning of data we cannot interpret without you — we do the work, you own the decisions;
- unbounded scope changes: new requirements after the specification are quoted, not absorbed silently;
- hardware, network and workstation upgrades;
- multi-entity consolidation and intercompany flows, which belong to the Enterprise package.
The middle line is the one that matters: we flag scope changes rather than absorbing them, because a project that quietly swallows changes is a project that quietly slips.
How it works
The six steps, weighted for a real replacement
The method is the group's; what changes here is where the effort goes. Discovery and migration take up the largest share.
1. Discovery, department by department
Workshops on how the work is actually done, not on how the SOP says it is done. This is where the difference between the two gets found.
2. Specification, written and validated
As close to standard Odoo as your processes allow, with every deviation named. You validate, amend — or stop the project right here, which is a right the method explicitly states.
3. Migration, treated as a workstream
Audit of what you hold, cleaning, mapping, and repeated test loads. Never a single import over the weekend of go-live.
4. Configuration and pre-production
Your own data in a secure environment, so key users can test the real thing and find the real problems while there is still time to fix them.
5. Training and change management
Per profile, on your records. The people who were part of the workshops become the people who train their colleagues.
6. Go-live and hypercare
A controlled cut-over with a rollback plan, followed by close support before moving to a run package.
Start your transformation
Replacing tools your teams have used for ten years?
The software is the easy part. Tell us how many departments are involved and what data you are carrying, and we will tell you how the phases should be cut.
FAQ
Frequently asked questions
Months rather than weeks, and phased. The variable is not the number of apps but the number of departments changing their way of working at once — which is why we phase by process rather than switching everything on a single date.
More than most vendors admit. Key users are needed in workshops, in testing, and for the data decisions only you can make. A project where the client is not involved is a project delivered on assumptions, and those surface at go-live.
Where it earns its keep, and each time with the upgrade cost written down. Over-customisation is the most expensive mistake in this kind of project because it is paid every year, at every version. Our default answer is to change the process; when the process is your competitive edge, we change the software instead.
We audit it first and tell you honestly what is worth migrating. Carrying over ten years of unusable records is a common and expensive instinct; the usual approach is full master data, open transactions, and history kept accessible elsewhere.
Hypercare for a defined period, then a support and run package sized to what you actually need. The reference pages on Odoo support and Odoo training describe the subject itself.
Let's talk
Ready to consolidate your tools onto Odoo?
Tell us which departments are involved, what you are replacing and the constraints on the calendar. We will get back to you with a phasing plan and the risks we can already foresee.