Substituir um sistema empresarial: quando faz sentido manter os dois?

Manter disponível um sistema empresarial antigo durante a sua substituição pode ajudar a comparar resultados ou a transferir o trabalho por etapas geríveis. Antes de aprovar esse período, exija quatro elementos: um objetivo específico, um registo claramente definido como fonte oficial, uma pessoa responsável por investigar as diferenças e um critério acordado para terminar a coexistência.

Para um CEO, responsável de operações ou diretor financeiro, a decisão diz respeito à forma como a empresa mantém registos corretos e conclui o trabalho diário. «Vamos manter os dois sistemas» deixa demasiadas questões por resolver. A proposta deve explicar o que cada sistema fará, que sistema os colaboradores utilizarão e quanto custará a solução temporária.

Três significados diferentes de manter os dois sistemas

Comparar resultados. Um sistema continua a realizar a operação efetiva da empresa, enquanto o sistema de substituição calcula um resultado para comparação. Num exemplo hipotético de substituição de um sistema de contabilidade, a equipa poderia comparar relatórios relativos ao mesmo período definido e aos mesmos dados de entrada, enquanto o sistema existente continua responsável pela emissão de faturas. A comparação dos cálculos não pode gerar acidentalmente uma segunda fatura, um pagamento, uma encomenda ou uma mensagem de correio eletrónico.

Defina que diferenças são relevantes e quem as investiga. Um total igual pode ocultar diferenças nos registos individuais, nas regras de arredondamento ou nos prazos. A cópia correta dos dados deixa uma questão separada: os colaboradores conseguem concluir o fluxo de trabalho necessário, incluindo correções e exceções?

Transferir a responsabilidade por fases. Uma função definida ou um grupo de clientes passa para o sistema de substituição, enquanto o restante trabalho continua no sistema antigo. Cada fase precisa de instruções claras sobre onde os colaboradores introduzem as alterações e de que sistema vêm os registos usados nos relatórios. Manter as duas aplicações disponíveis não dá a ambas autoridade sobre todos os registos.

As orientações da Microsoft sobre o padrão Strangler Fig descrevem a transferência gradual de funcionalidades e a remoção posterior do sistema antigo. É necessário acompanhar as dependências e os dados partilhados ao longo de todo o processo. Para quem dirige a empresa, a questão útil é saber se a responsabilidade pode ser dividida com clareza suficiente para operar e verificar cada fase.

Escrever deliberadamente nos dois sistemas. Neste caso, o software é concebido expressamente para registar alterações em dois locais. Isso cria outra obrigação: explicar o que acontece quando uma gravação é bem-sucedida e a outra falha. Alguém tem de detetar a diferença, decidir qual registo prevalece e concluir ou corrigir o trabalho em falta.

A explicação prática da AWS sobre reversão de migrações, publicada por Ed Murray em 2020, ilustra a coordenação necessária para escritas duplas e um regresso faseado. É um exemplo técnico datado, não um plano de implementação pronto a usar. Introduzir os mesmos dados manualmente ou prometer que serão sincronizados não resolve estas responsabilidades.

Compare a coexistência com uma transição de uma só vez ensaiada

A transição por fases pode limitar a quantidade de trabalho que muda de uma só vez, mas manter dois ambientes operacionais acrescenta tarefas de suporte, formação, reconciliação e integração temporária. Inclua esses custos na decisão de substituição, juntamente com o custo de remover as ligações temporárias.

No artigo de 2022 Arquitetura de transição, Ian Cartwright, Rob Horn e James Lewis descrevem ligações temporárias e a sua remoção posterior. A experiência relatada explica como uma ligação temporária pode ser útil e, ainda assim, precisar de orçamento próprio e de um plano de saída.

Também vale a pena comparar uma transição de uma só vez ensaiada quando o sistema é pequeno, não é possível dividir a responsabilidade, não existem pontos de integração adequados ou um prazo urgente para retirar o sistema exclui uma coexistência prolongada. A Microsoft identifica limites semelhantes para a adequação da substituição gradual. Estas condições não tornam automaticamente segura uma transição de uma só vez. Tornam especialmente importantes a preparação, as verificações operacionais e a autoridade para decidir.

Peça provas de um ensaio da transição proposta e condições acordadas para avançar ou parar. Compare as duas opções com o trabalho real que tem de continuar. Nenhuma das opções tem uma duração ou um limiar de aceitação universal.

As novas transações alteram a decisão de reversão

Depois de os colaboradores introduzirem trabalho válido no sistema de substituição, reabrir a aplicação antiga pode deixar esses registos mais recentes para trás. As encomendas também podem ter desencadeado entregas, pagamentos ou mensagens que não podem ser anulados pela reposição de uma base de dados.

As orientações da AWS para a fase de transição distinguem a reversão antes de existirem dados novos da reversão após novas transações, quando a base de dados original pode estar desatualizada. Antes de aprovar o regresso, exija um tratamento específico dos novos registos e das ações subsequentes que desencadearam. Uma cópia de segurança, por si só, não demonstra que as operações possam ser retomadas de forma coerente.

O registo de decisões a solicitar

Um registo breve deve permitir que as pessoas responsáveis pela operação da empresa respondam às seguintes perguntas:

• Objetivo e âmbito: Que trabalho está a ser comparado ou transferido e o que se pretende alcançar mantendo os dois sistemas?
• Autoridade: Onde são introduzidas as alterações em cada fase e que registos regem os relatórios e as ações afetados?
• Reconciliação: Quem investiga as diferenças, como são registadas e quem resolve resultados divergentes?
• Aceitação: Que provas permitem avançar para a fase seguinte, o que obriga a parar e quem decide se se avança ou não?
• Reversão: Como serão tratadas as novas transações e as ações subsequentes já concluídas se o trabalho regressar ao sistema antigo?
• Saída: Que provas permitem retirar o sistema, quem remove as ligações temporárias e que registos devem continuar acessíveis segundo os requisitos aplicáveis?

Aprove a coexistência quando o seu objetivo e as responsabilidades operacionais justificarem o custo e existir uma saída viável. Se estiver a avaliar uma substituição, o nosso serviço de substituição de sistemas legados é um ponto de partida para falar do sistema atual, do trabalho que tem de continuar e das limitações à mudança.