Make or buy
Modernise or rebuild a legacy PHP application? How to decide
By Dominik Natter · Last updated on 3 November 2026 · 8 min read
In short
If the code is maintainable and the application still fits the way you work, an update to a supported PHP version is usually enough. If it has grown over the years, has no tests and depends on one person, replacing it area by area is usually safer than a complete rebuild. If standard software covers around 80% of your process, replace the application. The decision is urgent because PHP 8.2 loses security support on 31 December 2026, and PHP 8.1 and older no longer receive regular updates.
How to tell that your PHP application has become a risk
A PHP application becomes a risk as soon as it runs on a version without security updates, or when nobody can change it safely any more. Both apply to many in-house builds from the 2000s and 2010s: intranets, ordering systems, customer databases and order management tools.
PHP 8.2 receives security updates only until 31 December 2026, and the critical security update of 21 October 2026 showed what happens after that. PHP 8.1 and older no longer received regular updates. The PHP project only published minimal patches that you have to apply yourself. Read more in our guide "PHP 8.2 end of life: what SMEs need to do by the end of 2026".
- Starting point for the assessment as a fixed-price study, up to CHF 9,000
- CHF 4,000
- Starting point for step-by-step modernisation in stages, up to CHF 150,000
- CHF 40,000
- Coverage by standard software at which replacing is usually the best choice
- Around 80%
- of project costs per year for maintenance and operation
- 15 to 20%
For applications that hold personal data, this is also a data protection issue, because Article 8 of the Swiss Federal Act on Data Protection and, for Liechtenstein, Article 32 of the GDPR require appropriate data security measures.
Check whether any of these points apply to your application:
- It runs on PHP 8.2 or older. Your hosting provider or IT partner can tell you the version quickly.
- The person or agency that built it is no longer available.
- There are no automated tests and no documentation. Every change becomes an experiment.
- It is built on a home-grown or outdated framework that nobody updates any more.
- A PHP update fails because parts of the code no longer run on newer versions.
- Your team keeps Excel lists alongside it because it no longer reflects how you work today.
- Data is copied into the ERP or the accounting system by hand.
Four options compared: update, modernise, replace or rebuild
There are four realistic options. Which one fits depends on the state of the code, how important the application is to your business and whether your process still works the way it should.
The application is moved to a supported PHP version, outdated libraries are replaced and known vulnerabilities are closed.
This is the cheapest option if the code is reasonably clean and the application still fits your process. The legacy baggage remains, but the immediate risk is resolved.
- Suitable if the code is maintainable and the process still fits.
- Effort: billed by the hour, CHF 150 to 250 per hour.
- Risk: low, legacy baggage remains.
The old application keeps running while one area after another is replaced by new software.
This suits business-critical applications that have grown over the years and that your operations depend on. The next section explains how it works.
- Suitable for grown, business-critical applications.
- Effort: CHF 40,000 to 150,000 in stages.
- Risk: low per stage, two systems for a while.
Many in-house builds exist because nothing suitable was available at the time. Today there are mature products for many processes, such as ERP modules or industry solutions.
If a standard product covers around 80% of your process and the rest is not a competitive advantage, this is usually the best choice. Our guide "Standard or custom software: how to decide" shows how to assess this properly.
- Suitable if a standard product covers around 80%.
- Effort: licence, rollout, CHF 3,000 to 15,000 per integration.
- Risk: medium, the process adapts to the product.
The application is developed again from scratch. This pays off if the code cannot be saved and your process is changing significantly anyway.
It is the option with the most effort. The risk is high if everything is switched over on a single date.
- Suitable if the code cannot be saved and the process is changing significantly.
- Effort: CHF 25,000 to 100,000, larger platforms above that.
- Risk: high with a single switchover date.
Modernising step by step: the strangler principle in plain terms
With the strangler principle, the old application is not replaced in one go but piece by piece. The name comes from the strangler fig, a plant that grows around a tree and eventually replaces it. Software developer Martin Fowler coined the image for software modernisation in the early 2000s.
In an SME it looks like this: an ordering system from 2012 covers customer login, order entry, stock lists and reports.
01
Biggest pain first
The area causing the most pain is rebuilt first, for example order entry.
02
Customers order in the new app
From then on, your customers order in the new application while everything else keeps running in the old system.
03
Shared data
Both work with the same data through an interface.
04
Remaining areas follow
The remaining areas follow one by one.
05
Switch off the old system
In the end the old application is empty and is switched off.
The advantage: each stage is manageable, useful early on and can be rolled back if problems arise. The drawback: for a while you run two systems, and the connection between them takes effort. The principle only works if you see the replacement through to the end. Otherwise you will run old and new side by side indefinitely.
Rebuilding: stay with PHP or switch technology?
PHP itself is not the problem. Current versions are actively maintained and well suited to business applications. The problem with old applications is usually the code, not the language.
We build with C# and .NET, Next.js and PostgreSQL. A rebuild by us therefore means a change of technology. If your code is in usable shape and a partner maintains it reliably, switching is not a goal in itself, and we will tell you so. Switching has advantages and drawbacks you should know about.
Drawbacks of switching
- Whoever maintains your PHP application today cannot simply take over the new solution.
- During a step-by-step replacement, two technologies have to work together for a while. The connection has to be built properly.
- If the old application runs on MySQL or MariaDB, a database switch is added. This makes the data migration somewhat more complex.
Advantages of switching
- The new application is built on a consistent, widely used foundation. Another team can take it over later.
- Typed languages such as C# and TypeScript reveal many errors during development rather than in production.
- Old code is not carried over out of habit. The process is rethought.
Checklist: modernise, replace or rebuild?
Answer these questions before you decide. They usually show quickly which option is worth considering.
- Does the application still fit the way you work today? If so, an update or step-by-step modernisation is a strong candidate.
- Can the code be moved to a current PHP version with reasonable effort? A technical review will tell.
- Is there standard software that covers around 80% of the process? Then assess that option first.
- Would one day of downtime cost you revenue or customers? Then a step-by-step approach is safer than a single switchover date.
- How many systems depend on the application, such as ERP, online shop or accounting? Every integration has to be rebuilt when it is replaced.
- How good is your data? Duplicates and free-text fields make any replacement more expensive.
- Who will look after the solution in five years? Without an answer, every option is risky.
- Does the application run on PHP 8.1 or older? Then securing it is urgent, whatever the long-term plan.
Common mistakes when replacing legacy software
These mistakes make replacement projects expensive or cause them to fail. All of them can be avoided.
- Big-bang rebuild: everything is rebuilt and switched over on a single date. Months pass without any benefit, and on the day all the gaps appear at once.
- Copying features one to one: the old application contains detours and features nobody needs any more. Copying them means paying for legacy baggage. Rethink the process first, then build.
- Underestimating data migration: after many years in operation there are duplicates, empty mandatory fields and special cases. Cleansing and trial runs take time and belong in the budget.
- Overlooking hidden rules: the code contains pricing rules or special cases that are documented nowhere. They are only noticed once they are missing.
- Forgetting the old application: as long as it is online it has to stay secured, even while its replacement is being built.
- Nobody decides: without a responsible person in the business who sets priorities, the project drags on.
When a rebuild does not pay off
A rebuild is not always the right answer. Do without it if any of these points apply:
- The code can be moved to a current PHP version with manageable effort, and the application does its job.
- The application is rarely used and is not business-critical. Securing it is enough, or you switch it off.
- A standard product covers most of your process, and the rest is not a competitive advantage.
- Your process is changing fundamentally right now, for example because of an ERP rollout. Wait until the target picture is clear and secure the old application until then.
- Nobody in the business has time to take part in workshops, testing and acceptance.
What software modernisation costs and how the assessment works
The costs depend on the option you choose. The following figures are guide values excluding VAT, derived from our price ranges.
Cost ranges by option
| Option | Price range | Note |
|---|---|---|
| Update to a current PHP version | CHF 150 to 250 per hour | billed by effort at Swiss providers' hourly rates, the number of hours only becomes clear once the code has been reviewed |
| Step-by-step modernisation | CHF 40,000 to 150,000 | in total, spread over several stages |
| Single stage as an automation | CHF 8,000 to 25,000 | depending on scope |
| Single stage as an internal tool | CHF 25,000 to 50,000 | depending on scope |
| Replacement with standard software | CHF 3,000 to 15,000 per integration | plus licences, rollout and data migration |
| Rebuild | CHF 25,000 to 100,000 | internal tool CHF 25,000 to 50,000, business application connected to your ERP CHF 50,000 to 100,000, larger platforms above that |
| Assessment as a preliminary study | CHF 4,000 to 9,000 | fixed price, 2 to 3 weeks, before any of these decisions |
| Maintenance and operation per year | 15 to 20% | of project costs |
Step-by-step modernisation is comparable to replacing a grown Excel or FileMaker solution. Read more in our guide "Replacing Excel: when does a custom solution pay off?".
For maintaining and operating the new solution, we offer a maintenance contract including hosting in the EEA, typically at 15 to 20% of the project costs per year. Read more in our guide "Software maintenance costs: what do maintenance and operations cost per year?".
A price only becomes binding after an assessment. With us this is a fixed-price preliminary study of CHF 4,000 to 9,000 that takes two to three weeks. Afterwards you decide freely whether and with whom to go ahead. The assessment works like this:
01
Technical inventory
Servers, PHP version, framework, database, interfaces and security status.
02
Code review
How understandable is it, where are the business rules, what can be reused?
03
Interviews with users
What is needed every day, what is never used, and where do people work around the application?
04
Data analysis
Volume, quality and dependencies of the data.
05
Result
A recommendation for one of the four options, immediate security measures, a stage plan and a cost ceiling.
Where this information comes from
PHP versions and security update
The PHP versions and support deadlines come from php.net, from the "Supported Versions" and "Unsupported Branches" overviews. The details of the update of 21 October 2026 come from the PHP project's security advisory of the same day on vulnerabilities CVE-2026-109618 and CVE-2026-109619.
Data security
The data security obligation arises in Switzerland from Article 8 of the Federal Act on Data Protection and in Liechtenstein from Article 32 of the GDPR. This guide is not legal advice.
Strangler principle
Martin Fowler describes the strangler principle in his article "Strangler Fig Application".
Cost ranges
The cost ranges are guide values excluding VAT and match the price ranges on our service and solution pages. They do not replace a preliminary study.
As of: November 2026.
| Update and keep running | Suitable if the code is maintainable and the process still fits | Effort: billed by the hour, CHF 150 to 250 per hour. Risk: low, legacy baggage remains. |
|---|---|---|
| Modernise step by step | Suitable for grown, business-critical applications | Effort: CHF 40,000 to 150,000 in stages. Risk: low per stage, two systems for a while. |
| Replace with standard software | Suitable if a standard product covers around 80% | Effort: licence, rollout, CHF 3,000 to 15,000 per integration. Risk: medium, the process adapts to the product. |
| Rebuild | Suitable if the code cannot be saved and the process is changing significantly | Effort: CHF 25,000 to 100,000, larger platforms above that. Risk: high with a single switchover date. |
| Assessment as a preliminary study | CHF 4,000 to 9,000 | Fixed price, 2 to 3 weeks, before any of these decisions |
| Maintenance and operation per year | 15 to 20% | of project costs |
Frequently asked questions
How long can we keep running an old PHP application securely?
Only as long as its PHP version receives security updates and someone can still change the code safely. PHP 8.2 receives no security updates from 1 January 2027, and PHP 8.1 and older already received no regular updates for the critical vulnerabilities of October 2026. Depending on the state of the application, the next step is to update it, modernise it step by step or replace it.
Is it worth simply updating an old PHP application?
Yes, if the code is maintainable and the application still fits the way you work. In that case an update is the cheapest option and removes the immediate security risk. If the code has no tests, no documentation and depends on one person, an update only postpones the problem. A short code review shows which case applies.
Do we have to move away from PHP when we rebuild?
No. Current PHP versions are a well-maintained basis for business applications. We build with .NET, Next.js and PostgreSQL, so a rebuild by us means switching technology. That makes most sense when you are rebuilding anyway. If your code is in good shape and a partner maintains it reliably, switching is not a goal in itself.
Can you take over existing software and develop it further?
Yes, after a short review. We look at the code, the data model and how it is operated, and tell you candidly whether further development makes sense or a gradual replacement would cost less. The review takes a few days and is charged at a fixed price.
Can we switch over gradually?
Yes, and we recommend it. The area causing the most pain is replaced first, while the old solution carries on for the rest. The benefit shows early and the risk per step stays small.
Matching services:Custom softwareIntegrations
Let us talk about your case.
20 minutes are enough to find out whether a custom solution is worth it for you.