Classic ASP e PHP precisam do mesmo plano de migração?

Classic ASP e um monólito PHP podem gerar páginas parecidas, consultar o mesmo banco de dados e irritar a mesma equipe de engenharia. Isso não os torna a mesma migração. Classic ASP geralmente entra na pauta porque a pilha de Windows e IIS por baixo dele ficou difícil de hospedar, corrigir, manter com pessoal capacitado ou mover. Um monólito PHP pode rodar em uma pilha suportada e continuar caro de alterar, pois suas fronteiras existem apenas na cabeça dos desenvolvedores.

Tratar os dois como aplicações web legadas genéricas gera um plano genérico: inventariar páginas, escolher um framework, converter código, testar e fazer a virada. Essa sequência esconde o risco que decide cada projeto. Com Classic ASP, a primeira obrigação é reproduzir um ambiente de execução em desaparecimento e suas dependências não documentadas antes que o host atual suma. Com PHP, é decidir quais separações arquitetônicas devem existir, pois uma reescrita linha por linha pode preservar todos os motivos que tornam o monólito penoso.

A distinção muda o que você inspeciona, congela, redesenha e aceita como evidência. Também explica por que um pacote único de migração a preço fixo raramente serve para os dois sistemas, mesmo quando a contagem de linhas parece próxima.

Classic ASP traz um prazo de plataforma

Uma migração de Classic ASP começa pelo host, porque a aplicação é em parte uma configuração do IIS acompanhada de arquivos-fonte. Páginas ASP dependem dos mecanismos de script do Windows, registro COM, metabase do IIS ou applicationHost.config, compatibilidade de 32 bits, fontes ODBC, permissões de arquivo, localidade e, muitas vezes, uma configuração de SMTP ou tarefa agendada que nunca entrou no controle de versão. Copiar os arquivos .asp entrega apenas a camada visível.

A documentação do IIS da Microsoft descreve Classic ASP como um recurso opcional do servidor web, desativado até um administrador instalá-lo. O detalhe parece comum, mas captura o risco: o runtime é uma função do sistema operacional com estado da máquina, não uma dependência restaurada de um manifesto do projeto. A mesma documentação menciona mudanças de segurança, como caminhos pais desativados em configurações recentes do IIS. Concordo com os padrões mais seguros, mas a equipe deve registrar o comportamento antigo antes de mudá-lo ou confundirá uma diferença de plataforma com defeito da aplicação.

O prazo raramente é uma única data de fim de suporte. É o ponto acumulado em que a organização já não consegue reconstruir o servidor com confiança. Uma máquina limpa pode ser configurada com instruções registradas? Os instaladores COM ainda existem? Alguém sabe qual identidade é dona do diretório de uploads? O driver de banco é suportado na versão pretendida do Windows? Se as respostas são fracas, o prazo de hospedagem já existe, mesmo que a máquina atual ainda responda.

Por isso, a avaliação de Classic ASP começa com uma reconstrução. Registre configurações de site e aplicação do IIS, funções instaladas, mapeamentos de manipuladores, propriedades do pool, identificadores de classe COM, DSNs, certificados, tarefas agendadas, serviços do Windows, entradas de registro usadas pela aplicação e ACLs de cada diretório gravável. A unidade útil do inventário é uma dependência executável, não uma página.

Execute o exercício com as identidades realmente usadas pela aplicação. Um administrador testando de forma interativa pode ler o registro, instanciar um componente e gravar em um compartilhamento inacessível para a identidade do pool. Registre também a arquitetura do processo e de cada componente nativo. Uma DLL COM de 32 bits pode ser registrada em um servidor de 64 bits e permanecer invisível para o processo que precisa dela. No navegador, essas falhas parecem erros da aplicação; no servidor, erros de hospedagem. É por isso que o ambiente reconstruído precisa de um conjunto controlado de requisições.

