# Como migrar de encurtador de ligações sem quebrar campanhas

> Planeie inventário, exportação, coexistência, DNS, API, analytics, monitorização e rollback para migrar ligações com segurança.

Canonical: https://abreai.com/pt-pt/blog/migrar-encurtador-de-link

## Como migrar de encurtador sem quebrar campanhas

Comece pelo inventário, não pela troca de DNS. Exporte links, destinos, slugs, títulos, UTMs, responsáveis, volume e materiais associados. Classifique o que utiliza o domínio próprio e o que depende do domínio do fornecedor. Os links em domínio partilhado normalmente não podem ser portados com o mesmo endereço; os links num domínio controlado pela empresa podem migrar por DNS, desde que a nova plataforma aceite a configuração. Faça ondas, monitorize e mantenha rollback.

Uma migração bem-sucedida preserva o acesso, a medição, a reputação e o contexto. O objetivo não é apenas recriar slugs, mas garantir que os QR Codes, e-mails, anúncios, documentos e integrações continuam a conduzir ao destino correto.

## Porque é que as migrações falham

Falham quando a equipa descobre tarde que não sabe onde os links foram publicados. Falham quando a exportação omite o destino completo ou os UTMs. Falham quando um domínio é alterado sem reduzir o TTL. Falham quando os links antigos são removidos antes de o tráfego terminar. E falham quando o analytics histórico é confundido com continuidade do endereço.

Trate os links como infraestrutura. Cada um pode ter dependências físicas e digitais. Um slug aparentemente sem cliques recentes pode estar impresso numa embalagem de longa validade.

## Domínio partilhado versus domínio próprio

Se o link for `fornecedor.com/campanha`, o domínio pertence ao fornecedor. Ao mudar de serviço, não controla a rota e provavelmente terá de publicar um novo endereço. O fornecedor antigo precisa de continuar ativo enquanto houver tráfego.

Se o link utilizar `go.suaempresa.com/campanha`, a empresa controla o DNS. É possível apontar o subdomínio para outro fornecedor, desde que sejam importados antes os slugs e as configurações. Existem ainda riscos: certificado, TTL, cache, propagação, diferenças de casos e comportamento dos redirects.

O domínio próprio melhora a portabilidade, mas aumenta a responsabilidade. Renove, proteja a conta do registrador e documente o DNS. Um domínio expirado pode comprometer todos os materiais.

## Passo 1: inventário completo

Reúna:

- slug e URL curto;
- destino completo;
- parâmetros UTM;
- estado ativo ou em pausa;
- título interno;
- data de criação;
- responsável e área;
- cliques e último acesso;
- QR Codes e ficheiros;
- canais onde foi publicado;
- domínio e certificado;
- integrações que criam ou consultam o link.

Não confie apenas no painel. Pesquise CMS, CRM, automatizações, anúncios, perfis sociais, e-mails, PDFs, packaging e apresentações. Fale com marketing, suporte, vendas e produto.

## Etapa 2: classificação da criticidade

Classifique como crítico, importante, substituível ou expirado. Criticidade considera impacto, não só cliques. Um QR de instruções de segurança pode ter pouco volume e uma importância elevada. Um anúncio antigo pode ter muitos bots e não ter valor.

Assinale materiais impossíveis de editar, como a embalagem distribuída. Estes links requerem manutenção longa no fornecedor anterior quando não existe um domínio próprio.

Defina proprietário e decisão para cada item: migrar, manter temporariamente, redirecionar para conteúdo perene ou terminar com página informativa.

## Passo 3: requisitos do destino novo

Confirme a importação, API, slugs, caracteres aceites, case sensitivity, custom domain, QR, analytics, users e rate limits. Teste colisões. Um slug reservado no novo serviço pode impedir a paridade.

No AbreAí.com, os slugs são normalizados e as rotas do sistema ficam reservadas. Os destinos passam por validação. Para volume via API PRO, planeie a paginação, limites e tokens separados por ambiente.

Não prometa a migração 1:1 antes de executar uma amostra com casos difíceis: query longa, fragmento, Unicode, destino temporário, link pausado e slug próximo de rota interna.

## Etapa 4: exportação e saneamento

Preserve um ficheiro original imutável e crie uma cópia de trabalho. Valide URLs, remova espaços invisíveis, detete duplicados e identifique destinos quebrados. Não “corrija” automaticamente sem registar.

