Home / Legacy software modernisation

Software modernisation

Legacy software modernisation without stopping the business

Modernise legacy software in steps: pin its current behaviour down with tests first, then replace it module by module while the old system keeps running. A full rebuild pays off only when the rules in the code are wrong.

Most organisations run on a few systems nobody likes to touch: an Access database carrying the planning, a .NET Framework order application, a PHP portal from 2016. This page is for the IT manager or CIO who decides what happens to them and must keep the result supported.

By Tom Joseph · Last updated: 29 October 2026

Free consultation Pricing

In short

There are four routes: upgrade the code to a supported version (refactor), replace the system module by module behind a routing layer (the strangler fig pattern), rebuild it, or move to a standard package. Three questions decide which one fits: are the business rules in the code still right, can today's behaviour be captured in tests, and can requests to the old system be intercepted? Whichever route you take: no big bang, tests first, and an agreed split of work with whoever runs your servers.

Why now

Which platforms are losing support

Platform	End of support	What it means
PHP 8.1 and older	Already ended	No security fixes from the PHP project. php.net lists only 8.2 to 8.5 as supported.
PHP 8.2	31 December 2026	Security fixes stop at the end of this year; PHP 8.3 is covered until 31 December 2027.
.NET Framework 4.6.2	12 January 2027	Versions 4.5.2, 4.6 and 4.6.1 already retired on 26 April 2022 (Microsoft Lifecycle).
.NET 8 and .NET 9	10 November 2026	The current long-term release, .NET 10, is supported until 14 November 2028 (.NET support policy).
Access 2016 and Access 2019	14 October 2025	No new security updates (Microsoft, end of support 2025).

The decision

Refactor, replace in steps, rebuild or buy a package

Route	Choose it when	Where the risk sits
Refactor and upgrade	The business rules are still right and the problem is mainly the runtime or framework, such as PHP 7.4 or .NET Framework.	Behaviour nobody wrote down that changes quietly during the upgrade.
Replace in steps (strangler fig)	The system is large, must keep running for years, and requests can be routed through a layer in front of it.	Two systems sharing the same data for a while.
Rebuild	The rules in the code are no longer right, the system is small, or the code cannot be tested.	Old rules that turn out to be missing only after go-live.
Standard package	The process does not set you apart and a package already does it well.	Custom logic that returns as configuration nobody oversees.
Retire	Hardly anyone still uses it.	A forgotten integration or report that still depends on it.

Step by step

How the strangler fig pattern spreads the risk

Microsoft describes the Strangler Fig pattern like this: a façade receives every request and routes it to either the legacy system or the new one. Functionality moves across piece by piece, users keep the same entry point, and the old system is switched off once nothing depends on it.

In practice you start with one module that has a clear boundary and a visible benefit, such as order entry or reporting. It goes live next to the rest, proves itself in use, and only then does the next one follow. Each step can be undone by pointing the façade back.

Microsoft also says when the pattern does not fit: when requests to the old system cannot be intercepted, when you cannot change its source code or database, or when the system is small enough that replacing it in one go is simpler.

AI, used safely

AI-assisted migration starts with tests, not code

AI tools now handle most of the mechanical work. Microsoft's GitHub Copilot upgrade agent moves .NET Framework projects of any version to .NET 8 or later, has a scenario for ASP.NET Web Forms to Blazor, and makes a Git commit for every portion of the work so each change can be rolled back. For PHP, Rector applies upgrade rules from PHP 5.3 up to 8.5.

The risk sits in behaviour that is written down nowhere, so we start with characterisation tests: tests that record what the system does today, including the quirks users rely on. AI drafts them, an engineer checks them against real cases, and from then on no change merges unless the tests stay green and an engineer has read it. Our PHP2Shell analysis shows what breaks in practice.

Continuity

Keeping the business running during the migration

No big bang. Each module goes live on its own, with the old path still available to fall back on.
Run in parallel where it counts. For prices, planning or invoices, old and new run side by side and we compare the outcomes.
Through your change process. Changes go through your DTAP street and your change advisory board, not around them.
Integrations mapped first. AFAS, Exact, SAP, a WMS or TOPdesk: every integration gets an owner and a test before anything switches. See API integrations.
Go-live outside the peak. A wholesaler does not switch before the holidays, nor an accountancy firm in tax season.

Data

Data migration sets the timeline

Code converts quickly with today's tooling; data does not. An Access database or an old SQL Server environment holds duplicate customers, fields whose meaning drifted over the years, and rules that live only in a query written by a colleague who left.

We work in four steps. An inventory: which tables, who writes to them, which reports and integrations depend on them. Then the mapping from old to new, with a cleaning decision per field. Then trial migrations on a copy, repeated until the reconciliation holds: counts, totals and samples per table, signed off by someone from the business. Only then the final transfer, in an agreed freeze window.

