The consultant's first impulse is to change the software. It's easy, sellable, and gives the feeling something big is being done. The client buys it because the problem is visible: "our software falls short". The apparent conclusion is to change it. Almost always, it isn't.
In recent years, most projects we've rescued started with a migration recommended by another provider. Companies that moved from a settled ERP to a modern one, from one billing tool to another, from a spreadsheet to a monthly-license platform. In two out of three cases, operations kept breaking in exactly the same places. The tool was new. The problem wasn't.
What migration really costs
The new licence invoice is the visible part of the cost, and not always the biggest. When you break down a real migration, three cost layers appear that are rarely budgeted:
- The learning cost. The whole team has to readjust routines. In the months after migration, productivity drops between 15% and 30%. It rises again when everyone adjusts. That negative dip rarely appears in the business case.
- The cost of lost information. No migration is clean. There are always fields that don't fit, historical data that gets truncated, relationships that break. The team spends months recovering information by hand.
- The cost of prior customisation. The previous tool had been adapted to ten years of concrete decisions. Reproducing those adaptations in the new one is a project of its own, and it's usually discovered late.
Adding these three layers, a reasonable ERP migration in a 30-person company usually falls between €40,000 and €120,000 of real cost, excluding the licence. And that cost is only justified if the new ERP does something the old one absolutely cannot do.
Almost never the case
In most mid-sized companies, the software they use is not bad. It's underused. The ERP has a recurring billing module nobody activated because nobody read the documentation. The CRM allows automatic exports nobody configured. The payment gateway has webhooks nobody connected. The Friday spreadsheet is not the software's fault: it's that nobody built the bridge between the software and the spreadsheet.
The first question we ask, before considering changing anything, is simple: which features of the current program aren't being used, and why? The most common answer is "we didn't know" or "nobody had time". Rarely is it "we tried and it didn't work".
When migrating does make sense
We're not always against it. There are three scenarios where we recommend migrating without hesitation:
- The vendor has announced end of support. Not up for debate. A system without security updates is a time bomb. The migration is planned in advance, not improvised in the quarter it expires.
- The business model has changed and the tool doesn't cover it. A typical example: a service company starts selling subscriptions too, and its ERP doesn't handle recurring revenue natively. Before migrating we check if there's a module or integration; if not, migrating is right.
- The maintenance cost of the current one exceeds migrating. This happens with very old systems that require own infrastructure, expensive licences, and specialised staff. The numbers speak for themselves and usually say migrating is cheaper over three years.
Outside these three scenarios, the default answer should be not to migrate. Not because the new software is worse, but because the switch cost is rarely recovered by the functional improvement.
The alternative: connect what you already pay for
Almost no company has a software problem. They have several correct tools, none in charge of the others, and people acting as bridges between them.
The alternative to migrating is integrating. Take the tools the company already pays for and make them talk to each other. In technical terms: build an intermediate flow — with n8n, Make, a custom function, or whatever fits — that consumes data from one system and drops it into another without a person in the middle. In economic terms: turn a €60,000 migration cost into an €8,000 integration cost.
The difference isn't just price. It's how many things don't break: no retraining, no lost history, no renegotiated customisations. Operations go on exactly the same, except that the human bridge between programs has ceased to exist.
How we approach it in each project
Before proposing anything, we spend two weeks mapping the current ecosystem. What tools exist, what data lives in each, who moves each piece of data from one to another. It's a boring but essential exercise. In 80% of cases, the map makes it crystal clear that we don't need to change programs: we need to connect three specific points. In the remaining 20%, a structural problem appears that does justify migrating. At that point, the conversation is honest and with data, not with impulse.
This way of working costs less, takes less time, and above all respects what the company has built over the years. It's the only reason we work this way.