Replacing legacy software as an SMB

Does your system still work, but just not well enough anymore? That is the hardest moment to make a call. It hasn't fallen over, so there is no panic. But every new customer, every new hire, and every integration takes just a bit more effort than it should. Replacing legacy software as an SMB is such a stubborn problem for exactly that reason: you have to tackle something that still runs, without your shop grinding to a halt in the meantime.

In this post we walk through the signs that your system is holding you back, the three ways to replace it, how to decide the order, and what it realistically costs. No big promises, just an honest picture.

How do you know your legacy system is blocking your growth?

Outdated software rarely breaks all at once. It gnaws. The question isn't whether it's perfect, because no system is, but whether it's holding you back. A few concrete signs.

Everything gets slow, your people too

Reports that take minutes. A screen that stutters when three people work in it at once. Tasks your team solves with a workaround because "that's just how it works". Those workarounds are hidden costs. They show up on no invoice, but they eat hours.

The integration inferno

Every new package you want to add, accounting, a webshop, a scheduling tool, needs its own separate integration. And every integration is fragile. Something breaks in one system and you only notice when the invoices in the other stop adding up. If you're afraid to connect something because you don't know what will fall over, you're in that inferno.

There's one person who really understands it

Maybe the most dangerous sign of all: key-person dependency. One developer, one vendor, or one colleague who is the only one who knows how it all fits together. As long as that person is around, things are fine. But your business can't hang on whether someone is on holiday or takes a job somewhere else. Knowledge that lives in only one head isn't an asset. It's a risk.

If you recognise two or three of these, the conversation is no longer about whether you do something, but when and how.

The three replacement strategies: big bang, phased migration, and the strangler-fig approach

There are roughly three ways to modernise outdated software. They differ hugely in risk. For most SMBs, one of them drops off fast.

Big bang: everything switched over at once

You build the new system alongside the old one, and on a chosen Sunday you move everything over. Sounds decisive. The problem: you only find out at go-live whether it really works, and by then your whole business is on the new system. If something goes wrong, a lot goes wrong at once. For a small, manageable system it can be fine. For the beating heart of an SMB, it's usually too much risk in one moment.

Phased migration: moving over in pieces

You cut the system into chunks and move them one by one. First the customer data, then the invoicing, then the scheduling. After each step the business runs stable again before you go further. Slower, yes. But your mistakes stay small and you can go back. For most SMB migrations, this is the sensible baseline.

The strangler-fig approach: the new grows around the old

The name comes from the strangler fig, a plant that grows around a tree until it fully replaces it. That's how you tackle this too. You build new functionality alongside the old system and route traffic to it bit by bit. The old system keeps running until the last piece is taken over, and then you switch it off. You never have a moment where everything is vulnerable at once. This takes a bit more thinking up front, but it's the safest route if your system is truly business-critical.

Which one fits you depends on how critical the system is and how much downtime your business can take. If you're torn between custom and off-the-shelf software, that's a separate call you're best off making up front. We wrote about it separately in custom or off-the-shelf software.

What decides the order? Mapping your value stream before you write a single line of code

Here's the most common mistake: people start with the part that's technically easiest, or with whatever the vendor happens to offer first. Wrong question. The question is: where is the most value and the most risk?

Map your value stream first. Literally follow how an order, a customer, or a request moves through your business, from first contact to payment. At which step does it get stuck? Where are the manual patches? Where are your biggest costs and your biggest opportunities? That's thinking you do on paper, not in code.

A few rules of thumb for the order:

• Start with the part that has the most pain and the least risk. A quick win the team feels right away builds confidence for the rest.
• Untangle the integrations early. As long as everything hangs together every which way, you can't replace anything on its own. Make sure parts can run independently.
• Don't leave the business-critical part for last. Otherwise you spend months building at the edges while the core keeps pinching.

If you want to genuinely renew a part rather than move it over one to one, treat that piece like an MVP you have built: start small, test it for real with your people, and only expand once it works. That way you cut the chance of building something no one turns out to use.

This phase sometimes feels like "we're not doing anything yet". That's a misunderstanding. Deciding on a good order is the work. It determines whether the migration goes smoothly or overruns by six months.

Costs and timeline: realistic expectations for an SMB migration

The honest truth about the cost of replacing a legacy system: it depends too much on your situation to put a number on it without knowing your system. Anyone who gives you a fixed figure without looking is guessing. What mainly drives the price:

• The state of your current data. Moving clean, well-structured data over is work. Cleaning up messy data first is often more work than the migration itself.
• The number of integrations. Every connection to another system is something that has to be rebuilt and tested.
• How much you want to renew versus move over. Recreating exactly what's there is cheaper than improving it. But recreating it exactly sometimes doesn't solve your original problem.

On timeline: a phased or strangler-fig approach takes longer in lead time than a big bang, and that's deliberate. You trade speed for the certainty that the business keeps running. Don't count on weeks but on months, in steps, with a working business in between each one. A sensible start is small: migrate one clearly defined part, learn from it, and use that learning to price the rest more sharply.

If you want a fuller picture of how we look at pricing, read what it costs to build a website or app.

Want to take a look at it together?

If your system is "just not good enough anymore" and you want to know which approach fits your situation, we're happy to think along with no strings attached. No sales pitch, just looking at your value stream together and an honest order. Feel free to get in touch, and we'll set up a call.