When you replace in steps, old and new use the same data for a while. Microsoft notes that both systems must then reach that data at the same time; we settle that design before the first module goes live.

Who does what

Your ICT partner, your IT organisation and us

Phase	Crux Digits	Your ICT partner	Your organisation
Analysis	Code audit, test coverage, migration plan per application	Access to the code and servers, an overview of environments, runtime and server versions	An owner per application, priorities and the budget
Build	Refactoring, new modules, characterisation tests, data migration scripts	Test and acceptance environments that match production	Acceptance tests, decisions on disputed business rules
Change and release	A change request with impact and rollback plan	A slot in the change calendar	Approval by the change advisory board
Go-live	Release package, runbook, support during cutover	Deployment, servers, backups, monitoring	Sign-off for go-live
After go-live	Handover of code, tests and knowledge	Hosting, patching, operations	Application ownership
Hosting, patching, helpdesk	Not us: we do not offer these	Yes	Contract management

Ownership

Your code, your tests, no new dependency

Many legacy problems are ownership problems: the source sits with a supplier, the only developer has left, or nobody knows which version runs in production.

With us the code lives in your own repository from day one. You receive the test suite that proves the behaviour, the data migration scripts, a runbook your ICT partner can use to deploy and restore the application, and a record of the architecture decisions. No proprietary framework or platform licence of ours sits underneath, so another supplier or your own team can carry on without us.

Ask every supplier, us included: which repository holds the code, who has the rights, and can a third party build and deploy it from the handover alone?

Cost and timeline

Three fixed steps, per application

Audit and strategy, €2,500, one to two weeks: code, dependencies, test coverage and data reviewed, with advice per application (refactor, replace in steps, rebuild or retire) and a fixed price for the next step. If a standard package is the better choice, the advice says so. Production-ready MVP, €20,000, four to six weeks: the first module, or the upgrade of one bounded application, with characterisation tests, working on your own data. Production, from €50,000, eight to twelve weeks: the full migration, integrated, tested and handed over with all source code. Prices exclude VAT, and the audit is credited against the MVP if you continue within 60 days. One named engineer is your contact from start to finish.

All prices are on our pricing page, and how we build is on custom software development.

Examples

What this looks like by sector (examples)

Example, wholesale: an Access database with the item master and price agreements, linked to Exact Online through CSV exports. Route: data into a proper database, a web application in front of it, the integration through the API instead of files.
Example, logistics: an ASP.NET Web Forms application on .NET Framework 4.6.2 that produces packing slips and CMR documents next to the WMS. Route: upgrade to .NET 10, with tests on the document output written first.
Example, construction and installation: a PHP 7.4 portal where engineers close their work orders. Route: Rector to PHP 8.4, the framework upgraded along with it, characterisation tests on the work-order flow.
Example, manufacturing: a Delphi planning tool on SQL Server next to the ERP. Route: replace in steps, starting with the planning view, while the old tool keeps doing the calculation until the new one is proven.

FAQ

Frequently asked questions

What is legacy software?

Legacy software is software your organisation still needs but that has become hard to maintain: the runtime gets no security updates, the framework is outdated, or nobody knows the code any more. Age alone says little: a twenty-year-old system with tests can be healthier than a five-year-old application nobody dares to touch.

When is replacing better than modernising?

Replacing is better when the business rules in the code are no longer right, when a standard package supports the process just as well, or when the system is small enough to rebuild faster than to test. If the rules are still right and the problem is mainly the technology, modernising keeps the value that sits in the code. The audit gives reasoned advice per application.

What does legacy software modernisation cost?

At Crux Digits the audit costs €2,500, a Production-ready MVP €20,000 and a full production migration from €50,000, excluding VAT. The audit takes one to two weeks, the MVP four to six weeks and production eight to twelve weeks. The audit is credited against the MVP within 60 days. The final cost depends mostly on test coverage, data quality and integrations.

Can AI convert old code automatically?

Yes, for the mechanical part: AI tools and rule-based tools such as Rector and the GitHub Copilot upgrade agent convert most outdated code. What they do not decide is whether the result behaves the same. That is why characterisation tests come first, and why an engineer reads every change before it is merged into the codebase.

How do you migrate data without downtime?

By running trial migrations on a copy until the reconciliation holds and doing the final transfer in a short, agreed freeze window. When you replace in steps, data moves per module. The old system stays available as a fallback until the business has accepted the new module.

Does our ICT partner need to be involved?

Yes: your ICT partner keeps running the servers, deployments, backups and operations, while we work on the application. They give us a test environment; we give them a release package and a runbook. Crux Digits does not host or run a helpdesk; we work alongside your ICT partner, not instead of them.

Which application is first on your list?

Send us the application's name, its runtime version and who runs it. We tell you which route fits and what the audit would deliver.

Book a free consultation →