How do you migrate a deployment to new tags?
If the tags hold a redirect address you control, the migration is a physical swap with a server update and nothing else. If they hold destinations directly, every tag has to be rewritten individually, which is a re-survey of the entire estate.
Two very different jobs
The same task, replacing an aging estate of tags, costs wildly different amounts depending on a decision taken when the deployment was built.
Tags holding a redirect address on your own domain: a physical swap, plus mapping the new identifiers, plus a server update. Tags holding final destinations: reading each old tag to learn what it held, writing that to a new tag, and applying it, one at a time.
Nobody thinks about this when choosing between the two, and the migration is when the bill arrives.
Migrating a redirect deployment
Write the new tags on a bench, each with its own identifier, verified as a batch. This is a normal production run and it happens indoors.
Swap them in the field, recording which new identifier replaced which old one as you go. That record is the migration.
Then repoint the new identifiers to the destinations the old ones served, which is a data operation rather than a physical one. Keep the old identifiers working until you are confident, since a tag missed in the field will still function.
Migrating a direct deployment
Every tag has to be read where it is, because only the tag knows what it holds.
That turns the migration into a survey: visit, read, note, then write a replacement and apply it. Two visits unless you carry blank tags and a phone and do it in one, which is slower per tag and avoids a second trip.
The failing tags are the problem. A tag too damaged to read takes its content with it, and if there is no record you are reconstructing from context.
This is the moment to switch to redirects rather than repeating the mistake. Writing the new tags with redirect addresses turns the next migration into the easy version.
The overlap period
Plan for both generations to be live at once, because a migration is never instantaneous and a tag will be missed.
Keep the old identifiers resolving throughout, and for a good while afterwards. There is no cost to leaving a redirect in place and a real cost to a missed tag going dead.
Track completion by location rather than by count. A count tells you how many you did, and only a list tells you which one you did not.
And keep the removed tags out of circulation. A drawer of old tags with valid content is exactly the sort of thing that reappears on a wall two years later.
Frequently asked questions
Why migrate at all if the tags still work?
Aging adhesive, physical wear, a chip going out of production, or a need for a feature the old tags lack such as mirroring. Working today does not mean available for replacement tomorrow.
Can I migrate gradually?
Yes, and it is usually the sensible approach. Both generations resolve through the same server, so a partial migration is a normal state rather than a broken one.
What if the old tags are locked?
Locked tags can still be read, so their content is recoverable. They simply cannot be reused, which matters only if you were planning to.
How long should old identifiers keep working?
Indefinitely, in practice. A redirect costs nothing to leave in place and removing one only creates the possibility of breaking a tag you forgot about.