MPG v2 migration stuck: "standby is ready" but promote fails with "couldn't find the prepared v2 standby"

Cluster: word-phx-17-mpg (ID: nvwq9ozp3de03kl1), org: vincent-lin, region: nrt, basic plan, PG 16.

Timeline (2026-08-24):

  1. Clicked “Prepare v2 standby” (manual cutover mode)
  2. Clicked “Promote to MPG v2” → error toast: “We couldn’t find the prepared v2 standby. Please prepare it again.”
  3. Refreshed — step 1 shows as complete, page says “Your v2 standby is ready”
  4. Clicked “Review cutover” → “Promote to MPG v2” again → same error

The migration page claims the standby is synchronized and ready, but the promote action can’t find it. Seems like stuck migration state on your side. Could you reset the migration state so I can re-prepare, or complete the migration from your end?

The v1 cluster itself is healthy and serving traffic normally.

Hi, we fixed a couple of wrinkles around migrations very recently, can you please try again? Let me know if it works better now.

Thanks — whatever you fixed worked. I retried this morning (2026-08-25 ~02:28 UTC) and the promotion completed; the cluster is now on v2 (w8675081g6nr3pk4) and healthy.

However, two issues at cutover caused a ~15 min production outage, despite the migration page stating “Fly-provided Direct and PgBouncer hostnames remain valid”:

  1. The old v1 pgbouncer hostname went NXDOMAIN at promotion. My app’s DATABASE_URL pointed at pgbouncer.nvwq9ozp3de03kl1.flympg.net (set when I attached the v1 cluster). Right after promotion it stopped resolving (tcp connect ...: non-existing domain), and the new v2 cluster showed “no attached apps” — the attachment did not carry over. I had to manually update the app’s DATABASE_URL secret to the new hostname to restore connectivity.

  2. The default cluster URI points at fly-db, but my app’s data lives in a database named after the app (word_phx_17). My original DATABASE_URL pointed at /word_phx_17. When I switched to the new cluster’s provided pgbouncer_uri (ending in /fly-db), the app connected but every query failed with undefined_table errors until I edited the URI path to /word_phx_17. It would help if attach preserved the previous database name or prompted for one.

All good now — data verified intact, background jobs back online. Thanks for the quick fix on the standby issue.


I also am having problems with the v2 migration,

One of my projects migrated successfully with no problems within a few hours.

The other one is giving me grief. First time it got stuck saying cutover in progress for maybe 2 days, then eventually said it failed and everything was still v1. I tried again yesterday, and as of right now, it’s stuck in the same way. I’m not really sure how to figure out whats going on under the hood other than the dashboard, or how to reach support, help would be appreciated.

I don’t know if this one is having problems because the one managed pg cluster has 2 dbs, one for my staging and one for prod, (project still in dev with no users so I’m not too worried) and the staging server was suspended. When I tried to revive it by pushing new updates of mine, thinking maybe it needed to be awake for the v2 migration to finish, the deploy failed as it couldn’t connect, with missing domain issue non-existing domain - :nxdomain

so the v2 migration seems stuck again and I can’t deploy updates either while its in this state. Also if i click on the databases tab for the cluster the fly dashboard crashes with a 500 error fail to load resources

Wasn’t sure how to reach support so thought I’d just post here, I’m pretty new to much of this so forgive me, I can share more specific details but I’m not sure which are the important ones for debugging something like this

Some of the docs say that MPG pricing is inclusive of:

Fly.io Support Portal to log tickets and get help

See linky:

I suppose that could mean here though :zany_face:

ah you are right! just sent a ticket