Changing an entity ID in Home Assistant has always been heavier than it looks. Behind the scenes the entity was removed and added again under the new ID, and its whole setup ran a second time. From Home Assistant Core 2026.11 that stops: the entity is updated in place. Erik Montnemery announced the change on the Home Assistant developer blog on 12 October 2026.
What happens now when you rename
In 2026.11, Home Assistant removes the state stored under the old ID, switches the entity to the new one, moves its own bookkeeping and writes the state under the new ID. The bookkeeping includes the entity and device registry tracking, entity sources, restored state and entity groups. The async_will_remove_from_hass and async_added_to_hass hooks no longer run, so the integration does not tear down and rebuild the entity just because you gave it a better ID.
A related change from an earlier post on the same blog (6 October) points the same way. From 2026.11, states saved by the restore state helper are indexed by the entity's registry ID, not by its entity ID. A restored state follows the entity after a rename and is never restored to a different entity that happens to reuse the old ID.
What integration developers have to do
Core integrations always use the new behavior. Custom integrations, including those you install through HACS, get a transition period. If a custom integration's own classes implement async_prepare_to_add_to_hass, async_added_to_hass or async_will_remove_from_hass, its entities are still removed and added again on rename until the author adds the new async_entity_id_changed callback. That callback runs after the switch, with the old ID passed in, and is the place to update anything keyed on the entity's own ID, such as state listeners or dispatcher signals. If nothing needs updating, a method that only calls super() is enough to opt in. The compatibility path will be removed in Core 2027.11.
The same post introduces a second hook, async_prepare_to_add_to_hass, available since 2026.10. It runs before the entity platform processes the registry entry, even for adds that will be aborted (for example when the entity is disabled), and it replaces overriding add_to_platform_start, which was never meant to be overridden.
What it means for users
For most people, renaming entities should simply get cheaper and safer, with fewer side effects: no needless teardown and rebuild, and restored state that stays with the entity. If you rely on custom integrations, the transition period protects you: until their authors opt in, those integrations keep the old remove-and-add behavior. If a custom integration misbehaves after a rename, especially once the compatibility path goes away in 2027.11, its issue tracker is the first place to look.