Mudança, migração e clientes legados

Por que o cliente antigo trava numa melhoria?

Porque ele avalia a mudança pela continuidade do trabalho dele. Você enxerga a novidade. Ele enxerga o esforço de reaprender e o risco de parar uma operação que rodava sozinha.

Antes do plano existe um erro de leitura que contamina tudo: tratar cliente antigo como cliente avançado. Um estudo do Nielsen Norman Group descreve o usuário legado como quem usa o software há anos sem ter ficado eficiente. Familiaridade nem sempre é domínio.

A hesitação desse cliente nasce da produtividade, antes da teimosia. Ele avisa que o trabalho dele não pode parar, e isso se responde com janela combinada e ensaio.

Com o rótulo de experiente, o cronograma supõe autonomia onde existe rotina decorada, e o material de ajuda sai escrito para quem entende o produto por dentro. A conta chega no suporte, e chega concentrada.

Some a isso uma segunda distância. Quem constrói a mudança subestima o custo de sair do estado antigo, e quem usa superestima o risco de entrar no novo. O seu time calcula pela dificuldade técnica da virada, e o cliente calcula pelo tempo de reconstruir confiança.

Toda plataforma acumula ainda dependências que ninguém projetou. Alguém montou um relatório em cima do formato de exportação, outra pessoa criou uma automação presa à ordem de um campo, um time decorou um atalho.

Nada disso está no roadmap, porque nada disso foi pedido. Aparece no primeiro dia da migração, em forma de chamado. Achar antes custa alguns dias de duas pessoas, uma vez só, na data que você escolhe.

Achar depois custa chamados amontoados na primeira semana, mais a conversa de recuperação. A primeira conta você paga uma vez. A segunda volta a cada onda.

Mudança segura junta valor novo com proteção do que já existe. Declare o que muda, o que fica igual, quem entra em cada etapa e quando a versão antiga sai do ar. Avisar reduz susto, e só. Reduzir risco exige testar em contas reais antes de liberar para todos.

Como separar a sua base em grupos de uso?

Separe por uso. Coorte, aqui, é o grupo de contas que usa a plataforma do mesmo jeito. Duas contas antigas podem depender de coisas diferentes, e uma conta nova pode chegar com integração crítica no primeiro dia.

Cruze estágio, volume, integrações, criticidade e necessidade de acompanhamento. Cinco grupos costumam dar conta da maioria das bases.

O grupo diz onde a conta entra na fila. Ele ainda não responde a pergunta que chega na sua mesa todo dia, conta por conta.

Migrar esta conta agora ou deixar onde está?

Decida por quatro provas, uma de cada vez. A pergunta erra por dois lados, e cada erro cobra numa moeda diferente.

Migrar cedo demais entrega ao cliente um produto que ainda não faz o trabalho dele, e a conta chega em chamados. Adiar sem critério cria uma segunda plataforma que ninguém encerra, com manutenção todo mês e cada mudança futura testada duas vezes.

A primeira conta dói rápido. A segunda entra no orçamento como se fosse normal, e sai mais cara.

Avalie cada eixo com prova observável, em vez do achismo de quem atende a conta.

As quatro saídas possíveis aparecem na tabela abaixo, cada uma com a leitura de eixos que a seleciona e a forma de executá-la.

O eixo de custo infla sozinho conforme a pressão interna aumenta. Ele só entra na decisão quando alguém nomeia as horas, os times envolvidos e o que deixou de ser feito. Sem essas linhas, o argumento de custo empurra contas despreparadas para a migração.

Grandfathering, ou manter a condição antiga. Manter para sempre faz sentido em três condições juntas. A promessa foi escrita na contratação, o custo de honrá-la é conhecido e a exceção não trava o produto para o resto da base. Manter por um prazo faz sentido quando existe dependência comprovada com data de correção.

Fora desses dois casos, o que existe costuma ser decisão adiada com cara de política. Quatro tipos de exceção cobrem o que aparece no dia a dia.

Toda exceção criada vira uma variante que alguém precisa testar em cada mudança futura. Dez exceções vivas custam dez testes por mudança, para sempre, pagos por um time que não participou de nenhuma das dez decisões.

Se a sua lista de exceções só cresce, a exceção virou substituta da decisão.

Critério de pronto: a decisão está tomada quando existem por escrito, conta a conta, quatro coisas. O eixo que a definiu, a saída escolhida, o responsável dos dois lados e a data de revisão.

O que significa continuar funcionando igual?

Significa que a pessoa termina o mesmo trabalho, mantém os dados, mantém os controles e consegue se recuperar de uma falha no jeito novo. É isso que a palavra paridade quer dizer aqui.