Não aceite uma página inicial funcional como prova de compatibilidade. Exercite uploads, exportações de relatórios, recuperação de senha, tarefas de fim do dia, caracteres incomuns, grandes conjuntos e qualquer rota que crie documento ou chame outra máquina. Sistemas antigos concentram suas dependências mais difíceis em caminhos administrativos pouco usados. Um teste superficial não os toca, e eles bloqueiam a primeira tarefa financeira ou de suporte após a virada.

Um monólito PHP traz um problema de custo de mudança

Um monólito PHP precisa de uma decisão de arquitetura quando mudanças de negócio atravessam código demais, não apenas quando a versão do PHP parece antiga. PHP suportado, servidor atual e implantação repetível podem remover a urgência do runtime e deixar um sistema em que checkout inclui regras fiscais, relatórios criam conexões e um include compartilhado altera a autenticação de toda rota. Atualizar o interpretador é manutenção. Redesenhar essas fronteiras é modernização.

Equipes costumam propor uma atualização de framework como se ela criasse arquitetura. Não cria. Mover estado global para um contêiner de injeção pode gerar sintaxe mais limpa e preservar o mesmo acoplamento. Trocar uma biblioteca Active Record por outra pode manter ambígua a responsabilidade pelas transações. Dividir controllers em services pode criar pastas sem criar comportamento testável de modo independente. A recomendação é popular porque ferramentas automatizam parte da sintaxe e o diff parece produtivo. Ela está errada quando o custo vem de lógica de negócio sem dono estável.

Encontre os caminhos de mudança. Revise trabalho recente e acompanhe o que desenvolvedores tocaram para uma regra de preço, campo de cliente, permissão ou relatório. Identifique tabelas gravadas por módulos sem relação, valores de sessão tratados como API oculta, includes com efeitos colaterais e jobs que chamam o código web por outra entrada. Essas conexões mostram onde uma fronteira alvo reduz o custo futuro. Uma contagem de arquivos não mostra.

Um sistema PHP também pode ter prazo de runtime, especialmente se usa interpretador sem suporte ou extensões abandonadas. Isso ainda não transforma os dois casos em um só. Remova a exposição imediata com a menor atualização segura que possa provar e decida a arquitetura pelos padrões de mudança observados. Misturar compatibilidade urgente com redesenho amplo dificulta localizar falhas.

Meça o custo da mudança com evidências que a organização já tem. Pegue uma amostra de tickets concluídos e associe cada um a arquivos, tabelas, jobs e unidades de implantação tocados. Reveja incidentes causados por mudanças em módulos aparentemente separados. Observe quanto tempo revisores gastam reconstruindo efeitos colaterais e quantas versões exigem coordenação entre equipes. Você não precisa de uma pontuação artificial de acoplamento. Precisa de um mapa que explique por que um pedido modesto atravessa autenticação, cobrança, relatórios e um diretório compartilhado de utilitários.

Esse mapa também evita um erro caro: extrair o código que parece velho em vez da capacidade que muda mal. Um relatório estável e feio pode não merecer redesenho. Um módulo recente que não possui dados e atravessa seis serviços compartilhados pode merecer atenção primeiro. A modernização paga seu custo ao melhorar o trabalho futuro, não ao fazer cada arquivo parecer atual.

Os inventários respondem a perguntas diferentes

O inventário de Classic ASP pergunta: "O que precisa existir para esta requisição rodar exatamente como hoje?" O de PHP pergunta: "O que precisa mudar junto e por quê?" Ambos inspecionam código, configuração, dados, tráfego e operações, mas dão pesos diferentes às evidências.

Não junte tudo em uma planilha com colunas para nome, linguagem e complexidade. Esse formato cria falsa comparabilidade. Uma chamada ASP de cinco linhas para um componente COM proprietário pode controlar todo o cronograma. Um controller PHP de cinco mil linhas pode ser verboso, mas separável mecanicamente. Classifique dependências de Classic ASP pelo risco de reconstrução e substituição. Classifique áreas PHP por acoplamento, frequência de mudança e responsabilidade de negócio.

