Quem busca isso já decidiu migrar.
O gatilho costuma ser externo: a hospedagem avisou que vai desligar o PHP 5, a auditoria de segurança apontou a versão, ou o sistema precisa de uma integração que a biblioteca antiga não faz. A tentativa comum é atualizar o PHP no lugar, e ela para no primeiro erro de função removida, no código com consultas montadas por concatenação, nas sessões que dependem do servidor de hoje.
Go entra como destino quando o sistema precisa aguentar volume e ficar previsível: um binário por serviço, concorrência embutida, consumo de máquina que não surpreende. É o que a Stickybit usa desde 2012, quando a linguagem ainda estava na versão 0.90 e reescrevemos a plataforma da Dinamize nela. A plataforma saiu de 600 mil para 23 milhões de e-mails por dia na mesma infraestrutura.
O método é o mesmo de lá: um proxy na frente decide, rota a rota, se o pedido vai para o PHP ou para o Go. As duas versões escrevem no mesmo banco. Cada rota migrada é comparada com a antiga sobre os mesmos dados antes de assumir, e volta por configuração se algo estranho aparece. O sistema nunca para, e o PHP só é desligado quando não recebe mais nenhum pedido.
O que do PHP 5 entrega, o que Go aceita.
PHP 5, a origem
Sistemas internos e portais escritos entre 2004 e 2015 em PHP 5, com ou sem framework da época: CodeIgniter, Zend 1, CakePHP ou código direto. PHP 5.6 não recebe correção de segurança desde o fim de 2018. PHP 5.6 sem suporte desde dezembro de 2018.
- Lógica espalhada entre páginas, includes e SQL montado por concatenação; a regra de negócio e a tela são o mesmo arquivo.
- Banco MySQL ou PostgreSQL em geral sem chave estrangeira declarada: a integridade está no código.
- Sessões, uploads e cron dependem do servidor específico onde o sistema roda hoje.
- Integrações antigas por FTP, arquivo CSV e SOAP, que precisam de equivalente.
- Dados acessíveis direto no banco, o que permite rodar os dois sistemas sobre a mesma base durante a transição.
Go, o destino
Linguagem compilada, com um binário só por serviço, concorrência embutida e consumo de máquina previsível. É o que a Stickybit usa desde 2012 para sistemas que precisam aguentar volume.
- Mesmo banco no começo: os serviços novos em Go leem e escrevem na base atual enquanto o PHP continua no ar.
- Uma rota de cada vez: o proxy na frente envia cada endereço para o sistema novo ou para o velho, e a troca é reversível por configuração.
- Regras reescritas com teste e comparadas com o resultado do sistema antigo sobre os mesmos dados.
- Filas e processamento em lote nativos, para o que hoje roda em cron e script solto.
- Um binário por serviço, com deploy sem dependência do servidor antigo.
Item por item, sem surpresa na virada.
| Item | Migra? | Como |
|---|---|---|
| Regras de negócio | migra | Extraídas do código PHP, dos includes e do SQL, escritas em linguagem clara e reescritas como funções testadas. Cada regra tem origem e teste rastreáveis. |
| Banco de dados | parcial | O mesmo banco durante toda a transição. Chaves estrangeiras e restrições que só existiam no código são declaradas no banco ao final, com relatório de órfãos. |
| Rotas e telas | migra | Cada endereço é migrado como unidade: o proxy envia para o Go quando a rota está pronta e comparada. Telas são refeitas em TypeScript quando o sistema tem interface própria. |
| Sessões e login | migra | Sessão compartilhada entre PHP e Go durante a transição, para que o usuário não perceba qual sistema atendeu. Senhas migram quando o hash é moderno; caso contrário, redefinição no primeiro acesso. |
| Cron e processamento em lote | migra | Scripts agendados viram serviços com fila, reprocessamento e monitoramento. É o que mais ganha com Go. |
| Integrações por FTP, CSV e SOAP | parcial | Refeitas com o mesmo contrato quando o outro lado não muda, ou modernizadas quando o outro lado tem API. |
| Uploads e arquivos | migra | Copiados para armazenamento próprio e servidos pelo sistema novo com os mesmos endereços. |
| Relatórios | migra | Consultas extraídas e versionadas, com saída em tela, PDF e planilha. |
| Código PHP | não migra | Não é traduzido linha a linha. A tradução automática produz Go com a estrutura do PHP e nenhuma das vantagens. |
| Framework da época: CodeIgniter, Zend 1, Cake | não migra | O framework fica para trás. O que ele fazia por baixo, roteamento, sessão, validação, vira biblioteca padrão do Go. |
"Parcial" quer dizer que migra com perda declarada ou com trabalho manual no meio. "Não migra" quer dizer que é recriado no destino ou aposentado, sempre com a sua decisão registrada no inventário.
O prazo é do porte, não da vontade.
| Porte | Prazo | Preço |
|---|---|---|
| Até 10 rotas, um banco, sem lote | 6 a 8 semanas | R$ 45 a 70 mil |
| Cerca de 30 rotas, lote e três integrações (típico) | 4 meses | R$ 120 mil |
| Até 80 rotas, várias integrações, alto volume | 6 a 9 meses | R$ 220 a 380 mil |
| Vários sistemas ou plataforma inteira | por módulo | a partir de R$ 380 mil |
Prazo em semanas corridas a partir do inventário aprovado. O que mais estica é o que depende de terceiros: ERP, gateway, equipamento, e a sua própria revisão do conteúdo.
R$ 120.000, e o que faz subir.
Referência para: Sistema de cerca de 30 rotas, um banco, três integrações, processamento em lote, até 200 usuários. Pago por módulo entregue.
Está dentro
- Auditoria de legado: mapa de rotas, includes, consultas, cron, integrações e dependências do servidor atual.
- Proxy de transição com roteamento por configuração e registro de cada pedido para comparação.
- Reescrita rota a rota em Go, com testes que comparam a resposta nova com a antiga sobre os mesmos dados.
- Serviços de lote com fila, reprocessamento e monitoramento.
- Declaração de restrições no banco ao final, com relatório de registros órfãos.
- Deploy sem dependência do servidor antigo, backup, monitoramento e 90 dias de acompanhamento.
Fica fora
- Servidor ou nuvem, domínio e certificado.
- Interface nova em TypeScript quando o sistema hoje é só API ou só lote. Entra como escopo próprio quando existe tela.
- Funcionalidades que não existem hoje.
- Mudança de banco. O banco fica; se precisar trocar, é o par SQL Server → PostgreSQL ou equivalente.
O que faz o preço subir, em ordem de frequência:
O que dá errado, e o que fazemos antes.
Regra escondida num include de 2008
Um arquivo incluído em meia dúzia de páginas altera um valor em certa condição, e ninguém sabe. Mitigação: a auditoria mapeia cada include por rota e a comparação automática de respostas pega a diferença antes de a rota assumir.
SQL montado por concatenação
Consultas construídas com pedaços de texto mudam de forma conforme a entrada, e a lista de consultas possíveis não está em lugar nenhum. Mitigação: registro das consultas reais em produção por duas semanas, que vira a lista de referência da reescrita.
Sessão que só funciona no servidor de hoje
Sessão em arquivo local, upload em pasta do servidor, cron no crontab de uma máquina. Mitigação: sessão e arquivos vão para armazenamento compartilhado na primeira semana, antes de qualquer rota migrar.
Resposta diferente que ninguém nota
Uma rota migrada que devolve o mesmo resultado em 99% dos casos e erra no 1% passa despercebida por meses. Mitigação: o proxy registra pedido e resposta dos dois sistemas e a comparação roda sobre tráfego real, não só sobre testes.
Duas versões escrevendo a mesma tabela
Durante a transição, PHP e Go escrevem no mesmo banco. Mitigação: cada tabela tem um dono por fase; o sistema que não é dono só lê, e o proxy garante que a rota de escrita está num lado só.
Integração do outro lado que ninguém controla
O parceiro que manda CSV por FTP não vai mudar nada. Mitigação: o contrato antigo é mantido byte a byte na primeira versão, e modernizado só se o outro lado quiser.
Projeto sem fim
Reescritas param quando não entregam nada por meses. Mitigação: primeira rota em produção em quatro semanas, pagamento por módulo, e a cada módulo você decide se continua.
Em paralelo, com volta garantida.
Rotas, includes, consultas reais registradas, cron, integrações, dependências do servidor. Ordem dos módulos decidida pelo risco e pela dor. Preço fechado por módulo.
Proxy na frente registrando tudo, sessão e arquivos em armazenamento compartilhado, ambiente do Go com deploy pronto. Primeira rota migrada e comparada.
Cada rota: regras extraídas, reescrita, comparação sobre tráfego real, troca no proxy. Lote e integrações entram no meio, quando o fluxo de leitura já está estável.
Última rota migrada, proxy sem nenhuma entrada para o PHP por duas semanas, servidor antigo desligado. Restrições declaradas no banco.
Monitoramento, ajuste de capacidade e correções incluídas.
Dinamize: 67 sistemas de PHP e Java para Go, sem parar a plataforma
Migração feitaEntre 2012 e 2017 reescrevemos a plataforma de e-mail marketing da Dinamize em Go, quando a linguagem ainda estava na versão 0.90. Eram 67 sistemas em PHP e Java, com envio, captação, relatórios, integrações e processamento em lote, atendendo milhares de clientes que não podiam parar.
O método foi o desta página: proxy na frente, rota a rota, mesmo banco, comparação sobre tráfego real. No fim, a plataforma enviava 23 milhões de e-mails por dia, contra 600 mil no início, sobre infraestrutura que não cresceu na mesma proporção.
Os rótulos desta seção são três e dizem exatamente o que temos: migração feita, quando já entregamos este par; origem conhecida por dentro, quando construímos ou mantivemos sistemas na tecnologia de origem; destino em produção, quando operamos o destino em escala. Nunca um caso inventado.
O que sempre perguntam.
Por que não atualizar para PHP 8 em vez de ir para Go?
Se o código tem framework mantido, testes e volume moderado, atualizar o PHP pode ser o caminho mais barato. Quando o código é de 2008, sem teste, com SQL concatenado e precisa aguentar volume, a atualização custa quase o mesmo que a reescrita e entrega menos. A auditoria responde com o seu código na mesa.
O sistema para em algum momento?
Não. O proxy manda cada rota para o PHP ou para o Go, os dois escrevem no mesmo banco, e a troca de uma rota é reversível em segundos por configuração.
Precisa trocar o banco?
Não. O banco fica o mesmo durante toda a transição e depois dela. Se houver motivo para trocar, é um projeto separado, feito depois, com o sistema novo já estável.
E se a equipe interna não sabe Go?
Entregamos o sistema com documentação, testes e um período de acompanhamento em que a equipe faz as primeiras alterações com a gente ao lado. Go é uma linguagem pequena; quem programa em PHP costuma ficar produtivo em semanas.
Como sei que a rota nova faz a mesma coisa?
O proxy registra o pedido e a resposta dos dois sistemas sobre tráfego real, e a comparação aponta cada diferença antes de a rota assumir. Diferença que é correção de bug antigo é documentada; diferença que é erro novo é corrigida.
O preço de referência é fechado?
É o preço do sistema típico descrito acima. A auditoria de duas semanas fecha o preço por módulo, com o seu sistema na mesa, e é descontada do projeto se ele seguir.
Comece pelo inventário.
Mande o endereço da loja ou uma descrição do sistema. Em até 24 horas úteis você recebe a confirmação da faixa de preço e prazo para o seu caso, sem compromisso. Se o par for outro, dizemos qual é.