Legacy Modernisation for SMEs: Renewing Applications Without Bringing the Business to a Halt

Every SME owner knows the tension: there is one system that has carried your business forward for years, but that nobody now dares to touch. An order-processing package on Windows Server 2012, a PHP 5 web app that only the original developer understood, a custom Access database that your accounts and production planning both depend on. Legacy modernisation is about giving an honest answer to that situation: when do you replace, when do you build on what you have, and how do you do it without bringing the business to a standstill.

What exactly is legacy modernisation

Legacy modernisation is the full set of decisions and projects that make outdated business applications fit for the next ten years. That might mean moving them to a modern cloud environment without touching the code, rewriting the most painful modules, or replacing a system with a standard SaaS package. It is rarely "throw everything away and start again", and even more rarely "do nothing".

We call an application legacy as soon as one of three things is true: it is hard to find developers who still work with it, the vendor no longer ships security updates, or every small change costs a disproportionate amount of time and risk. A system from 2015 can already be legacy, while a system from 2003 can comfortably last a few more years if it runs isolated and patched.

Why SMEs put it off (and what that costs)

Every leadership team has the same gut feeling: as long as it runs, there is no crisis. That is true, until it is not. McKinsey calculated that companies pay 10 to 20 per cent extra on top of every IT project purely to work around existing technical debt, and that at one insurer they studied, technical debt cost between 15 and 60 per cent of the IT budget per system. For SMEs, those figures translate into something more tangible: every new request takes three times as long as it should, an outage costs half a day of production, and the supplier who is the only one still familiar with your stack raises their hourly rate every year.

Delay itself also has a cost that never shows up on an invoice. Old systems more often run on unpatched infrastructure, which makes it hard to meet your GDPR duty of care and, if you fall under the new Dutch Cybersecurity Act (Cyberbeveiligingswet), becomes a real problem. Our complete guide to NIS2 for Dutch SMEs shows that demonstrable security policy under NIS2 also covers your old applications.

The six modernisation paths at a glance

The literature usually talks about seven Rs. For SMEs, we narrow it down to six paths that really matter, from least to most effort.

1. Retain: deliberately change nothing

You leave the system in place and accept that as an explicit starting point. That can be perfectly fine if it runs stably, the vendor still exists and the business asks little of it. What matters is that you isolate it: its own network segment, tight firewall rules, backups that work and MFA on every login. Without that hygiene, retain is not a choice but a risk.

2. Retire: pull the plug

Sometimes a system is barely used any more. Export the data, archive what you are legally required to keep (often seven years for tax records in the Netherlands), and take it offline. Every system you remove is one less attack surface.

3. Rehost: move it without changing it

You move the application as-is onto modern infrastructure, usually in the cloud. This is also known as "lift and shift". You get rid of outdated hardware within weeks, but the software itself stays what it was. Useful if you need to leave your data centre, and as a stepping stone towards a later refactoring project.

4. Replatform: light rebuilding

Here you make targeted changes to components. The self-managed SQL Server becomes a managed database, authentication moves to Entra ID. The business logic stays intact. For many SMEs this is the most attractive path: the biggest gains for the least risk.

5. Refactor or rearchitect: rebuild the engine

You keep the purpose of the application, but rebuild parts of it from the inside. A monolith becomes a few clearly defined modules, hard-coded integrations become APIs, and the UI is decoupled from the business logic. This pays off for systems with real business value that too often stand in the way of change.

6. Rebuild or replace: start over or buy a package

Sometimes the system simply no longer fits your business. A home-grown CRM from 2010 becomes a modern SaaS product, a custom stock system is replaced by an industry package. The risk is adoption: the package does things differently, and your processes have to adapt.

How to choose the right path for each system

A modernisation plan for an SME is rarely "rebuild everything" or "replatform everything". It is a portfolio decision. Plot your applications on a simple matrix, with business value on one axis and technical health on the other.

• High value, poor health: refactor or rebuild. This is where you invest.
• High value, reasonable health: replatform. You strengthen a system you want to keep.
• Low value, poor health: retire or replace. Do not spend modernisation budget on it.
• Low value, reasonable health: retain. Isolate it and leave it alone.

You can do this exercise in a single afternoon with the business owner, the person responsible for IT and someone who knows the day-to-day work. The outcome is never a score, but a shortlist of four or five priorities for the coming year.

The Strangler Fig pattern in plain English

In 2004, Martin Fowler came up with an image that still works: your new system grows around the old one like a strangler fig, function by function, until the old one can die off. For SMEs this matters because you can rarely go six months without a business system. In practice it works like this: put a proxy or API gateway in front of your old application, build new functionality behind that gateway on modern infrastructure, and move existing endpoints from old to new bit by bit. Users barely notice, and if a new piece does not work, you simply switch the routing rule back.

This is almost always better than a six-month "big bang" of silence in which everyone hopes the new version will work. A big bang feels brave, but it piles all the risk onto a single day.

What it costs, in realistic ranges

