How do you replace a damaged tag without changing anything else?
Read the failing tag before it stops answering entirely, because a tag that reads intermittently today may read not at all tomorrow. Write the same content to a matching replacement, register the new identifier wherever the old one was known, and update the record.
Read it while you still can
A failing tag is usually failing progressively: it reads at the third attempt, then the tenth, then not at all. The window between noticing and losing it is the only chance to recover what it holds.
Take the read as soon as you notice, before doing anything else. Export the content and note the chip, the tag type and the identifier.
People routinely spend that window trying to make the old tag work again, and end up with a dead tag and no content.
Matching the replacement
Same tag type where possible, since platform behaviour follows the type rather than the chip. Same or larger free space, checked rather than assumed.
And appropriate to the surface. A tag that failed because it was on metal will be replaced by another tag that fails on metal unless the replacement is designed for it. Replacing like for like repeats the fault.
That last point is worth pausing on. A damaged tag is evidence about its environment, and treating the replacement as a pure swap ignores what the failure told you.
The identifier changes, and something knows
The new tag has a different identifier, and anything keyed on the old one will not recognise it.
Check three places: automations triggered by that specific tag, access or asset systems holding a list, and any server logic expecting a mirrored identifier. Register the new value in each.
Then remove the old entry, so a recovered original cannot come back into service unnoticed.
When the old tag is already dead
Your record is the only source, which is the entire reason for keeping one.
If the record exists, the replacement is straightforward: look up what that identifier held, write it, register the new tag. If it does not, you are reconstructing from context, from server logs showing what that identifier used to serve, or from an identical tag elsewhere in the deployment.
If none of those exist, the content is gone. That is the moment the value of a five minute record built during installation becomes obvious, and it is always too late.
Frequently asked questions
Can I recover content from a physically broken tag?
If the antenna is broken, no, since nothing can power the chip. The content is intact and unreachable, which amounts to the same thing.
Should the replacement be the same chip?
The same tag type matters more than the same chip, since platform behaviour follows the type. Matching both is simplest when the tags are still available.
What if I cannot find the same tag any more?
Choose a replacement of the same tag type with at least as much free space, then verify the behaviour on the devices that matter rather than assuming equivalence.
Do I need to change anything on the server?
If the system keys on identifiers, yes, and forgetting is the most common reason a correct replacement does not work. Register the new identifier and remove the old one.