Há outra distinção que equipes confundem: descobrir dependências não é descobrir arquitetura. A primeira atividade encontra o que o sistema precisa para executar. A segunda encontra quais responsabilidades devem mudar de forma independente. Classic ASP exige a primeira antes da mudança do host. A modernização de PHP ganha a maior parte do valor com a segunda. Ambos os projetos precisarão das duas, mas em ordem e profundidade diferentes.

Comportamento registrado é o terreno comum

As duas migrações precisam de uma base de comportamento antes de qualquer reescrita, pois o código-fonte é uma especificação incompleta. Tráfego de produção revela combinações de parâmetros, cookies, redirecionamentos, tipos de conteúdo, codificações, erros e suposições de tempo que a revisão não vê. Snapshots do banco, arquivos gerados, mensagens de saída e resultados de jobs acrescentam os efeitos que HTTP não mostra.

Registre requisições representativas com valores sensíveis removidos ou substituídos e reproduza-as contra os sistemas antigo e novo em ambiente controlado. Compare status, cabeçalhos relevantes, corpos normalizados, mudanças no banco, arquivos e eventos de saída. Não compare todo byte volátil. Datas, identificadores, ordem sem contrato e tokens CSRF exigem normalizadores explícitos. Cada normalizador precisa de dono e motivo, pois um muito amplo apaga uma regressão real.

Um caso útil de paridade contém tanto o estímulo quanto os efeitos observáveis esperados:

{
  "case": "invoice-posted-with-credit",
  "request": {
    "method": "POST",
    "path": "/billing/post.asp",
    "form": {"invoice_id": "18421", "apply_credit": "1"}
  },
  "expect": {
    "status": 302,
    "location": "/billing/view.asp?id=18421",
    "database": ["invoice.status=posted", "credit.remaining=0"],
    "outbound": ["invoice-posted email"]
  }
}

A ferramenta pode ser diferente, mas sua saída deve identificar caso, observação divergente, valor antigo e novo. "Teste falhou" não basta em migração. Um engenheiro precisa saber se um redirecionamento mudou, um decimal arredondou de outro modo ou um e-mail saiu duas vezes.

Em Classic ASP, o comportamento registrado protege contra diferenças de datas, páginas de código, coerção Variant e retornos COM. Em PHP, protege a equipe enquanto move lógica entre novas fronteiras. O mecanismo é comum; o motivo é diferente.

Cobertura importa mais que volume bruto. Construa casos em torno de estados e transições: primeira compra e compra repetida, direito expirado, pagamento parcial, usuário com duas funções, relatório que cruza mudança de horário e repetição após timeout de outro sistema. Ligue cada caso ao tráfego que prova que sua forma é real. Milhares de GETs bem-sucedidos e duplicados dão menos confiança que um estorno registrado com efeitos no banco verificados.

Mantenha o sistema antigo como oráculo apenas enquanto entender seus limites. O resultado antigo pode conter um defeito do qual usuários dependem, ou um defeito que a migração deve remover de propósito. Marque diferenças intencionais como decisões revisadas com dono e nova expectativa. Não as esconda em um normalizador. O mecanismo de paridade deve expor toda diferença e deixar pessoas classificá-la, nunca declarar silenciosamente que o antigo está certo.

A sequência de Classic ASP remove primeiro o risco do host

Um bom plano de Classic ASP torna o comportamento portátil antes de tornar o desenho elegante. A sequência deve revelar cedo o estado da máquina e removê-lo de modo deliberado.

1. Reconstrua a aplicação em Windows e IIS limpos e suportados usando configuração escrita e instaladores preservados. Registre toda ação manual que o repositório não reproduz.
2. Capture e repita comportamento representativo nos hosts atual e reconstruído. Resolva diferenças de compatibilidade antes de introduzir nova arquitetura.
3. Substitua ou encapsule dependências que não sobrevivem à mudança, começando por componentes COM, provedores antigos e armazenamento local. Dê a cada substituição seus casos de paridade.
4. Reescreva comportamento delimitado no runtime alvo enquanto a aplicação antiga permanece como oráculo. Envie tráfego controlado à rota nova e compare efeitos.
5. Faça a virada apenas quando operações puder implantar, restaurar, observar e reverter o sistema sem acessar a máquina original.

