Como trocar de sistema sem parar a empresa

Quem precisa de sistema novo tem uma operação rodando agora, que não pode parar para receber a novidade. Isso parece óbvio escrito assim, mas é a primeira coisa que os projetos ignoram.

A sequência que sobreviveu na prática tem quatro passos, e o primeiro é o que mais gera estranheza.

Comece por fora

O módulo novo nasce separado do sistema existente. Repositório próprio, publicação própria, vida própria.

Parece meio caminho, eu sei. Mas quando você acopla no começo, dois problemas aparecem juntos. Qualquer erro no que está sendo construído derruba o que já funciona, e a velocidade do projeto cai para a velocidade da parte mais lenta e mais antiga.

Construindo por fora, você entrega em semanas em vez de trimestres. E a decisão de juntar as coisas passa a ser consequência de um resultado que já apareceu, não um requisito para começar.

Rode os dois ao lado

O novo funciona junto com o antigo por um tempo, com os dois vivos, até dar para comparar resultado com resultado.

É a etapa que todo mundo quer pular, porque parece desperdício. É também a que gera confiança, e sem ela ninguém autoriza desligar nada.

Tenha um botão de desligar

Cada módulo tem uma chave que decide se ele está no ar ou não. Ela fica no banco de dados, não no código, e o padrão é estar desligada. Quem liga faz isso de propósito, olhando para a tela.

Isso dá uma coisa que nenhum plano de migração dá: poder desligar em trinta segundos, sem publicar nada e sem chamar ninguém, quando algo dá errado às três da tarde de uma quinta-feira. E algo sempre dá errado numa quinta-feira.

Agora o erro que eu cometi

A fase em que os dois sistemas convivem precisa ter data para terminar. A minha não tinha.

O que acontece quando falta essa data é lento e não dispara alarme nenhum. O sistema antigo para de receber correções, porque a atenção foi toda para o novo. O novo avança. E os dois continuam escrevendo nos mesmos dados, só que o antigo agora grava com regras velhas por cima do que o novo já atualizou.

Vi essa defasagem passar de 35 dias. Nada quebrou em nenhum momento. Os dados só foram ficando errados devagar, que é de longe a pior forma de errar, porque não existe o dia em que alguém percebe.

A solução foi matar a tela antiga de uma vez, com um redirecionamento. Deveria ter sido feito no dia em que a primeira correção foi aplicada em um lado só.

Ficou uma regra que eu uso desde então: no momento em que uma correção é feita em apenas um dos dois lados, o outro lado já morreu. Falta só admitir.

Coloque isso no contrato

Vale escrever a sequência no contrato, com a data de desligamento do sistema antigo marcada como um marco do projeto.

Serve para os dois lados. Protege o cliente de pagar por dois sistemas ao mesmo tempo, e protege quem entrega daquela conversa de seis meses depois, em que alguém diz que a planilha antiga ainda é a oficial.

Porque um projeto que roda ao lado da planilha e nunca a substitui não virou nada. Foi uma demonstração caríssima.