The ERP still runs. The business has outgrown it.
What does ERP modernization actually mean?
ERP modernization is the decision work before a rebuild, a version jump, or a platform change. It is not a migration project by another name. It starts with what the business needs the system to do next, what the current estate can honestly carry, and whether replace, evolve, or stabilise-first is the cheaper path over three years.
Most “modernization” conversations arrive as a vendor pitch: new modules, a version bump, a greenfield implementation. The hard part sits earlier. The chart of accounts still works. The warehouse process does not. Finance trusts a spreadsheet that shadows the ERP. Custom code freezes the upgrade path. Nobody can say which of those is a product problem and which is an ownership problem.
We treat modernization as a diagnosis with three honest exits: keep and evolve (including a planned Odoo migration), replace with a new implementation, or rescue and stabilize first because the live system is already failing users. Selling the exit before the diagnosis is how estates get migrated twice.
Does any of this sound familiar?
Leadership wants “a modern ERP” but cannot name which process the current one blocks next quarter.
The version is years behind, and every upgrade conversation dies on custom modules nobody owns.
Two or three satellite tools do the work the ERP was supposed to do, and nobody will turn them off.
Month-end still closes, but only because three people maintain a parallel spreadsheet.
A previous partner proposed a full rewrite; the business never got a written case for evolve-vs-replace.
You are comparing migration quotes without a risk register of what breaks when the data moves.
If you recognised three of these, you do not need a bigger quote. You need a decision that survives contact with operations.
What these decisions looked like in practice.
VitaOne · evolve, then change edition
A health and wellness operator came with a fragile Enterprise estate. Stabilization came first. The modernization call was unusual: migrate to Community for long-term cost and control, then build AI-assisted practitioner workflows on top. The version and edition move was the midpoint of the engagement, not the end.
Read the VitaOne case study →Cemseal · modernize while production keeps running
A multi-company manufacturer moving v14 toward v19 across states and users, with banking integrations and field loyalty still live. Modernization here meant a controlled version path on a system the business could not pause.
Read the Cemseal case study →Multi-company estate · consolidation as the modernization
Apex Group: multi-company implementation and migration work where the modernization was the estate shape itself (companies, access, and a platform that could hold growth), not a feature catalogue.
Read the Apex case study →What a modernization engagement decides, and what it does not.
In the decision
- A written evolve-vs-replace recommendation, with the operational evidence behind it.
- Inventory of custom code, integrations, and shadow processes that freeze or force a path.
- A risk register you keep whether or not you continue with us.
- A recommended next engagement: migration, implementation, rescue, or managed continuity.
- Clear fences so delivery quotes are not reopening the strategy fight mid-project.
Not in the decision
We will tell you not to modernize the wrong thing.
Founders have worked on Odoo since v6. Fifteen-plus migrations sit behind the delivery pages. That history is useful here only as judgement: which custom modules are debt, which are the business, and when a version jump is the wrong first move.
We will not trash a previous partner. Most modernization failures are incentive failures: the project ended at go-live, and the estate kept growing past the design. Thirty-five percent of our delivery effort is post-go-live work. If the recommendation is “stabilize first,” that is Rescue, not a polite delay of a migration sale.
How we work is documented on How we work.
How a modernization read runs.
-
01
Situation call
What is blocked in operations, what leadership thinks “modern” means, and what must not break during any change. If the live system is already failing users, we route to Rescue before strategy theatre.
-
02
Estate read
Modules, versions, integrations, shadow tools, and the upgrade freezes. You get a written picture of what you actually run, not what the licence list says.
-
03
Options on paper
Evolve (including migration), replace (implementation), or stabilise first. Each option carries cost shape, risk, and what you give up. No single vendor pitch dressed as a strategy.
-
04
Recommended path
One primary recommendation and the conditions under which we would change it. Delivery work (if any) is scoped only after this lands.
-
05
Hand-off into delivery or stop
You can take the write-up to anyone. If you stay with us, the next page is the matching Service or Rescue engagement, not a vague “phase two.”
Questions we get first.
Is this the same as an Odoo migration?
No. Migration is the delivery of a version, edition, or hosting move. This page is the decision work that says whether that move (or a replacement, or a rescue) is the right first step. When the path is a migration, we send you to Odoo Migration.
When should we replace the ERP instead of evolving it?
When the core process model cannot carry the next three years of the business without perpetual custom theatre, or when the shadow systems have become the real system of record. We put that in writing. We do not sell replace by default.
Our system is already failing month-end. Start here?
Start at Rescue & Stabilization. Modernization strategy on a system that cannot close is how you migrate a mess into a newer mess.
Do you only modernize onto Odoo?
Odoo is the core of our Digital Platforms practice (v6 through v19). We will say when another platform is the better fit for the operation. We will not sustain a platform we do not run.
What does this cost?
A fixed-scope read after the situation call, priced in writing before work starts. We do not publish a catalogue price because estate size and integration surface vary too widely. Delivery projects are separate quotes after the recommendation.
Can we bring an existing partner’s migration quote into this?
Yes. The read is useful precisely when quotes exist without a shared risk register. We are not interested in a fight over the account; we are interested in whether the quote matches the estate.
Get a clear path before the rebuild.
Tell us what the current system blocks. We will say evolve, replace, or stabilise first, and which Service page (if any) comes next.