Mudança, migração e clientes legados

A base existente avalia a mudança pela continuidade do próprio trabalho

Para quem já usa a plataforma, uma melhoria pode significar perda de hábito, integração, limite, histórico ou previsibilidade. Você enxerga a capacidade nova; o seu cliente enxerga o esforço de reaprender e o risco de parar uma operação que funcionava sem ele precisar pensar nela. A confiança depende de você reconhecer essa diferença antes de anunciar a transição, e não depois que o primeiro chamado chegar explicando ela para você.

Antes do plano existe um erro de leitura que costuma contaminá-lo inteiro: tratar cliente antigo como cliente avançado. Um estudo do Nielsen Norman Group sobre aplicações complexas, publicado em 27 de junho de 2025, separa três perfis e descreve o primeiro deles, o usuário legado, como quem usa o software há anos ou décadas sem ter se tornado eficiente. A formulação do estudo é curta e desconfortável: familiaridade nem sempre é maestria. O mesmo texto acrescenta o ponto que muda o tom de toda a comunicação de migração ao afirmar que, no caso desses usuários, produtividade, e não resistência, costuma estar no centro da hesitação.

Repare no tamanho da consequência. Se a sua base antiga entrar no plano com o rótulo de experiente, o cronograma vai pressupor autonomia onde existe rotina decorada, o material de ajuda vai ser escrito para quem entende o modelo do produto e o convite vai ser lido por alguém que aprendeu um caminho, não o sistema. A conta chega no suporte, e chega concentrada. Vale também o inverso: quem hesita por produtividade não está pedindo para ficar parado, está dizendo que o trabalho dele não pode parar, e essa é uma objeção que se responde com janela e ensaio, nunca com convencimento.

Sobre esse erro de leitura assenta uma segunda assimetria, e esta é observação de quem conduz transição, não da fonte citada. Quem constrói a mudança conhece o estado futuro em detalhe e subestima o custo de sair do estado atual; quem usa conhece o estado atual em detalhe e superestima o risco de entrar no estado futuro. As duas distorções se somam, e o resultado aparece na estimativa: o seu time calcula o esforço de migração pela dificuldade técnica da virada, enquanto o cliente calcula pelo tempo que vai gastar reconstruindo confiança em uma rotina que já dispensava atenção.

Existe um segundo mecanismo, menos discutido. Toda plataforma acumula dependências que nunca foram projetadas. Alguém montou um relatório em cima do formato de exportação; outra pessoa criou uma automação que depende da ordem de um campo; um time inteiro decorou um atalho. Nada disso aparece no roadmap, porque nada disso foi pedido. Aparece no primeiro dia da migração, em forma de chamado. A assimetria de custo entre achar antes e achar depois é o argumento inteiro desta página, e ela se escreve em duas unidades que você já conta: inventariar essas dependências antes da virada custa alguns dias de duas pessoas, uma vez; descobri-las depois custa chamados concentrados na primeira semana, ao seu tempo médio de tratamento, mais a conversa de recuperação com quem tinha montado a rotina em cima do comportamento antigo. A primeira conta você paga uma vez e escolhe quando. A segunda se repete a cada onda e chega na hora que ela quiser.

Mudança responsável combina valor futuro com proteção presente. Você declara o que muda, o que permanece, quem entra em cada etapa, onde pedir ajuda, qual direito fica preservado e quando a versão anterior pode ser desligada. Transparência reduz surpresa, o que já é bastante. Reduzir risco operacional exige outra coisa: paridade testada com dados reais, em contas reais, antes da escala.

Clientes diferentes precisam de contratos de mudança diferentes

A data de entrada ajuda, porém não explica sozinha a dependência. Duas contas antigas podem usar capacidades distintas, e uma conta nova pode chegar com integração crítica desde o primeiro dia. A coorte de migração combina estágio, uso, complexidade, valor, risco e necessidade de acompanhamento.

A coorte responde onde a conta entra na fila. Ela ainda não responde a pergunta que chega na sua mesa todos os dias, conta por conta: esta migra agora ou fica onde está?

Migrar este cliente legado agora ou mantê-lo onde está?

A decisão erra por dois lados, e os dois erros cobram em moedas diferentes. Migrar cedo demais transfere ao cliente um produto que ainda não faz o trabalho dele: a conta vem em chamados por onda, ao seu tempo médio de tratamento, e parte desse tempo não volta como conta migrada, porque é refazer na conta o que já constava como feito. Adiar sem critério cria uma base paralela que ninguém encerra: a conta vem em horas de manutenção do caminho antigo, todo mês, mais cada mudança futura testada duas vezes, uma em cada realidade. A primeira conta é visível e dói rápido. A segunda é silenciosa, entra no orçamento como normalidade e por isso costuma ser a mais cara das duas.

