A Armadilha da Migração: Quando o Substituto Não Consegue Substituir

Na semana passada escrevi sobre por que 31 mil milhões de dólares em valor de mercado se evaporaram por causa de um post de blogue sobre a modernização de COBOL. A conclusão foi que o mercado não entrou em pânico porque a AI ameaça os sistemas legados — entrou em pânico porque a AI ameaça o modelo de receita construído em manter esses sistemas complexos, opacos e caros.

Esta semana, quero mostrar o que de facto acontece quando as organizações tentam a modernização que toda a gente agora debate. Não em teoria. Não num post de blogue. Na realidade — com orçamentos reais, equipas reais, e consequências reais.

Há um padrão que vi repetir-se em organizações de infraestrutura crítica durante mais de três décadas. Os nomes mudam. Os fornecedores mudam. Os PowerPoints ficam melhores. O resultado não.

Uma organização opera as suas operações sobre uma plataforma legada. A plataforma funciona. Funciona há décadas. Não é glamorosa. Não fotografa bem para os relatórios anuais. Mas quando algo se avaria às 3 da manhã, alguém sabe como o corrigir — normalmente em minutos.

Depois alguém decide que a plataforma precisa de ser substituída.

Não porque deixou de funcionar. Porque deixou de parecer moderna.

A promessa

O business case para a nova plataforma é sempre impecável no papel. Promete tudo o que a antiga entrega, mais uma lista de atributos que se leem como uma brochura de consultoria de gestão: disponibilidade, resiliência, agilidade, time-to-market, escalabilidade.

Cada atributo ganha uma letra. As letras formam uma sigla. A sigla ganha um nome de projeto. O nome do projeto aparece em slide decks, em pedidos de orçamento, em organogramas. Torna-se uma entidade viva com a sua própria atração gravitacional — atraindo orçamento, efetivos e carreiras.

A premissa não é questionada. A plataforma antiga custa dezenas de milhões por ano em licenciamento — uma rubrica grande e visível no balanço. A nova plataforma vai eliminar esse custo. É esta a narrativa. É limpa, é convincente, e é fundamentalmente incompleta.

Porque a pergunta que nunca recebe tempo de antena adequado não é «conseguimos construir um substituto?». É «conseguimos desligar aquilo que ele substitui?».

A execução

A arquitetura antiga era simples por necessidade. Duas camadas. Um front-end que tratava da interface. Um back-end que tratava do processamento. Dois sistemas. Modos de falha conhecidos. Uma equipa que compreendia ambos.

O substituto foi desenhado para um mundo distribuído. Múltiplas camadas, múltiplos serviços, múltiplas interfaces. Isto é arquiteturalmente defensável em teoria. Na prática, significa que cada função que antes existia num só lugar existe agora em vários, com protocolos de comunicação, latência e domínios de falha entre cada um.

O âmbito do projeto expandiu-se. Como o back-end corria processamento batch que não podia ser replicado na nova arquitetura, criou-se um subprojeto paralelo — uma iniciativa de «rehosting» para tratar das cargas de trabalho que a nova plataforma não conseguia absorver. Um projeto de substituição tornou-se dois.

O orçamento cresceu. Quando os números ainda eram acompanhados internamente, o projeto tinha consumido mais de dez vezes o custo anual da plataforma que era suposto eliminar. Em poucos anos.

Os efetivos explodiram. A operação original corria com algumas centenas de pessoas. Num curto período, a organização cresceu para várias vezes esse número — uma combinação de contratações permanentes e consultores externos. Aos consultores, trazidos para preencher as lacunas de competência inerentes aos sistemas distribuídos, foram oferecidas condições que muitos funcionários internos de longa data só podiam observar à distância. Carros. Cartões de combustível. Estacionamento reservado. O simbolismo não passou despercebido a ninguém.

E a plataforma antiga? Continua a correr. Continua a processar. Continua a consumir os mesmos custos de licenciamento que sempre teve. Porque acabou por se ver — como algumas pessoas tinham dito desde o início — que não se consegue simplesmente desligá-la.

A aritmética

Antes do projeto, a organização tinha dois sistemas e uma equipa que os compreendia.