Procure dados pessoais em slugs e UTMs. A migração é oportunidade para reduzir exposição, mas mudar um link público exige plano. Para novos endereços, substitua PII por identificadores de campanha.

Normalize os títulos internos e responsáveis. Um catálogo limpo melhora a procura e o suporte depois.

## Passo 5: arquitetura de coexistência

Raramente é seguro desligar o antigo no mesmo dia. Defina período de coexistência. Novas campanhas nascem no serviço novo; links antigos continuam a responder. Migre os que usam o domínio próprio e atualize os ativos editáveis.

Se houver um custo duplo, trate-o como um seguro de transição. O valor de manter redirects é normalmente inferior a perder tráfego de material impresso ou e-mails já enviados.

Defina data de revisão, não apenas data de cessação. Decisão deve usar tráfego residual e criticidade.

## Etapa 6: piloto

Escolha um grupo representativo, e não apenas links fáceis. Inclua tráfego elevado, QR, UTM, destino com query e integração. Importe ou recrie. Compare as respostas HTTP, Location, tempo e analytics.

Teste em browsers, apps e redes. Verifique que parâmetros chegam. Utilize monitor externo e registe baseline do fornecedor antigo.

O piloto deve durar o tempo suficiente para observar uma utilização real. Recolha feedback dos operadores sobre a pesquisa, títulos, filtros e permissões.

## Passo 7: DNS para domínio próprio

Dias antes, reduza TTL de forma planeada. Confirme registos exigidos pelo novo fornecedor e emissão de certificado. Registe todos os slugs antes de apontar DNS. Faça o backup da zona.

Na janela, altere apenas registos necessários. Monitorize a resolução autoritativa e pública, IPv4 e IPv6. Valide HTTPS, cadeia de certificados, host e redirect. Mantenha o rollback explícito.

Depois da estabilidade, ajuste o TTL para o valor operacional. Não apague configuração antiga imediatamente.

## Passo 8: integrações e tokens

Mapeie aplicações que criam ligações. Gere tokens distintos no novo serviço e guarde em cofre. Nunca reutilize chave em vários sistemas. Atualize o endpoint, a autenticação e o formato de resposta em homologação.

Implementar backoff, tratamento de 401, 403, 409, 422, 429 e 5xx. Idempotência impede duplicatas. Registe o identificador do link. Rotacione e revogue os tokens antigos após o corte.

Se a API ficar indisponível, a aplicação deve enfileirar ou permitir contingência; não deve publicar URL incorreto silenciosamente.

## Passo 9: analytics e histórico

Os dados antigos raramente combinam automaticamente com os novos. Exporte relatórios e guarde com definição de métrica, fuso e período. Marque a data de migração nos dashboards.

Não some visitantes estimados de metodologias diferentes como se fossem idênticos. Preservar histórico para referência e iniciar nova série quando necessário. As UTMs ajudam a continuidade no analytics do destino.

Crie um relatório de transição com cliques no antigo, novo e total contextualizado. Os scanners e testes devem ser identificados.

## Passo 10: atualização de ativos

Dê prioridade aos canais editáveis: site, bio, anúncios, automatizações, templates de e-mail e documentos vivos. Depois trate ficheiros distribuídos e materiais futuros. Para impresso existente, mantenha redirect antigo.

Não substitua um link sem testar no contexto. Redes sociais podem manter cache de pré-visualização. O e-mail pode reescrever URLs para segurança. Os PDF podem ter hiperligação diferente do texto visível.

Atualize o guia de marca, onboarding e snippets para impedir que novas pessoas continuem a utilizar o fornecedor antigo.

## Monitorização pós-migração

Monitorize o estado, latência, 404, 429 e 5xx. Crie lista de slugs críticos. Compare p50, p95 e p99. Verifique a cache e o banco. Os alertas devem apontar domínio e slug.

Analise os acessos ao antigo. Um link residual pode revelar ativo esquecido. Não o remova até identificar a origem ou aceitar o impacto.

Mantenha canal de suporte e modelo de incidente. Request ID, hora, rede e destino aceleram o diagnóstico.

## Evitar cadeias de redirects

Não faça antigo apontar para novo e novo para landing intermédio se puder apontar diretamente. Cada salto adiciona latência, cache e ponto de falha. Para coexistência temporária, documente e depois simplifique.

Os loops surgem quando a canonicalização e as regras de domínio se contradizem. Inspecione cada Location. Defina máximo de saltos no teste automatizado.

## Segurança durante a migração

