Migrate PHP 5 to PHP 8 or exit an unsupported framework
Your application works, but it is written in a version of PHP or on a framework that no longer receives fixes. Each change brings more concern than the last.
Your application works, but it is written in a version of PHP or on a framework that no longer receives fixes. Each change brings more concern than the last.
Your application works, but it is written in a version of PHP or on a framework that no longer receives fixes. Each change brings more concern than the last. We help you migrate it to a supported version, or decide what to do with it, starting with a diagnosis before changing anything.
To start, simply describe the application. Do not send credentials or database copies.
Request your Proportione Legacy diagnosis
A PHP application is not a block. It has the language and its extensions, the third-party libraries it uses, the framework (if any), and the code written by its team. Each piece has its own support schedule and its own way of changing.
That's why the first job is an inventory: what version is running, what dependencies it has, what the code really does, and who knows it. With that in front of you, you choose the path. Without it, any budget is a guess.
What it means for you: knows what their application is composed of before deciding what to do with it. Next step: request the diagnosis.
The PHP project only supports recent branches. When each one ends is published by the project itself on its page of supported versions and on the page of unsupported branches. According to php.net, on October 11, 2026:
| Branch | Active support until | Security fixes until | |---|---|---| | PHP 8.2 | Dec 31, 2024 | Dec 31, 2026 | | PHP 8.3 | Dec 31, 2025 | Dec 31, 2027 | | PHP 8.4 | Dec 31, 2026 | Dec 31, 2028 | | PHP 8.5 | Dec 31, 2027 | Dec 31, 2029 |
Branch 5.6, the last of the 5 series, ended its life on December 31, 2018, according to the same page. Branches 7.4, 8.0, and 8.1 ended on November 28, 2022, November 26, 2023, and December 31, 2025, respectively.
Moving from PHP 5 to a branch of the 8 series is a big leap. The official documentation describes the transition between each pair of versions, from 5.6 to 7.0, from 7.0 to 7.1, and so on up to 8.0 (migration guide to PHP 7.0, migration guide to PHP 8.0). Each step has its own breaking changes.
A concrete example from the official documentation: the `mysql_*` extension, with which many old applications were written, became obsolete in PHP 5.5.0 and was removed in PHP 7.0.0 (PHP manual). An application that uses it will not start on a current version until that layer is rewritten with `mysqli` or `PDO`.
Our approach is the same as in any other system: inventory of what exists, version path chosen with data, a limited pilot when the case requires it, phased delivery with acceptance criteria, and a rollback plan. The destination is chosen with the php.net calendar in front of us, not with the closest branch.
What it means for you: a written path, with each step verifiable, instead of a blind update. Next step: request the diagnosis and indicate the PHP version, if known.
“Out of maintenance” can mean three different things, and each has a path.
Each project publishes its version calendar. This is the case for Symfony and for Laravel: a major version has a correction period and then stops receiving them. These pages also indicate which PHP version each branch requires. For example, Symfony 7.4 requires PHP 8.2 or higher, according to its own version page. Upgrading the framework and upgrading PHP are, in practice, the same conversation.
A custom framework has no community, no public documentation, and no calendar. All knowledge resides with a few people, and they may no longer be around.
There is no official guide to follow here, which is why the work begins by understanding what it does: what modules it has, which ones are used, which ones can be retired, and which ones must be kept. Then there are three options:
There are old applications that are PHP files mixing queries, logic, and presentation. There is no framework to update, but there is also no structure to rely on. The inventory decides which parts are ordered, which are kept as they are, and which are replaced.
If what is unsupported is a content management system (Drupal 7, for example) or a Moodle platform, the case is different and has its own page: Migrating a content management system like Drupal 7 or update Moodle from an old version. And if the application is not in PHP but in Visual Basic 6, FoxPro, Delphi or COBOL, the method is the same and the page is different.
What it means for you: know which of the three cases you are in and what options you have. Next step: indicate in your message if the framework is known or in-house, and who maintains it today.
It is not an emergency that needs to be resolved this week. It is a situation that worsens slowly, and therefore it is advisable to decide it with a calendar instead of waiting for a failure to decide it.
Technically, continuing as is has four consequences:
None of this means the application will stop working tomorrow. It means the room for choice is narrowing.
What it means for you: the risk is understood and contained before deciding, without drama. Next step: the diagnosis, which is described below.
We start with a diagnosis of your data and processes before choosing a destination. It delivers an inventory of processes and data, the options (build, buy, or connect), and a phased scope proposal. General details are in how we work.
What it means for you: at all times you know what has been delivered, what is missing, and how to roll back. Next step: request the diagnosis.
Before adding AI, the process must be understood and the data organized. The business rules of an old application live in its code, and they must be understood before moving them.
Sometimes the result of the diagnosis is to open it with APIs and connectors to link it with the rest, without replacing it. We consider AI afterwards, when the process is understood. AI can run on its own server and, if necessary, without an internet connection. This is the option we describe in legacy systems migration service.
What it means for you: your data does not have to leave your premises. Next step: see how AI fits into your company at artificial intelligence in business. If you want to see the whole picture, consult our services and the Business Management Consulting.
The official documentation describes the transition between each pair of versions, from 5.6 to 7.0 and so on up to 8.0. Which route is best for your application depends on its code and dependencies, and is decided during the diagnosis, not in advance.
They need to be located and replaced. The official documentation lists the functions and extensions removed in each version; the diagnostic inventory crosses that list with the actual calls in your code, to know how many there are before committing to the scope.
It depends on what the inventory does. Sometimes it's enough to update the language and libraries. Other times it's worth migrating the code to a current framework in parts, or rewriting a part. The diagnosis compares the options (build, buy, or connect) with your application data.
It depends on the scope: how many dependencies there are, how much custom code, and how many tests exist. That's why we don't give a figure or a deadline without knowing your case. The diagnosis ends with a phased scope proposal, and from there, it is specified.
We agree with you on each phase, including what it implies for the service, and each phase has a rollback plan. We don't promise there won't be any downtime: what is fixed in advance is what is delivered and with what acceptance criteria.
The code belongs to the client, and this is explicitly stated in the contract. Documentation, exportability, and custody are verifiable and form part of the design.
Tell us what application you have, what PHP version it's on, and what concerns you. We'll respond within two business days. [Short form: see specification in notes] If you prefer to write to us directly: contact.
Request your Proportione Legacy diagnosisDo not send credentials or databases. We will use your data only to respond to you; more information in the Privacy Policy.
