Como migrar uma instalação para tags novas?
Se as tags guardam um endereço de redirecionamento que você controla, a migração é uma troca física com uma atualização no servidor e nada mais. Se elas guardam destinos diretos, cada tag tem de ser regravada uma a uma, o que equivale a um levantamento do parque inteiro.
Dois trabalhos muito diferentes
A mesma tarefa, trocar um parque de tags envelhecido, custa somas muito diferentes conforme uma decisão tomada quando a instalação foi montada.
Tags que guardam um endereço de redirecionamento no seu próprio domínio: uma troca física, mais o mapeamento dos novos identificadores, mais uma atualização no servidor. Tags que guardam destinos finais: ler cada tag antiga para saber o que ela guardava, gravar isso numa tag nova, e aplicá-la, uma por vez.
Ninguém pensa nisso na hora de escolher entre as duas, e a migração é quando a conta chega.
Migrar uma instalação com redirecionamento
Grave as tags novas numa bancada, cada uma com o identificador dela, verificadas como lote. Isso é uma tiragem de produção comum e acontece em ambiente fechado.
Troque-as em campo, anotando qual identificador novo substituiu qual antigo à medida que avança. Esse registro é a migração.
Depois aponte os novos identificadores para os destinos que os antigos serviam, o que é uma operação de dados e não uma operação física. Mantenha os identificadores antigos funcionando até ter confiança, já que uma tag esquecida em campo vai continuar funcionando.
Migrar uma instalação com destinos diretos
Cada tag tem de ser lida onde está, porque só a tag sabe o que ela guarda.
Isso transforma a migração num levantamento: visitar, ler, anotar, depois gravar uma substituta e aplicá-la. Duas visitas, a menos que você leve tags virgens e um celular e faça tudo numa só, o que é mais lento por tag e evita uma segunda viagem.
As tags que estão falhando são o problema. Uma tag danificada demais para ser lida leva o conteúdo dela junto, e sem um registro você fica reconstruindo pelo contexto.
Este é o momento de passar para redirecionamentos em vez de repetir o erro. Gravar as tags novas com endereços de redirecionamento transforma a próxima migração na versão fácil.
O período de convivência
Planeje para as duas gerações estarem no ar ao mesmo tempo, porque uma migração nunca é instantânea e alguma tag vai ser esquecida.
Mantenha os identificadores antigos resolvendo durante todo o processo, e por um bom tempo depois. Não custa nada deixar um redirecionamento no lugar e custa caro uma tag esquecida ficar morta.
Acompanhe a conclusão por local e não por contagem. Uma contagem diz quantas você fez, e só uma lista diz qual você não fez.
E mantenha as tags retiradas fora de circulação. Uma gaveta de tags antigas com conteúdo válido é exatamente o tipo de coisa que reaparece numa parede dois anos depois.
Perguntas frequentes
Por que migrar se as tags ainda funcionam?
Cola envelhecendo, desgaste físico, um chip saindo de linha, ou a necessidade de um recurso que as tags antigas não têm, como o espelhamento. Funcionar hoje não quer dizer estar disponível para reposição amanhã.
Dá para migrar aos poucos?
Dá, e em geral é a abordagem sensata. As duas gerações resolvem pelo mesmo servidor, então uma migração parcial é um estado normal e não um estado quebrado.
E se as tags antigas estiverem bloqueadas?
Tags bloqueadas ainda podem ser lidas, então o conteúdo delas é recuperável. Elas simplesmente não podem ser reaproveitadas, o que só importa se esse era o plano.
Por quanto tempo os identificadores antigos devem continuar funcionando?
Indefinidamente, na prática. Um redirecionamento não custa nada para ficar no lugar e tirá-lo só cria a possibilidade de quebrar uma tag de que você se esqueceu.