Quatro eixos separam os dois erros. Avalie cada um com evidência observável, nunca com a impressão de quem atende a conta. A leitura combinada aponta uma entre quatro saídas.

As quatro saídas

O eixo de custo merece cuidado especial, porque tende a inflar sozinho conforme a pressão interna aumenta. Um custo de manutenção só entra na decisão quando alguém consegue nomear as horas, os times envolvidos e o que deixou de ser feito por causa dele. Sem essa decomposição, o argumento de custo empurra contas despreparadas para a migração e produz exatamente o chamado que se queria evitar.

Grandfathering: quando manter a condição antiga é a resposta certa

Manter a condição anterior de forma permanente faz sentido quando a promessa original foi explícita, quando o custo de honrá-la é conhecido e estável, e quando a exceção não impede a evolução do produto para o resto da base. Manter de forma temporária faz sentido quando existe dependência verificável com prazo de resolução. Fora desses dois casos, o que costuma existir é uma decisão adiada com aparência de política.

Toda exceção concedida cria uma variante que alguém precisa testar em cada mudança futura, e esse é o custo real do grandfathering. Repare em como a conta se comporta: dez exceções vivas não custam dez vezes uma exceção, custam dez execuções de teste em cada mudança que tocar aquele caminho, para sempre, e essa conta é paga por um time que não participou de nenhuma das dez decisões. Se a sua lista de exceções só cresce, você está usando exceção como substituto de decisão.

Critério de pronto: a decisão está tomada quando existe, por escrito e por conta, o eixo que a definiu, a saída escolhida entre as quatro, o responsável dos dois lados e a data em que a decisão será revista.

Paridade precisa ser definida pelo trabalho que o cliente realiza

Comparar listas de funcionalidades permite declarar equivalência enquanto uma jornada importante continua quebrada. Paridade operacional pergunta se a pessoa consegue completar o mesmo trabalho, preservar dados, manter controles e recuperar uma falha dentro da nova experiência.

• Jornadas essenciais estão inventariadas por coorte.
• Dados e histórico possuem conferência antes e depois da migração.
• Diferenças de capacidade aparecem em linguagem de cliente.
• Direitos, condições e exceções têm regra e vigência.
• Critério de encerramento do legado foi combinado antes da comunicação.

Amplie a exposição somente quando a coorte anterior confirma segurança e valor

A exposição avança em cinco fases, e cada fase só libera a seguinte depois de entregar uma saída verificável. O desenho reproduz a liberação canário descrita no capítulo 16 do Google SRE Workbook, de 2018: uma parcela pequena recebe a mudança, o restante permanece como controle e os dois são comparados antes de prosseguir. O capítulo desfaz um engano comum sobre o método, e vale repetir a conclusão dele antes que ela vire promessa errada na sua reunião: detectar e reverter levam praticamente o mesmo tempo com ou sem canário. O que o canário compra é outra coisa, e está escrita em uma linha: o impacto no orçamento de erro é diretamente proporcional ao volume de tráfego exposto ao defeito.

Traduzindo para a sua base, é essa proporcionalidade que transforma tamanho de onda em decisão de risco em vez de escolha de calendário. Uma falha que atinge 60 contas e uma falha que atinge 1.150 consomem o mesmo tempo de diagnóstico, e diferem no que já aconteceu com o trabalho de quem está do outro lado quando o diagnóstico termina. Separar a entrega do código da liberação ao cliente, que a documentação de feature flags do GitLab descreve como estratégias de exposição por percentual e por lista de usuários, é o mecanismo que permite parar uma onda sem reverter a entrega inteira.

A comunicação começa pela consequência para o cliente

Uma mensagem de mudança útil responde o que acontecerá, por que a alteração existe, quando chega àquela conta, o que precisa ser feito, o que permanece igual, onde testar, como pedir ajuda e qual alternativa existe. Comunicar cedo sem essas respostas apenas antecipa a ansiedade.

Capacidade de suporte também é um gate. Estime contatos por coorte, motivos prováveis, tempo de tratamento, materiais de autoatendimento e especialistas disponíveis. Se a onda ultrapassa a capacidade de resposta, reduza o lote antes de transferir o custo ao cliente. A conta cabe numa linha: contatos esperados por conta migrada, vezes o tamanho da onda, vezes o tempo médio de tratamento, contra as horas de atendimento livres no dia. O que passa disso não desaparece, vira fila. E quem espera na fila é exatamente o cliente que você acabou de convidar, no dia em que ele mais precisa de resposta.

Meça adoção, continuidade e percepção no mesmo painel

