Cutover Sem Janela de Manutenção Perfeita

O problema

Todo plano de migração eventualmente bate nesta pergunta:

“Quando a gente vira de vez?”

Esse momento e o cutover.

E muita gente ainda imagina o cutover assim:

• para o sistema
• troca tudo
• sobe o novo
• volta a operar

Só que sistema real quase nunca entrega essa paz.

Tem tráfego continuo, integração externa, job rodando, fila atrasada, cliente velho e urgencia de negócio.

Esperar uma janela perfeita pode significar nunca sair do lugar.

Modelo mental

Pense assim:

cutover e a troca do caminho principal sob risco controlado

O objetivo não e encontrar o momento perfeito.

E criar um momento suficientemente seguro.

Isso pede tres coisas:

• compatibilidade antes da troca
• observabilidade durante a troca
• reversao depois da troca, se necessário

Sem essas tres, o plano depende mais de sorte do que parece.

Quebrando o problema

Diferencie preparação de troca

Muito trabalho importante do cutover acontece antes do dia da virada.

Exemplos:

• schema expandido
• consumidores aceitando os dois formatos
• rota de fallback pronta
• tráfego parcial já validado

Se tudo isso ainda não existe, você não esta perto de um cutover.

Só esta perto de um salto no escuro.

Saiba exatamente o que esta mudando no momento da virada

Cutover ruim tenta mudar muita coisa ao mesmo tempo:

• rota
• storage
• contrato
• observabilidade
• processo operacional

Quanto menos variavel nova entrar no minuto da troca, melhor.

Idealmente, o momento do cutover muda só qual caminho vira principal, não metade da arquitetura.

Tenha critério de stop e de reversao

Virar o caminho principal sem saber quando parar e pedir para o time racionalizar erro.

Antes da troca, você precisa definir:

• o que seria sinal de regressao
• quanto tempo de observação importa
• como volta
• o que acontece com estado escrito durante a janela

Reversao de tráfego pode ser simples.

Reversao de dado quase nunca e.

Trate estado atrasado como parte do plano

Mesmo depois da virada, ainda podem aparecer:

• mensagem antiga na fila
• cliente com cache velho
• job usando contrato antigo
• reprocessamento tardio

Se o sistema novo não lida com esse rastro, o cutover foi otimista demais.

Evite depender de sincronismo organizacional perfeito

Plano fraco costuma depender de:

• todos os times acordados ao mesmo tempo
• nenhuma fila acumulada
• nenhum parceiro externo atrasado
• nenhum rollback necessário

Plano forte assume que parte disso vai falhar e se prepara para isso.

Exemplo simples

Imagine a migração de um endpoint de criação de pedido para um backend novo.

Plano ingenuo:

1. sexta a noite
2. corta tráfego
3. muda DNS ou roteamento
4. confia que tudo já esta pronto

Plano melhor:

1. backend novo já esta exercitado com shadow traffic e cohort pequeno
2. ambos os lados aceitam estado antigo e novo
3. observabilidade e dashboards estao prontos
4. a virada muda só o roteamento principal
5. se erro ou divergencia subir, o tráfego volta rápido

O cutover continua delicado.

Mas deixa de ser loteria.

Erros comuns

• Confiar em janela de manutenção como substituto de compatibilidade.
• Tentar mudar várias camadas ao mesmo tempo no minuto da virada.
• Esquecer mensagens ou consumidores atrasados.
• Ter rollback de tráfego, mas não de operação ou de dado.
• Declarar sucesso cedo demais porque os primeiros minutos pareceram tranquilos.

Como um senior pensa

Quem tem mais experiência trata cutover como operação preparada, não como gesto heroico.

A pergunta boa costuma ser:

“Se a virada acontecer com atraso, fila velha e um pequeno erro escondido, o que ainda me protege?”

Essa pergunta puxa o plano para a realidade.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você sabe fazer a ultima etapa da migração sem romantizar a infraestrutura.

Você sobe de nivel quando:

• diferencia preparação e momento da troca
• fala de compatibilidade e rastro de estado antigo
• lembra de reversao operacional, não só técnica
• mostra que cutover sem perfeicao ainda pode ser seguro

Uma resposta forte costuma soar assim:

“Eu não dependeria de uma janela perfeita. Prepararia compatibilidade antes, exercitaria o novo caminho, deixaria o momento do cutover restrito ao roteamento principal e teria critério claro para observar e reverter se o sinal piorasse.”

Cutover bom não precisa de silencio absoluto. Precisa de proteção suficiente contra o caos normal.

O plano de virada melhora muito quando o minuto da troca faz pouco e o trabalho pesado já aconteceu antes.