Na agência do começo, paridade é a garantia de que os quarenta clientes continuam entregando o que entregavam ontem. Comparar listas de recursos deixa você declarar empate enquanto uma rotina importante segue quebrada.

Quatro perguntas resolvem a conversa de paridade com qualquer time, e valem tanto para o produto quanto para o atendimento.

• As rotinas principais de cada grupo estão listadas.
• Alguém confere dados e histórico antes e depois da virada.
• As diferenças aparecem escritas na língua do cliente.
• Direitos, condições e exceções têm regra e vigência.
• A regra para desligar a versão antiga ficou combinada antes de avisar alguém.

Para quem liberar primeiro, e quando ampliar?

Libere em cinco fases, e só passe para a próxima quando a anterior entregar uma prova. O desenho copia a liberação canário do manual de engenharia do Google. Um grupo pequeno recebe a mudança, o resto fica como controle, e os dois são comparados antes de seguir.

O mesmo capítulo desfaz um engano comum. Achar e desfazer o problema levam quase o mesmo tempo com ou sem grupo pequeno. O que o grupo pequeno compra é o tamanho do estrago, que acompanha o número de contas expostas ao defeito.

Uma falha em 60 contas e uma em 1.150 consomem o mesmo tempo de diagnóstico. O que muda é quanto trabalho alheio já quebrou quando ele termina. Por isso o tamanho da onda é decisão de risco, antes de virar escolha de calendário.

Separe a entrega do código da liberação ao cliente, por percentual ou por lista de contas. É esse mecanismo que deixa parar uma onda sem desfazer a entrega inteira.

O que dizer ao cliente, e em que ordem?

Comece pela consequência para ele, e só depois pelo motivo. Uma mensagem útil diz o que vai acontecer, quando chega àquela conta, o que ele precisa fazer, o que fica igual, onde testar e como pedir ajuda.

Avisar cedo sem essas respostas só antecipa o susto. Pelo WhatsApp, o aviso passa pela API (a porta por onde dois sistemas trocam informação sozinhos). O custo aparece antes do envio.

A tabela da Meta em reais cobra R$ 0,0350 por mensagem de utilidade entregue e R$ 0,3217 por mensagem de marketing. Aviso de mudança é utilidade. Marcar como marketing por precaução multiplica a fatura por dez sem melhorar nada.

Cinco momentos cobrem a conversa inteira, do primeiro aviso ao desligamento da versão antiga, com a prova de que o cliente entendeu cada um.

A capacidade de atendimento também é um portão. Estime contatos por grupo, motivos prováveis, tempo de tratamento e quem está disponível. Se a onda passa da capacidade de resposta, reduza o lote antes de empurrar 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 atendimento, contra as horas livres no dia. O que passa disso vira fila, e quem espera na fila é o cliente que você acabou de convidar.

Quais números você acompanha durante a virada?

Cinco camadas, no mesmo painel, lidas juntas. Cada uma tem um limite escrito, o guardrail, que é o número que interrompe a expansão sem precisar de reunião.

Cada par de camadas conta uma história que nenhuma delas conta sozinha. Adoção alta com suporte estourado descreve uma migração paga pelo atendimento. Suporte tranquilo com paridade baixa descreve contas que desistiram caladas.

Esse segundo caso só aparece quando você compara o uso da versão antiga com a lista de contas que constam como migradas. O silêncio é o sinal mais caro do painel, porque de longe ele se parece com sucesso.

Como o método funciona num caso completo?

E se a virada der errado no dia?

Você conserta, explica e repara na medida do estrago, nessa ordem. Diga quem foi afetado, o que está sendo feito, a que horas sai a próxima notícia e qual saída existe até lá.

Depois confirme a volta, guarde o histórico e registre a prevenção. O manual de engenharia do Google separa três papéis nessa hora: quem comanda, quem fala com o cliente e quem opera. A mesma pessoa não diagnostica e responde ao mesmo tempo sem atrasar as duas coisas.

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

Que erros aparecem sempre, e como vê-los cedo?

Seis erros se repetem, e nenhum deles nasce de descuido. Todos mandam um sinal cedo que passa batido porque parece boa notícia. A pergunta de detecção existe para pegar cada sinal antes da próxima onda, quando mudar de ideia ainda sai barato.

Em que ordem executar cada passo?

Nesta, porque cada passo produz o que o seguinte consome. Dimensionar o suporte define o tamanho da onda. Escolher o tamanho da onda antes de conhecer a capacidade de atendimento gera um cronograma que a operação não cumpre.

