Home Assistant Migration: Old and New in Parallel

Description and use

Successfully migrated Home Assistant to a new Docker host while both instances ran in parallel. Automations were transferred without duplicate actions, entity IDs matched, KNX polling was controlled to prevent unnecessary reads, and the first shared automation behaved identically on both instances.

Problem

Migrating a Home Assistant setup from an Azure VM to a Hetzner Docker host while keeping both instances running in parallel without duplicate actions on the KNX bus.

Outcome

Successfully migrated Home Assistant to a new Docker host while both instances ran in parallel. Automations were transferred without duplicate actions, entity IDs matched, KNX polling was controlled to prevent unnecessary reads, and the first shared automation behaved identically on both instances.

Workflow

• 1. Copy 166 KNX entities to new instance, set initial_state:false for shadow mode.
• 2. Order areas by risk: energy/PV, helpers/time‑based, lights, covers, heating.
• 3. Disable automation on old instance, enable on new instance per area.
• 4. Configure KNX integration via config flow, disable state polling, set sync_state:false to avoid reads.
• 5. Attach new instance to existing Modbus cache for PV sensors.
• 6. Run small tool to match entity IDs by unique_id, rename mismatches.
• 7. Merge seven motion‑detector automations into one shared automation, adjust triggers and actions.
• 8. Copy helper values via REST API, verify identical timestamps.
• 9. Compare full state across entities, identify gaps (unknown covers, switches).

Evidence

Both instances are connected to the same KNX bus. If the same automation runs on both, every action happens twice: covers get two commands and my phone gets two push notifications.

Source

I switched per area and always in the same order. I turn the automation off on the old instance first and enable it on the new one afterwards.

Source

The new instance got the second tunnel address of the KNX interface, and the old one keeps the first.

Source

For zero read requests, every single entity needs sync_state: false, and then the states stay unknown until a telegram happens to come by.

Source

I wrote a small tool that reads the entity registry of both instances over the WebSocket API, matches entries by their unique_id and renames on the new instance.

Source

The first automation that runs on both instances writes only to helpers of its own instance and sends nothing to the bus, so two instances recording the same thing do not interfere.

Source