A migração expõe ficheiros, tokens e acessos. Utilize canal seguro, menor privilégio e retenção curta. Não envie exportações por mensagem. Verifique quem pode impersonar os utilizadores e audite as ações administrativas.

Valide os destinos contra SSRF. Não importe protocolos perigosos ou endereços privados. Trate slug como entrada não fidedigna. Utilize instruções preparadas e índice único.

Proteja o DNS com MFA e bloqueio de transferência. Confirme os contactos de domínio. Um atacante no registo supera as proteções da aplicação.

## Privacidade e LGPD

Documente bases, finalidades e operadores. Se o fornecedor novo processar país, dispositivo ou eventos, atualize inventário e política quando aplicável. Evite transferir dados históricos desnecessários.

Responda à exclusão e retenção. Uma exportação de migração também é dada e necessita de um prazo para o descarte seguro. Nunca inclua credenciais ou PII em ZIP de runtime.

## Plano de rollback

Rollback define trigger, responsável, comando ou alteração DNS, tempo e validação. Guarde configuração anterior. Se a migração falhar, restaure sem improviso e preserve as provas.

Não utilize o rollback para ocultar o erro de dados. Se parte dos slugs foi importada incorretamente, corrija catálogo e reexecute com idempotência. Comunique impacto.

## Critérios de aceitação

- todos os slugs críticos respondem;
- Location corresponde ao inventário;
- As UTM chegam ao destino;
- HTTPS válido em regiões relevantes;
- latência dentro do limite;
- 404 e 5xx abaixo do objetivo;
- os tokens novos funcionam e os antigos foram revogados;
- os operadores encontram e gerem ligações;
- histórico foi arquivado;
- rollback foi testado.

## Quando encerrar o fornecedor antigo

Analise o tráfego residual, contratos e materiais. Exporte dados finais. Remova integrações, revogue tokens e utilizadores. Se o domínio é seu, mantenha o controlo. Se é partilhado, confirme consequências da eliminação.

Não encerre apenas porque a data chegou. Para ligações críticas ainda utilizadas, estenda com decisão consciente. Para links sem finalidade, ofereça página apropriada ou finalize de acordo com a política.

## Checklist executivo

1. Patrocínio e responsáveis ​​definidos.
2.º Inventário e criticidade concluídos.
3.º Requisitos e piloto aprovados.
4.º Coexistência financiada.
5.º DNS e certificado preparados.
6.º Integrações homologadas.
7. Analytics e histórico preservados.
8.º Ativos atualizados por prioridade.
9.º Monitorização e rollback ativos.
10.º Desligamento baseado em evidência.

## Ensaio de recuperação

Antes do corte, simule a perda de acesso ao fornecedor novo, erro de DNS e importação incompleta. Confirme que as credenciais antigas, cópias de segurança e instruções de rollback estão disponíveis para pessoas autorizadas. Um plano que nunca foi ensaiado depende, normalmente, de pormenores esquecidos precisamente durante o incidente.

Utilize uma amostra representativa: links muito acedidos, slugs com caracteres válidos no sistema anterior, destinos com UTM, QR Codes impressos e integrações de API. Compare o código HTTP, o destino final, os parâmetros, a latência e a contabilização. Registe a evidência automática para não depender da verificação manual de milhares de linhas.

Após o corte, mantenha uma janela de observação com alertas de 404, 410, 5xx, aumento de latência e queda anormal de cliques. Não desligue a origem ao primeiro sinal de sucesso. A coexistência planeada é um seguro temporário, desde que não crie cadeias de redireccionamento ou dados divergentes.

## Conclusão

Migrar encurtador é um projeto de continuidade, não uma simples importação. O fator decisivo é controlar o domínio ou manter a coexistência para endereços que não podem ser portados. Inventarie, classifique, pilote, monitorize e preserve o rollback. O AbreAí.com pode receber novas campanhas com personalização e gestão gratuita, e a API PRO ajuda nas migrações automatizadas; ainda assim, os materiais antigos devem ser tratados de acordo com o domínio e o fornecedor de origem.

![Arquivo de rotas a ser organizado por um braço robótico durante a migração](https://abreai.com/media/blog-inline/migracao-inventario.webp)

_Arquivo de rotas a ser organizado por um braço robótico durante a migração._

![Migração controlada de tráfego entre uma ponte antiga e uma nova com rota de retorno](https://abreai.com/media/blog-inline/migracao-monitoramento.webp)

_Migração controlada de tráfego entre uma ponte antiga e uma nova com rota de retorno._