As cinco camadas se leem juntas, e cada par delas conta uma história que nenhuma sozinha conta. Adoção alta com suporte estourado descreve uma migração que está sendo paga pelo atendimento. Suporte tranquilo com paridade baixa descreve contas que desistiram em silêncio e voltaram ao caminho antigo, e isso só aparece quando você compara o uso do legado com a lista de contas que constam como migradas. O silêncio é o sinal mais caro do painel, porque ele se parece com sucesso em todas as outras leituras.

Exemplo resolvido: o construtor de automações que ia virar de uma vez

Recuperar confiança exige reconhecer impacto e devolver controle

Uma recuperação completa combina restabelecimento técnico, explicação compreensível e ação proporcional ao dano. Você informa quem foi afetado, o que está sendo feito, a que horas sai a próxima atualização e qual saída temporária existe até lá. Depois confirma o retorno, preserva o histórico e registra a prevenção. O capítulo 9 do Google SRE Workbook, de 2018, separa três papéis para isso, o comando do incidente, a comunicação e a operação, e a razão de separar é prática: a mesma pessoa não consegue diagnosticar a falha e responder ao cliente ao mesmo tempo sem atrasar as duas coisas.

O cliente não julga a migração pela falha, e sim pela primeira hora depois dela. Nesse intervalo ele descobre se alguém já sabia do problema e quanto do trabalho dele voltou intacto.

Seis erros comuns e como detectá-los antes do dano

Os erros abaixo não aparecem por descuido. Todos têm em comum um sinal que surge cedo e passa despercebido justamente porque parece uma boa notícia, e é essa a razão de eles sobreviverem a revisões inteiras sem serem vistos. A coluna de detecção existe para transformar cada sinal em uma pergunta que você faz antes da próxima onda, quando ainda dá para mudar de ideia barato.

Como executar, na ordem em que as decisões travam umas às outras

A sequência abaixo não é sugestão de organização. Cada passo produz a informação que o seguinte consome, e inverter a ordem costuma produzir um plano que precisa ser refeito. O dimensionamento do suporte, por exemplo, define o tamanho da onda; decidir o tamanho da onda antes de conhecer a capacidade de atendimento gera um cronograma que a operação não consegue cumprir.

1. Inventarie as jornadas antes de olhar para o cronograma

   Liste o que o cliente termina usando a capacidade afetada, incluindo o que ninguém pediu e passou a existir por efeito colateral. Consulte suporte e sucesso do cliente, porque as dependências não documentadas aparecem no histórico de chamados antes de aparecerem em qualquer outro lugar.

   Saída: lista de jornadas essenciais, cada uma com quem a executa e com que frequência.

2. Monte as coortes pelo uso, e não pela data de entrada

   Cruze estágio, volume, integrações, criticidade e necessidade de acompanhamento. A data de contratação ajuda a explicar expectativas contratuais, mas não prevê dependência técnica.

   Saída: matriz de coortes cujo critério de elegibilidade se confere por consulta, sem depender do julgamento de quem atende.

3. Teste a paridade com dados reais, sob autorização

   Execute cada jornada essencial no estado novo com dados equivalentes aos de contas reais. Registre o que passa, o que passa com esforço adicional e o que não passa. Lacunas de dado e de histórico concentram as descobertas, porque são justamente as que nenhum catálogo de recursos mostra.

   Saída: relatório de paridade por jornada e por coorte, com responsável por cada lacuna aberta.

4. Dimensione o suporte e derive daí o tamanho da onda

   Estime contatos por conta migrada, motivos prováveis, tempo de tratamento e capacidade diária disponível sem degradar o atendimento regular. O tamanho máximo da onda sai dessa conta pronto, e o calendário apenas o recebe.

   Saída: capacidade diária declarada, tamanho máximo de onda e roteiro de atendimento escrito para o estado novo.

5. Ensaie o rollback antes da primeira onda real

   Execute a reversão com dados criados depois da virada e cronometre. Classifique o que é reversível, reversível com perda e irreversível. O resultado ajusta o tamanho da onda e a comunicação ao cliente.

   Saída: rota de retorno testada, com tempo medido e perdas conhecidas declaradas.

6. Publique guardrails com número antes de convidar alguém

   Defina, para cada camada de medição, o limite que interrompe a expansão. Guardrail definido depois do primeiro problema tende a se acomodar ao resultado observado, o que remove a função dele.

   Saída: limites numéricos por camada, com dono da decisão de pausar e canal onde a pausa é anunciada.

7. Rode a onda, leia as cinco camadas juntas e decida

   Ao fim de cada onda, decida de forma explícita entre expandir, repetir o mesmo tamanho, reduzir ou pausar. Registre a decisão com a evidência que a sustentou, porque ela será revisitada quando a próxima onda apresentar comportamento diferente.

   Saída: decisão registrada por onda, com data, responsável e evidência anexada.