Modernisation is hard to capture in a single figure because scope determines everything. Here are a few rules of thumb we often see in SME projects.

• Rehosting and replatforming a mid-sized business application: a few tens of thousands of euros, spread over a few months. Ongoing cloud costs partly replace the old hardware and licence costs.
• Refactoring projects per module: €15,000 to €80,000 per module depending on size, usually spread over quarters so the business keeps its rhythm.
• Full rebuild or SaaS replacement: rarely under €50,000, often rising to several hundred thousand euros for custom builds with integrations.

Do not just compare these amounts with "doing nothing now", but with the costs you are already quietly paying: maintenance, workarounds, slow releases, risk.

Legacy and the EU Data Act

If you modernise to the cloud, you will have to deal with the EU Data Act. The regulation has applied to cloud services since 12 September 2025. From January 2027, providers may no longer charge you switching or egress fees, and every agreement must include an exit clause with a maximum transition period of 30 days. For your modernisation project, that means: from now on, require portability in new contracts, so no hard dependency on proprietary data formats or on a single specific managed service without an open alternative. Our guide to avoiding vendor lock-in in the cloud explains how to build that into your architecture.

The six steps of a healthy modernisation project

1. Portfolio inventory. A list of all applications with owner, version, host, number of users and status.
2. Value-health matrix. Place each application in a quadrant, together with leadership and end users.
3. A path for each system. Retain, retire, rehost, replatform, refactor or replace, with the reasoning behind it.
4. Sequence and MVP. Which three systems will you tackle in the next six months, and what is the minimum first release?
5. Implement the strangler approach. New functionality behind a gateway, existing endpoints moved one at a time.
6. Capture the learning curve. Every delivery produces knowledge for the next one. Document architecture decisions and test automation.

Also read our guide to drawing up an IT roadmap if you want to fit this project into a broader multi-year plan.

Common pitfalls in SME projects

• Trying to modernise everything at once. Replacing five systems in a year is the classic mistake. Spread the work over quarters.
• No test environment. No modern release should go live without an equivalent test and acceptance environment. Budget 10 to 15 per cent of the project for this infrastructure.
• No data strategy. Agree up front how you will migrate data and who owns which field.
• Swapping the old lock-in for a new one. Ask about export formats, documentation and an exit clause before you sign.
• IT only, no business involvement. Without a lead from the business side, every modernisation stalls after three months. Appoint a product owner from the end-user group.
• Forgetting adoption. A new UI that works better but looks different always feels "worse" in the first few weeks. Train, communicate and keep the painful period short.

What to keep in-house and what to outsource

In practice, three roles are always needed: a product owner from your own organisation, an architect who safeguards the long-term direction, and a team that builds. That team can be largely external, and for SMEs that is often the only realistic route. What matters is that knowledge is documented at the end of every sprint, so you do not become dependent on one senior developer. Our software engineering practice is set up so that knowledge and code stay with the client, with shared repositories and formal handover moments.

Frequently asked questions about legacy modernisation

When is modernisation more urgent than it feels? Four signs mean genuine urgency: no supplier maintains the system any more, the underlying infrastructure no longer receives security updates, you can no longer find developers for the stack, or every small change takes a disproportionate amount of time. In that situation, waiting is no longer a choice but a risk that grows by the day.

Do we have to move to the cloud, or can we stay on-premises? Many SME modernisations move to the cloud because managed services take patching, backups and scalability off your hands. But a stable on-premises environment can work perfectly well for applications with strict latency requirements or specific data classifications. The choice depends on your total management costs, your team and your risk profile. Our guide to choosing between servers and the cloud helps you make a well-founded decision.

How long does a modernisation project take at an SME? For a single application, it typically takes anywhere from a few months to around two years, depending on size and complexity. A rehost can be done in weeks, a replatform in a few months, and a full rebuild often runs from six months to eighteen months. If you split your projects into quarterly releases, you get a regular moment to adjust course.

Does the Strangler pattern also work for very small systems? Yes, and often especially then. A small application can usually be split into a handful of endpoints that you rebuild step by step behind a proxy. Because the scope is small, you can even migrate a few functions per sprint. The idea is universal: better a working improvement every week than one big, uncertain bang six months from now.

Can grants or tax incentives help? Sometimes. Dutch innovation schemes such as the WBSO R&D tax credit can make part of your development hours more tax-efficient. Check in advance whether your project qualifies before you count on any funding.

Conclusion

Legacy modernisation is neither "start all over again" nor "wait just one more year". It is a portfolio decision in which you consciously choose, system by system, between retain, retire, rehost, replatform, refactor or replace, and in which you build new functionality step by step rather than in one big bang. Start with an honest inventory, pick three systems for this year, build behind a gateway and keep your team focused on knowledge transfer.

Stuck on which path suits your business systems, or want to talk through a realistic multi-year plan that will not bring your business to a halt? TRON Group guides SMEs through modernisation projects, from portfolio inventory to delivery. Call us on +31 85 303 5869 for a no-obligation chat, or have your plan reviewed by our software engineering practice.