1. Liste as rotinas antes de olhar o cronograma. Anote o que o cliente termina usando o que vai mudar, inclusive o que ninguém pediu e virou costume. Pergunte ao suporte: as dependências escondidas aparecem no histórico de chamados antes de qualquer outro lugar. Saída: lista de rotinas, com quem executa cada uma e com que frequência.

2. Monte os grupos pelo jeito de usar a plataforma. Cruze estágio, volume, integrações, criticidade e necessidade de acompanhamento. A data de contratação explica o que foi prometido, e para por aí. Saída: quadro de grupos com regra de entrada que se confere por consulta.

3. Teste a paridade com dados reais, sob autorização. Rode cada rotina principal no jeito novo. Registre o que passa, o que passa com esforço extra e o que não passa. As falhas de dado e de histórico concentram as descobertas. Saída: paridade por rotina e por grupo, com responsável por cada falha aberta.

4. Dimensione o suporte e tire dali o tamanho da onda. Estime contatos por conta migrada, motivos prováveis, tempo de atendimento e horas livres por dia. O tamanho máximo da onda sai pronto dessa conta, e o calendário apenas recebe. Saída: capacidade diária, tamanho máximo de onda e roteiro de atendimento novo.

5. Ensaie a rota de volta e publique os limites antes de convidar alguém. Reverta com dados criados depois da virada e cronometre. Separe o que volta, o que volta com perda e o que não volta.

   Depois defina, em cada camada de medição, o valor que interrompe a expansão. Limite escrito depois do primeiro problema se acomoda ao resultado e perde a função. Saída: rota de volta cronometrada, perdas declaradas e limites por camada, com dono da pausa.

6. Rode a onda, leia as cinco camadas juntas e decida. Ao fim de cada onda, escolha entre ampliar, repetir o tamanho, reduzir ou pausar. Registre a decisão com a prova que a sustentou, porque ela vai ser revista na onda seguinte. Saída: decisão registrada por onda, com data, responsável e prova.

7. Feche o legado por lista com nome e dono por linha. O desligamento acontece quando a lista de contas e rotinas pendentes chega a zero, ou a exceções com dono e prazo. Guarde o histórico e avise a data final em cada canal combinado. Saída: encerramento registrado, com lista final e exceções vivas.

Critério de pronto: qualquer pessoa do time responde sozinha três perguntas. Quantas contas já migraram, qual limite está mais perto de estourar e quem decide a próxima onda. Se as três dependem de você, o controle é a sua memória.

Qual folha você preenche antes de marcar a data?

Esta. Uma folha por grupo de clientes, preenchida antes do cronograma. Onde faltar dado, escreva PENDENTE em vez de supor.

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:

O que fazer em cada mês dos primeiros 90 dias?

Quem responde por cada parte da transição?

O que conferir antes de liberar a próxima onda?

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

• As rotinas principais deste grupo rodaram no jeito novo com dados equivalentes aos reais.
• Cada falha de paridade aberta tem responsável e prazo, e nenhuma é crítica para este grupo.
• O tamanho da onda cabe na capacidade de atendimento do período, e o roteiro de suporte já descreve o jeito novo.
• A rota de volta foi ensaiada com dados criados depois da virada, e o tempo dela é conhecido.
• Os limites de pausa têm número, dono e canal de anúncio, e as exceções deste grupo têm tipo e prazo.
• Ao fim da onda, as cinco camadas foram lidas juntas e nenhuma conta ativa ficou sem contato reconhecido.
• A decisão de ampliar, repetir, reduzir ou pausar ficou registrada, com a lista de contas pendentes atualizada.

O que esta página não resolve?

Seis coisas. A lista separa o resultado que faltou por execução do resultado que nunca esteve aqui. Se algum limite bater de frente com uma promessa já feita na empresa, renegocie antes da primeira onda.

Perguntas que sempre aparecem na reunião

O que fazer hoje, antes de fechar a aba?

Duas coisas, na ordem: uma busca de dois minutos e uma folha de quarenta. A primeira dá a primeira linha da sua lista de rotinas. A segunda destrava o cronograma.

Onde ler mais sobre cada peça

• Google SRE Workbook, capítulo 16: Canarying Releases, de Alec Warner e Štěpán Davidovič, Google e O'Reilly, 2018. Origem da liberação para um grupo pequeno com controle.
• Google SRE Workbook, capítulo 9: Incident Response, Google e O'Reilly, 2018. Origem da separação entre comando, comunicação e operação numa falha.
• GitLab Docs: Feature Flags, documentação da versão 19.3. Origem da separação entre entregar o código e liberar ao cliente.
• Nielsen Norman Group: Supporting "Power Users" Isn't Enough, 3 Complex-App User Types, de 27 de junho de 2025. Origem do perfil do usuário legado e da hesitação por produtividade.