Depois do projeto, a organização tem quatro sistemas: o front-end original, o back-end original, a nova plataforma distribuída, e a camada de rehosting. Nenhum deles é opcional. Todos exigem manutenção, licenciamento e pessoas.

O custo da plataforma antiga não desapareceu. Juntou-se-lhe o custo da nova. Os efetivos não estabilizaram — multiplicaram por seis.

E eis o detalhe que corta mais fundo: quando é preciso implementar uma nova função na plataforma antiga, leva dias. Correções ou melhorias levam de minutos a umas duas horas. Na nova plataforma — a construída para «time-to-market» — as novas funções levam de semanas a meses. E quando são precisas correções urgentes, a nova plataforma faz o que nunca foi planeado no business case original: recorre à antiga. O sistema construído para substituir o legado tornou-se dependente dele.

A promessa era eliminação. O resultado foi multiplicação.

A falha de governação

Se isto fosse puramente um erro técnico de cálculo, seria doloroso mas perdoável. As migrações complexas correm mal. As estimativas são excedidas. Os prazos derrapam. Isto é sabido.

O que torna este padrão estrutural e não acidental é o que aconteceu a seguir.

A liderança da organização mudou. A nova administração chegou de uma indústria diferente — as telecomunicações — e trouxe uma camada inteira de gestão desse mundo. Posições que tinham sido ocupadas por pessoas com décadas de conhecimento de domínio foram reatribuídas a pessoas com lealdade à nova liderança mas sem compreensão dos sistemas por que eram agora responsáveis.

Os peritos internos — as pessoas que tinham construído, mantido e compreendido a infraestrutura — não foram despedidos. Isso teria sido demasiado visível. Foram reatribuídos a papéis operacionais onde a sua perícia continuava a manter as coisas a funcionar, mas onde as suas vozes já não chegavam aos fóruns de decisão. Tornaram-se, com efeito, a tripulação da casa das máquinas de um navio cujos oficiais de ponte nunca tinham navegado estas águas.

Alguns levantaram preocupações. No início do projeto, houve reuniões onde perguntas técnicas e operacionais foram postas em cima da mesa — perguntas sobre viabilidade, sobre cenários de fallback, sobre se a premissa fundamental de eliminação era realista. Essas reuniões foram descontinuadas. Não porque as perguntas tenham sido respondidas. Porque as perguntas eram inconvenientes.

Os melhores foram-se embora. Não porque tenham sido empurrados — embora alguns o tenham sido, na prática — mas porque os profissionais competentes não permanecem em ambientes onde a competência é subordinada ao alinhamento político. A organização sangrou conhecimento institucional, uma demissão de cada vez. Cada saída tornava a equipa restante mais dependente de consultores externos que não tinham memória institucional nem incentivo para simplificar.

Por que acontece

Isto não é uma história sobre uma organização. É um padrão que se repete sempre que três condições convergem.

Condição 1: O custo é invisível para quem decide. Em organizações onde o orçamento vem de clientes cativos — entidades que não têm fornecedor alternativo — não há sinal de mercado para o fracasso. O custo da migração é absorvido em encargos operacionais que os clientes têm de pagar de qualquer forma. Quem decide nunca enfrenta a consequência das suas decisões sob a forma de negócio perdido, porque o negócio não pode sair.

Condição 2: A impunidade é estrutural. Quando uma organização é detida pelos seus próprios clientes, e esses clientes são em simultâneo acionistas, clientes e fonte de financiamento, a responsabilização torna-se circular. As perdas de um projeto falhado são absorvidas pelos donos que são os clientes que são os acionistas. É um ciclo fechado. Nenhum órgão externo alguma vez audita o delta entre o que foi prometido e o que foi entregue — porque toda a gente à mesa é simultaneamente responsável e cúmplice.

Condição 3: O projeto serve carreiras, não operações. Uma plataforma legada que funciona não gera promoções. Um projeto de transformação de centenas de milhões gera. Cria posições, orçamentos, visibilidade e narrativa. «Liderei a modernização de infraestrutura nacional» é uma linha que define uma carreira num CV. «Mantive uma plataforma que processava milhares de milhões de transações sem incidentes» não é. A estrutura de incentivos recompensa a disrupção mesmo quando a continuidade é o que a operação precisa.