A sequência pode revelar que uma parada temporária no IIS é necessária. É aceitável se for explícita, reproduzível, corrigida e tiver condição de saída. Mover uma máquina virtual opaca para outro data center e declarar vitória não é modernização. O host temporário compra tempo para remover dependências de máquina; não deve virar o plano permanente por inércia.

Evite redesenhar todo fluxo enquanto não puder explicar como o host antigo o executa. Se uma página de fatura reescrita difere da produção, você precisa distinguir regra de negócio, localidade, comportamento de ADO e chamada COM. Separar paridade de ambiente de mudança de desenho reduz esse espaço de busca.

A sequência de PHP cria e testa fronteiras

Um bom plano de PHP começa com uma fronteira alvo ligada à pressão real de mudança e move o comportamento por essa separação. O monólito pode permanecer em um host suportado enquanto a equipe prova uma fronteira de domínio por vez. Uma reescrita completa a portas fechadas remove o retorno que deveria moldar o desenho.

Escolha fronteiras por responsabilidade de negócio e necessidade transacional, não por substantivos em nomes de tabelas. "Cliente" aparece em todo lugar e raramente produz o melhor primeiro serviço. Uma decisão de preço, geração de documentos, checagem de direito ou liquidação costuma ter entrada, saída e dono mais claros. Mantenha junto o trabalho que requer uma transação atômica até ter uma estratégia consciente de consistência. Chamadas de rede não melhoram um desenho só por cruzar processos.

A primeira extração deve provar o mecanismo arquitetônico: autenticação dos chamadores, evolução de contratos, propriedade das gravações, repetição sem efeitos duplicados, exposição de falhas e retorno ao caminho antigo. Também precisa provar que a fronteira reduz o escopo das mudanças. Se toda função exige edições dos dois lados, a equipe criou distribuição sem independência.

Não exija microsserviços. Um monólito modular em Go ou TypeScript pode explicitar responsabilidade e direção de dependências com custo operacional muito menor. Rust pode servir a um núcleo numérico em que overflow, precisão e vazão pedem controle rigoroso, mas usá-lo no tratamento comum de requisições adiciona uma fronteira de linguagem sem resolver um problema do domínio. A arquitetura alvo deve remover o acoplamento medido, não exibir tecnologias preferidas.

A propriedade dos dados decide se a separação é real

A migração não criou fronteira se o componente novo e a aplicação antiga atualizam as mesmas tabelas quando querem. Leituras compartilhadas podem ser uma ponte temporária. Gravações compartilhadas criam dois conjuntos de invariantes, dois modelos transacionais e nenhum dono confiável quando valores divergem. O risco existe em ambos, mas fica central no trabalho arquitetônico de PHP porque a extração convida ao compartilhamento prematuro do banco.

Comece nomeando quem grava cada fato de negócio. Se o novo módulo de preços possui uma cotação calculada, o monólito pode pedir o cálculo e guardar uma referência imutável, ou o módulo pode possuir o registro e expô-lo por contrato. Ambos funcionam. Deixar os dois recalcular e sobrescrever o valor não funciona. Registre qual lado valida transições, atribui identificadores e publica efeitos.

Classic ASP costuma esconder comportamento em stored procedures, triggers e padrões ADO. Reescrever uma página mantendo o SQL pode mudar tipos de parâmetros, tratamento de null, cursores ou escopo da transação. Rode paridade no nível dos efeitos do banco, sobretudo para dinheiro, datas e atualizações de várias linhas. Resposta HTML igual não prova operação igual.

Monólitos PHP escondem o mesmo atrás de ORM. Callbacks, lazy loads, escopos globais e transações implícitas podem transformar uma chamada simples em vários efeitos. Antes de mover o método, capture consultas e estado final e decida quais efeitos pertencem à nova fronteira. Reproduzir callbacks cegamente é transliteração. Removê-los cegamente é perda de dados.

