Migration

Migrating an existing BirdNET-Pi to the Enhanced Version

If you already run BirdNET-Pi — Nachtzuster's fork or the original mcguirepr89 version — you don't need to start over. Your detections, recordings, and settings carry across. In the normal case this is three commands.

Before you begin

• Update your current installation first. Migrating from an up-to-date station is far more reliable than migrating from one that's months behind.
• Check your OS version. You need 64-bit Raspberry Pi OS, Bookworm or Trixie.
• Take that backup. Genuinely.

The normal route: your OS is already correct

SSH into your Pi, then from inside the BirdNET-Pi directory:

cd ~/BirdNET-Pi
git remote remove origin
git remote add origin https://github.com/zach7036/BirdNET-Pi-Enhanced-Version.git
./scripts/update_birdnet.sh

That repoints your installation at the Enhanced repository and runs the standard updater, which pulls the new code and applies any schema changes. Your database, audio files, and configuration stay where they are.

When it finishes, reload the web interface. You should land on the new dashboard with your full detection history already present.

The fresh-install route: upgrading from Bullseye

If you need to move to a newer OS, treat it as a new station plus a data restore:

1. On the old system, take a full backup and copy it off the Pi.
2. Image a new SD card with 64-bit Raspberry Pi OS (Trixie recommended). See the installation guide.
3. Install the Enhanced Version with the one-line installer.
4. In the new web interface, go to Settings → System Controls and restore your backup.

Restoring can take a long while — it depends on how much audio you've accumulated and how fast your storage is. Let it finish.

After migrating

Two settings are worth checking immediately, because the new features depend on them:

• Latitude and longitude — these drive species range filtering, rarity detection, and weather. If they were never set on your old station, set them now.
• Admin password — set one under Advanced Settings if you haven't.

Some of the newer pages need history to be interesting. Insights and seasonality compare against your own station's baseline, so give them a couple of weeks before judging them — though if you migrated with existing data, much of that is already available on day one.

Going back

Restore your backup. That is the supported route back to your previous fork, and it's the reason for taking one before you start.

Pointing the git remote back the other way and re-running the updater looks like it should work — the Enhanced Version only ever adds tables to the database and never alters the detections table, so your detection history itself isn't at risk. But the installation also carries configuration keys and service definitions that the older fork's updater doesn't know to clean up, and that path isn't tested. Restoring a backup onto a fresh install is the route that's known to work.