The ERP that built the business is now holding it back.

It depends on the size of the organisation, the number of sites, and how much of the old system needs rebuilding versus simplifying. The blueprint phase, where we map your processes and design the Odoo setup, typically runs four to six weeks. From there, a single-site replacement usually takes a few months, and multi-site or multi-country groups take longer. The blueprint gives you a realistic timeline up front, not a number pulled before anyone has looked at the system.

Migrating data from a 15-to-20-year-old SAP, Exact, Navision, or Sage system is the part that worries people most, and the part we plan first. The migration strategy is defined in the blueprint phase, not at go-live. We map what data exists, what the business actually needs in the new system, and what should be archived rather than moved. The history that matters (compliance records, customer transaction history, audit trails) is preserved on purpose. The rest is retired deliberately, not by accident. A legacy migration runs through a sandbox cycle before any production cutover, so issues surface in testing, not on go-live day.

No. Big-bang go-lives, where everything switches in one weekend, only make sense when the timeline genuinely justifies the risk. More often we phase it, by site, by entity, or by module, so each step is contained. Where it reduces risk, we run the old system and the new one in parallel for a period, so the business has a fallback while people find their feet. The blueprint sets the sequence, the dependencies, and what runs alongside what during the transition.

There is no list price, because no two replacements are the same. The main drivers are the number of users, the number of sites or entities, how many surrounding systems Odoo has to connect to, the volume and state of the data to migrate, and how much needs custom development versus standard configuration. We work standard-first, which keeps cost down: the more of your processes that fit Odoo as it comes, the less there is to build and maintain. The blueprint puts a concrete number on the table before you commit to the full project, so the investment is clear up front, not discovered along the way.

This is one of the first things the blueprint phase looks at. Old systems accumulate customisations and workarounds that were never written down, and often only one or two people still understand them. We map what each one does and why it exists, working with the people who know the system rather than around them. Some of that logic turns out to matter and gets rebuilt properly in Odoo. Some of it was a workaround for a limitation that no longer applies, and gets dropped. Either way, the knowledge moves out of people's heads into a documented design, so the business no longer depends on who happens to still be around. 

We do one thing. Odoo, and only Odoo. A generalist implementer spreads across SAP, Microsoft Dynamics, NetSuite, and others, bringing general ERP knowledge to each. We bring depth in one. Every project teaches the next. Every custom build is reviewed by someone who has solved the same thing before. Our developers think Odoo-native, not retrained from another system. For a legacy replacement, that focus is the difference between a partner learning your platform on your project and one that has done it hundreds of times.

A first conversation to understand where you are: the system you are on, what is holding the business back, and where you need to get to. We tell you honestly whether Odoo is a fit, and what a realistic path looks like. If there is a match, the next step is a tailored demo built around your operations, then a blueprint proposal. If there is not, we will say so.