Planeje o estado de transição, não apenas o final. Se o código antigo precisa ler dados do novo componente, prefira uma view de compatibilidade, API ou modelo de leitura replicado explícito, com data para remoção. Se os dois caminhos precisam receber o mesmo comando em um teste, designe um como autoridade e compare os efeitos propostos pelo outro sem confirmá-los. Gravações duplas parecem fáceis em diagramas, mas falhas parciais as transformam em sistema de conciliação. Poucas equipes querem construir e operar esse sistema como ponte temporária.

Mudanças de schema precisam da mesma disciplina. Adicione campos e leitores antes de mudar escritores, aceite representações antigas e novas durante a transição e remova a compatibilidade quando o tráfego provar que o caminho antigo acabou. Os deployments de banco e aplicação podem não ser atômicos. Um plano que presume o contrário encontrará um rollback na ordem errada.

Sessões, jobs e arquivos expõem a aplicação escondida

O caminho de requisição e resposta costuma ser menos que o sistema inteiro. Aplicações Classic ASP podem usar sessão InProc ligada a um worker do IIS, gravar documentos em diretório local, aceitar uploads processados por tarefa do Windows ou chamar um objeto COM para enviar e-mail. Monólitos PHP podem ter crons que inicializam a web, workers com variáveis diferentes, sessões compartilhadas e arquivos usados para coordenação.

A migração de sessão exige escolha explícita. Você pode preservar cookie e representação, conectar buscas entre runtimes ou exigir novo login em uma virada planejada. A escolha depende de segurança e impacto. Fingir que sessões passam automaticamente não é escolha. Teste expiração, rotação depois da autenticação, requisições simultâneas, logout e reinícios de deployment.

Jobs precisam de corpus próprio. Registre entradas, regras de horário, travamento, efeitos no banco, arquivos e repetição. Um job que funciona manualmente pode duplicar faturas quando dois agendadores coincidem. Um consumidor de fila não devolve HTTP, mas pode carregar a lógica mais perigosa.

Trate caminhos de arquivos como interfaces. Identifique quem grava e lê, regras de nome, retenção, codificação, atomicidade e o resultado de uma gravação parcial. Mudar de diretório Windows local ou host PHP compartilhado para armazenamento de objetos altera consistência e permissões. Modele a mudança em vez de trocar uma string e torcer pelo comportamento dos consumidores.

Os critérios devem provar o risco dominante

Um painel comum pode acompanhar ambos os projetos, mas os critérios de liberação não devem ser idênticos. Classic ASP deve provar que a organização escapou do host antigo. PHP deve provar que o desenho reduz acoplamento sem mudar comportamento. Contar arquivos convertidos ou testes unitários não prova nenhum dos dois.

Para Classic ASP, exija construção limpa a partir de artefatos controlados; inventário completo com dono e decisão para cada dependência; paridade em comportamento interativo e em lote; evidência operacional de implantação, backup, restauração, monitoramento e rollback; e um teste mostrando que desligar o servidor antigo não remove instalador, segredo, certificado ou fonte necessária. Prontidão para desativação é propriedade de aceitação.

Para PHP, exija contrato explícito por fronteira, um gravador por fato movido, paridade em respostas e efeitos, regras de dependência impostas no código ou build, testes de falha e repetição entre processos e evidências de mudanças concluídas nas quais trabalhar na área extraída não exige editar partes sem relação. A independência deve aparecer no caminho de mudança.

Comparações de desempenho precisam de contexto. Iguale formas de requisição e concorrência, aqueça caches e compare trabalho no banco além de latência. Um endpoint pode responder rápido e mandar trabalho caro para uma fila que não acompanha. Um relatório pode parecer rápido numa cópia vazia e falhar com o volume do fechamento mensal. Use carga e distribuição reais.