Estas três condições — custo invisível, impunidade estrutural, e decisões movidas pela carreira — são as duas variáveis da minha newsletter anterior (impunidade e dinheiro barato) aplicadas a um domínio específico. A armadilha da migração não é um problema de tecnologia. É um problema de governação vestido com um fato de tecnologia.

O padrão mais profundo

O que descrevi não é uma falha da modernização. A modernização é por vezes necessária, por vezes valiosa, por vezes inevitável. O que descrevi é o que acontece quando a modernização é tratada como um objetivo em vez de um meio — quando a decisão de migrar é tomada antes da pergunta sobre se a migração serve a operação.

A plataforma antiga tinha uma característica que nenhum sistema distribuído consegue replicar facilmente: a concentração. Um sistema para compreender. Uma equipa para o manter. Uma só garganta para apertar quando algo corria mal. Esta concentração foi descrita como uma fraqueza — um ponto único de falha, uma dependência de fornecedor, um anacronismo arquitetural.

Mas a concentração tem uma propriedade que à distribuição falta: a responsabilização. Quando o sistema está num só lugar, as falhas estão num só lugar. O conhecimento está num só lugar. O custo está num só lugar — visível, mensurável, gerível.

A distribuição dispersa tudo. O sistema torna-se muitos sistemas. As falhas ficam distribuídas por serviços, interfaces e equipas. O conhecimento fragmenta-se por fornecedores, contratados e consultores — cada um a segurar uma peça, nenhum a segurar o quadro. E o custo dispersa-se por rubricas de orçamento, contratos e SLAs até que nenhum número único capta o total.

A plataforma antiga era cara. O substituto é mais caro. Mas o custo do substituto está espalhado por rubricas suficientes para que nenhum relatório único mostre o quadro completo. Isto não é um bug. É a funcionalidade que torna estes projetos politicamente sobreviventes.

O que teria funcionado

É aqui que me recuso a ser a pessoa que só diagnostica e nunca prescreve.

Primeiro: Avaliação honesta antes do compromisso. «Conseguimos de facto desligar a plataforma antiga?» é a única pergunta que importa num projeto de substituição. Se a resposta é «durante anos não» ou «não por completo», então o projeto não é uma substituição — é uma adição. Orce-o como uma adição. Dote-o como uma adição. Defina expectativas como uma adição. O dano vem da distância entre o que é prometido (eliminação) e o que é entregue (multiplicação).

Segundo: Validação técnica das decisões estratégicas. Nenhuma migração de infraestrutura crítica deveria avançar sem o aval das pessoas que operam o sistema atual. Não como cortesia — como requisito de governação. As pessoas que mantêm o motor são as únicas que sabem que partes podem ser substituídas sob carga e quais não podem.

Terceiro: Contabilidade honesta. O custo total da migração — incluindo o custo contínuo da plataforma que era suposto substituir — deveria ser reportado como um único valor, anualmente, ao órgão de governação. Não distribuído por rubricas de orçamento. Não enterrado em encargos operacionais. Um número. Comparado anualmente com o custo do sistema que era suposto eliminar.

Quarto: Proteger o conhecimento institucional. As pessoas que sabem como o sistema funciona não são intercambiáveis com pessoas que sabem como funciona um sistema diferente. O conhecimento de domínio leva décadas a construir e meses a perder. Qualquer transformação que trate operadores experientes como obstáculos em vez de ativos não está a modernizar — está a amputar.

A conclusão

Toda a organização de infraestrutura crítica enfrentará esta decisão mais cedo ou mais tarde. A tecnologia vai envelhecer. Os fornecedores vão empurrar upgrades. Os consultores vão apresentar roadmaps. O conselho vai querer ver «transformação» no plano estratégico.

Quando esse momento chegar, a pergunta a fazer não é «o que promete a nova plataforma?». É «o que acontece se não conseguirmos desligar a antiga?».

Porque se a resposta honesta é «vamos ter as duas», então não está a planear uma migração. Está a planear uma multiplicação — de sistemas, de custo, de complexidade, e do número de coisas que podem correr mal às 3 da manhã.

E é bom que se certifique de que as pessoas que sabem corrigir coisas às 3 da manhã ainda estão no edifício quando isso acontecer.