Proportione Legacy

Aplicações em PHP e frameworks sem suporte

A aplicação da sua empresa funciona, mas está escrita numa versão de PHP, ou sobre uma framework, que já não recebe correções. Cada alteração dá mais respeito do que a anterior. Ajudamos a levá-la para uma versão com suporte, ou a decidir o que fazer com ela, começando por um diagnóstico antes de mudar o que quer que seja.

Pedir um diagnóstico de transição

Para começar, basta indicar a versão de PHP, se a souber, e o que a aplicação faz. Não envie credenciais nem bases de dados.

Em poucas palavras

«Sem suporte» quer dizer que o projeto deixou de publicar correções para essa versão, incluindo de segurança.
Uma aplicação PHP tem várias peças: linguagem, bibliotecas, framework e código próprio. Cada uma tem o seu calendário.
Nem sempre é preciso reescrever. O diagnóstico diz o que se atualiza, o que se reescreve e o que se substitui.
Avança-se por fases, com critérios de aceitação e plano de reversão.

O que significa «sem suporte»

Cada versão de PHP tem um período em que recebe correções. Passado esse período, o projeto deixa de publicar atualizações para ela, incluindo as de segurança. A aplicação continua a funcionar. Deixa de receber correções.

As datas publica-as o próprio projeto PHP, em versões suportadas e em versões sem suporte. Segundo php.net, a 14 de outubro de 2026:

Versão	Fim do suporte de segurança
PHP 5.6	31 de dezembro de 2018
PHP 7.0	10 de janeiro de 2019
PHP 7.4	28 de novembro de 2022
PHP 8.0	26 de novembro de 2023
PHP 8.1	31 de dezembro de 2025
PHP 8.2	31 de dezembro de 2026
PHP 8.3	31 de dezembro de 2027

Confirme sempre a sua versão na página do projeto. A tabela pode mudar.

O que significa para a sua empresa: a data do fabricante diz quando decidir, não o que decidir. Passo seguinte: indicar-nos a versão que tem.

Uma aplicação PHP resolve-se por peças

Uma aplicação PHP não é um bloco. Tem:

a linguagem e as suas extensões;
as bibliotecas de terceiros;
a framework, se existir;
o código que a sua equipa ou um fornecedor escreveu.

O diagnóstico inventaria cada peça e o que dela depende. Só depois se escolhe o destino.

Diagnóstico do que a aplicação faz hoje

Partimos da aplicação em funcionamento, dos seus dados e do seu comportamento. Não é preciso ter a documentação nem o programador original. A autorização do titular é sempre condição.

Entrega um inventário do que a aplicação faz, as opções (construir, comprar ou ligar) e uma proposta de âmbito por fases.

Opções: atualizar, reescrever ou substituir

Atualizar a versão de PHP e as bibliotecas, quando o código o permite. O salto entre versões antigas e recentes é longo, e a documentação oficial descreve cada passo.
Reescrever a parte que depende de uma framework sem manutenção, quando compensa.
Substituir por um produto de mercado, quando o processo é comum.
Isolar e ligar a aplicação ao resto, quando só precisa de partilhar dados. Veja integrar software antigo.

O que significa para a sua empresa: uma rota escrita, com cada passo verificável, em vez de uma atualização às cegas. Passo seguinte: pedir o diagnóstico.

Exemplo hipotético: a aplicação que ninguém quer atualizar

Imagine uma empresa industrial de média dimensão, no centro ou norte do país. Uma aplicação web interna gere pedidos e prazos. Foi escrita por um fornecedor externo, há muitos anos, numa versão de PHP que já não recebe correções. O servidor onde corre também é antigo. Quando alguém propõe atualizar, a resposta é sempre a mesma: «e se deixa de funcionar?».

Esta cena é inventada para ilustrar. Não descreve nenhuma empresa concreta.

Num caso assim, o diagnóstico não começa por alterar código. Começa por listar o que a aplicação faz e por definir como se verifica que continua a fazê-lo. Só com essa verificação a atualização deixa de ser um salto no escuro.

O que recebe e como se avança

Um diagnóstico dos seus dados e processos, com inventário e opções.
Uma proposta de âmbito por fases, com critérios de aceitação em cada uma.
Um piloto delimitado, quando o caso o pede, com critérios de aceitação fixados à partida.
Entrega por fases, com critérios de aceitação e plano de reversão.
Documentação, exportação e custódia dos dados, verificáveis.

O preço e o calendário acordam-se depois de delimitar o sistema.

Pedir um diagnóstico de transição

Perguntas frequentes

Estou em PHP antigo. É urgente?

Depende do que a aplicação faz e do que a rodeia. A data de fim de suporte é a do projeto PHP e está na sua página. O diagnóstico serve para decidir com essa data à frente.

Posso atualizar sem reescrever?

Por vezes sim. Depende do código e das bibliotecas que usa. O diagnóstico indica o que se atualiza e o que não pode ser atualizado.

Quem tem de dar autorização?

O titular do sistema. Sem a sua autorização, não analisamos nem alteramos a aplicação.

E a segurança?

Sem suporte significa que a versão deixou de receber correções, incluindo as de segurança. Não prometemos um resultado concreto de segurança; o diagnóstico indica o que a versão em uso implica.

É possível migrar sem o programador original e sem documentação?

É possível migrar um sistema sem depender de quem o programou nem da sua documentação. Parte-se do sistema em funcionamento, dos seus dados e do seu comportamento, com autorização do titular. É um método e uma possibilidade, não uma garantia para qualquer caso.

Páginas relacionadas

Fale connosco

Indique a versão de PHP, se a souber, e o que a aplicação faz. Para começar, chega isso.

Pedir um diagnóstico de transição