Comment migrer un déploiement vers de nouveaux tags ?
Si les tags portent une adresse de redirection que vous contrôlez, la migration est un échange physique assorti d'une mise à jour serveur, et rien d'autre. S'ils portent directement les destinations, chaque tag doit être réécrit individuellement, ce qui revient à réinventorier tout le parc.
Deux chantiers très différents
La même tâche, remplacer un parc de tags vieillissant, coûte des montants radicalement différents selon une décision prise au moment où le déploiement a été bâti.
Des tags qui portent une adresse de redirection sur votre propre domaine : un échange physique, plus la mise en correspondance des nouveaux identifiants, plus une mise à jour serveur. Des tags qui portent les destinations finales : lire chaque ancien tag pour apprendre ce qu'il portait, l'écrire sur un tag neuf, et le poser, un par un.
Personne n'y songe au moment de choisir entre les deux, et la migration est le moment où la facture arrive.
Migrer un déploiement à redirection
Écrivez les nouveaux tags sur un établi, chacun avec son identifiant, vérifiés en lot. C'est une série de production ordinaire et elle se déroule à l'intérieur.
Échangez-les sur le terrain, en relevant au fur et à mesure quel nouvel identifiant a remplacé lequel. Ce relevé est la migration.
Repointez ensuite les nouveaux identifiants vers les destinations que servaient les anciens, ce qui est une opération de données plutôt que physique. Gardez les anciens identifiants en service jusqu'à ce que vous soyez sûr, un tag manqué sur le terrain continuant alors de fonctionner.
Migrer un déploiement direct
Chaque tag doit être lu là où il se trouve, parce que seul le tag sait ce qu'il porte.
Cela transforme la migration en inventaire : se déplacer, lire, noter, puis écrire un remplaçant et le poser. Deux passages, sauf à emporter des tags vierges et un téléphone pour tout faire en un, ce qui est plus lent par tag et évite un second déplacement.
Les tags défaillants sont le problème. Un tag trop abîmé pour être lu emporte son contenu avec lui, et s'il n'y a pas de relevé vous reconstituez à partir du contexte.
C'est le moment de passer aux redirections plutôt que de répéter l'erreur. Écrire les nouveaux tags avec des adresses de redirection transforme la migration suivante en version facile.
La période de recouvrement
Prévoyez que les deux générations soient en service en même temps, une migration n'étant jamais instantanée et un tag étant toujours manqué.
Gardez les anciens identifiants résolvables pendant toute la durée, et un bon moment après. Laisser une redirection en place ne coûte rien et un tag manqué qui devient mort coûte réellement.
Suivez l'avancement par emplacement plutôt que par compte. Un compte vous dit combien vous en avez faits, et seule une liste vous dit lequel vous n'avez pas fait.
Et gardez les tags retirés hors circulation. Un tiroir d'anciens tags au contenu valide est exactement le genre de chose qui réapparaît sur un mur deux ans plus tard.
Questions fréquentes
Pourquoi migrer si les tags fonctionnent encore ?
Adhésif qui vieillit, usure physique, puce qui sort de production, ou besoin d'une fonction dont les anciens tags sont dépourvus, comme le miroir. Fonctionner aujourd'hui ne veut pas dire être disponible en remplacement demain.
Peut-on migrer progressivement ?
Oui, et c'est d'ordinaire l'approche sensée. Les deux générations se résolvent par le même serveur : une migration partielle est un état normal plutôt qu'un état cassé.
Et si les anciens tags sont verrouillés ?
Les tags verrouillés se lisent encore : leur contenu est récupérable. Ils ne peuvent simplement pas être réemployés, ce qui ne compte que si vous y comptiez.
Combien de temps garder les anciens identifiants en service ?
Indéfiniment, en pratique. Une redirection ne coûte rien à laisser en place et en retirer une ne crée que la possibilité de casser un tag que vous aviez oublié.