Defina orçamentos de falha para a mecânica da migração. Quantas diferenças podem ficar abertas, que gravidade bloqueia tráfego, quanto atraso de fila é aceito e que conciliação precisa ser zero? Diga quem pode dispensar um critério e como registra a decisão. Sem regras, o cansaço de reuniões transforma diferenças inexplicadas em risco aceito. Com elas, a liderança distingue detalhes visuais de efeitos financeiros incertos.

Ensaie rollback na mesma fronteira do rollout. Se o roteamento move uma capacidade, prove que ela pode voltar sozinha sem perder gravações novas. Se a virada move a aplicação inteira, meça restauração e conciliação com dados do formato de produção. Um documento de rollback nunca executado é hipótese, não controle operacional.

Uma estimativa não expressa as duas incertezas

Uma estimativa de Classic ASP deve expor dependências desconhecidas do host, opções de substituição e evidência disponível. Uma de PHP deve expor decisões de fronteira, propriedade compartilhada e custo de mudar chamadores. Um fornecedor que precifica ambos por linhas e páginas mediu digitação, não risco.

Peça à equipe de Classic ASP uma reconstrução limpa e que mostre como descobre chamadas fora do repositório. Pergunte o destino de cada objeto COM, DSN, tarefa, certificado e diretório. Pergunte como comparará comportamento quando Variant ou localidade mudar um resultado. Uma proposta que começa com conversão automática sem responder começa tarde demais na pilha.

Peça à equipe PHP que desenhe a fronteira de propriedade e percorra por ela uma função recente. Pergunte qual componente grava cada tabela, como uma operação permanece idempotente após repetição e que evidência faria a equipe manter um monólito modular. Uma proposta que promete microsserviços antes de estudar transações escolheu o diagrama antes do sistema.

A estrutura do contrato deve seguir evidências. A descoberta precisa produzir registro de dependências, corpus de comportamento, mapa de fronteiras, decisões alvo e critérios de aceitação. Marcos devem corresponder a riscos removidos ou comportamento funcional, não percentuais de arquivos. Datas fixas não removem incógnitas; tornam descoberta inicial e decisões estreitas mais importantes.

A estimativa deve separar implementação conhecida e opções explícitas. Substituir um componente COM específico pode ter preço depois de observar entradas e saídas. Decidir se uma capacidade PHP pertence ao monólito, a um módulo ou serviço é uma opção arquitetônica com efeitos em implantação e dados. Misturar ambos em um percentual de contingência esconde qual decisão pode mudar o trabalho.

Exija suposições verificáveis. "Aplicação ASP padrão" e "base PHP típica" não dizem nada. "Nenhum componente nativo grava fora dos diretórios listados" pode ser conferido. "O fluxo de liquidação possui estas quatro tabelas e nenhum outro código as grava" pode ser conferido. A estimativa ganha confiança quando a equipe diz qual observação a mudaria.

O plano certo segue o motivo da mudança

Classic ASP deve permitir desligar o host Windows antigo sem perder comportamento ou instrução operacional oculta. Uma modernização de PHP deve permitir mudar uma capacidade de negócio sem rastrear estado compartilhado pelo monólito inteiro. São linhas de chegada diferentes.

CodeHero recebe fontes Classic ASP e PHP, lê toda a base e suas linguagens em conjunto e verifica o comportamento reescrito com um mecanismo de paridade contra tráfego registrado. Seus projetos modernizam a arquitetura para Go, Rust, TypeScript e Postgres em menos de 30 dias, inclusive com os modelos fornecidos pela CodeHero executados de forma air-gapped em hardware dentro do perímetro do cliente quando o ambiente exige.

Mesmo que use outra equipe, exija que o plano nomeie o risco dominante na primeira página. Para Classic ASP, peça evidência de que o host pode ser reconstruído e removido. Para PHP, peça uma descrição defensável de propriedade, transações e caminhos de mudança que a arquitetura encurtará. Se um modelo responde aos dois, provavelmente não respondeu a nenhum.