8. Feche o legado por lista nominal, não por data isolada

   O desligamento acontece quando a lista de contas e jornadas pendentes chega a zero ou a um conjunto de exceções com dono e vigência. Preserve o histórico, comunique a data final em cada canal acordado e mantenha uma janela de recuperação proporcional ao ciclo de trabalho do cliente.

   Saída: decisão de encerramento auditável, com lista final e exceções vigentes documentadas.

Critério de pronto: a transição está sob controle quando qualquer pessoa do time responde, sem consultar terceiros, quantas contas já migraram, qual guardrail está mais perto do limite e quem decide a próxima onda. Se essas três respostas dependem de você, a transição não está sob controle, está sob a sua memória.

Contrato de migração por coorte

MUDANÇA:
RESULTADO ESPERADO:
DONO:
COORTE:
CRITÉRIO DE ELEGIBILIDADE:
JORNADAS ESSENCIAIS:
PARIDADE EXIGIDA:
DADOS E HISTÓRICO A PRESERVAR:
DIREITOS, LIMITES E CONDIÇÕES:
EXCEÇÕES E VIGÊNCIA:
DATA DE CONVITE:
JANELA DE TESTE:
CANAL DE AJUDA:
CAPACIDADE DE SUPORTE:
INDICADORES:
GUARDRAILS:
CRITÉRIO DE PAUSA:
PLANO DE ROLLBACK:
CONFIRMAÇÃO DO CLIENTE:
DECISÃO PARA A PRÓXIMA ONDA:
DATA E RESPONSÁVEL:

Plano de 90 dias para colocar a transição sob controle

Quem decide e protege a transição

Checklist antes de liberar a próxima onda

Percorra a lista antes de cada expansão, inclusive a quinta. Uma onda que passou não autoriza a seguinte, porque cada coorte traz dependências que a anterior não tinha.

Antes de convidar a coorte

• As jornadas essenciais desta coorte foram executadas no estado novo com dados equivalentes aos reais.
• As lacunas de paridade abertas têm responsável nomeado e prazo, e nenhuma delas é crítica para esta coorte.
• O tamanho da onda cabe na capacidade de atendimento declarada para o período.
• O roteiro de suporte descreve o estado novo e foi testado por pelo menos dois atendentes.
• A rota de retorno foi ensaiada com dados criados depois da virada, e o tempo dela é conhecido.
• Os guardrails têm número, dono e canal onde a pausa é anunciada.
• As exceções desta coorte estão classificadas, com dono e vigência registrados.

Durante e ao fim da onda

• A taxa de reconhecimento da comunicação atingiu o limite definido para liberar a virada.
• As cinco camadas de medição foram lidas em conjunto, e não isoladamente.
• Nenhuma conta ativa na capacidade afetada permanece sem contato reconhecido.
• Contas que voltaram ao caminho antigo foram identificadas e contatadas.
• A decisão entre expandir, repetir, reduzir ou pausar foi registrada com a evidência que a sustentou.
• Falhas encontradas viraram correção de gate, material ou produto antes da próxima onda.
• A lista nominal de contas pendentes para o encerramento do legado foi atualizada.

O que esta página não promete

A lista abaixo é a parte que você consegue cobrar. Ela existe porque um método que só descreve o que entrega deixa quem lê sem régua para separar duas coisas bem diferentes: o resultado que não veio por falha de execução e o resultado que nunca esteve no escopo. Se algum dos limites abaixo for incompatível com o que já foi prometido internamente, o melhor momento para renegociar é antes da primeira onda.

Perguntas para evoluir sem abandonar a base

Por onde começar

Referências para aprofundar

• Google SRE Workbook, capítulo 16: Canarying Releases, de Alec Warner e Štěpán Davidovič, Google e O'Reilly, 2018. Consultado em 11 de agosto de 2026. Usado aqui para a definição de canário e controle e para a proporcionalidade entre tráfego exposto e custo do defeito.
• Google SRE Workbook, capítulo 9: Incident Response, Google e O'Reilly, 2018. Consultado em 11 de agosto de 2026. Usado aqui para a separação entre comando do incidente, comunicação e operação.
• GitLab Docs: Feature Flags, documentação da versão 19.3, sem data de publicação exibida pela própria fonte. Consultado em 11 de agosto de 2026. Usado aqui para a separação entre entrega do código e liberação ao cliente e para as estratégias de exposição por percentual e por lista de usuários.
• Nielsen Norman Group: Supporting "Power Users" Isn't Enough, 3 Complex-App User Types, de 27 de junho de 2025. Consultado em 11 de agosto de 2026. Usado aqui para o perfil do usuário legado e para a recomendação de preservar a visão anterior durante a transição.