Two migration data-loss fixes
Both of these could silently replace your recorder configuration — including a custom database location — and cause Home Assistant to start a fresh empty database. If you have a recorder: block with anything non-default in it, update before migrating.
Migration steps could be run out of order (v0.8.37)
The three migration steps were independently clickable. Nothing stopped you from running Step 2 (Disable current recorder config) and Step 3 (Enable gui_recorder.yaml) without ever running Step 1 (Import).
Doing that replaces your entire recorder config with GUI Recorder's defaults — purge_keep_days: 10, no exclusions, no db_url — because gui_recorder.yaml is generated from storage that was never populated. If your database lives at a custom path, HA falls back to the default location and creates a new empty database, orphaning your history.
Steps 2 and 3 are now blocked until the import has run, both in the UI and server-side.
Fresh installs are unaffected — with no legacy config to import, Step 3 works as before.
Custom db_url was dropped on import (v0.8.36)
Even when you did run the import, a custom db_url (e.g. a database moved to /share) was never carried across into gui_recorder.yaml, so the same fresh-empty-database outcome applied.
Migration now captures db_url from your legacy config and writes it to gui_recorder.yaml. The migration summary shows the detected value, and the import confirmation notes that it was preserved.
If you already migrated on an earlier version, your stored config has no db_url. Either re-import with the legacy recorder: block active, or add db_url: back to configuration.yaml by hand alongside the !include. Existing installs without a custom db_url are unaffected — nothing is written.
Thanks to Frank_Beetz on the community forum for the report that led to both fixes.