VAPID Key Backup and Restore: WordPress Migration Guide

A WordPress site migration usually goes one of two ways: either everything works and nobody thinks about it again, or something breaks in a way that’s immediately obvious — broken images, a 500 error, a theme that looks wrong. Push notifications break the third way, the quiet way. The migration finishes. The new site loads fine. Everything looks correct. And then, days or weeks later, someone notices open rates have flatlined, campaigns are going out to nobody, and there’s no error log entry anywhere explaining why — because from the server’s perspective, nothing went wrong. It just started talking to an audience that can no longer hear it.

The cause is almost always the same: the VAPID keys changed, and nobody backed up the old ones first.

What a VAPID Key Actually Is, Briefly

VAPID — Voluntary Application Server Identification — is the standard that lets a website send web push notifications directly, without routing through a third-party relay. Defined under RFC 8292, VAPID works by having the website’s backend generate and store a public and private key pair, then sign every notification it sends with the private key so the browser’s push service can verify it came from the legitimate server. When push is set up on a site, that key pair gets generated; the public key is embedded in every subscription a visitor creates when they opt in, and the private key stays on the server, used to cryptographically sign every notification sent afterward.

That signature check is exactly what makes VAPID secure, and it’s exactly what makes a key change so destructive. A subscription isn’t tied to a domain name or a WordPress install in the abstract — it’s tied to one specific key pair. Generate a new pair, and every subscription created under the old one is now signed against a private key that no longer exists on the server. The push service has no way to validate the notification, so it simply doesn’t deliver it. No bounce, no error, no notification to the site owner that anything failed.

Why a Migration Regenerates the Keys in the First Place

VAPID keys are typically generated once, automatically, the first time a push plugin activates on a fresh WordPress install — which is precisely the problem. A site migration that involves setting up a brand-new WordPress installation on the destination server, rather than a byte-for-byte file and database copy, triggers exactly that condition: the push plugin activates as if for the first time, generates a new key pair, and has no way of knowing an old one with an existing subscriber base ever existed unless the old keys are explicitly restored into it.

This happens more often than most site owners expect, because plenty of legitimate migration paths involve exactly this kind of fresh setup: moving to a new host with a clean install rather than a raw file transfer, rebuilding a staging site into production, recovering from a host-level issue by reinstalling WordPress from scratch, or even a plugin reset during troubleshooting an unrelated issue. None of these are exotic edge cases. They’re routine WordPress maintenance events that happen to intersect with a detail almost nobody thinks to check.

Even migrations that preserve the database exactly aren’t automatically safe. Some hosting migration tools intentionally exclude specific plugin data tables to reduce transfer size, or reset options tables flagged as “cache” or “transient” data during an optimization pass — and a push plugin’s key storage can occasionally get swept up in that kind of cleanup without anyone intending it. The safest assumption for any migration, regardless of how it’s performed, is that the keys need to be verified afterward rather than trusted to have survived by default.

Why This Rarely Comes Up With Vendor-Hosted Push Tools

It’s worth being clear about why this specific failure mode is mostly a self-hosted problem. Most WordPress push plugins on the market route subscriber data and delivery through a third-party vendor’s own infrastructure rather than generating and holding keys locally — which means there’s no local VAPID key pair for a site migration to accidentally regenerate, because the site never held the keys to begin with. The subscriber list lives on the vendor’s servers, tied to an account, not to a WordPress installation.

That isn’t a solved problem so much as a different tradeoff. A vendor-hosted subscriber list survives a WordPress migration cleanly, but it was never really the site’s data to control in the first place — it lives in someone else’s system, accessible through someone else’s dashboard, and subject to someone else’s pricing and retention policies. Self-hosting the keys means the site owns its subscriber relationship outright. It also means the site is now responsible for a detail that a vendor-hosted setup simply never exposes to the site owner at all.

How WhoKnew Signal™ Backs This Up

WhoKnew Signal™ is the only WordPress push plugin with a dedicated VAPID key backup and restore feature built into the plugin itself — not a raw settings field a technical user might think to copy manually, but an actual export and restore workflow designed around this exact moment. The Backup & Migration section, found in Signal’s Settings tab, exports the current key pair as a downloadable file. On the destination site, that same file gets uploaded through the restore option before the new install’s push plugin has a chance to generate its own fresh pair.

The Full Migration Checklist for Push Notifications

Beyond the key backup itself, a handful of related details are worth confirming during the same migration window, since they tend to get missed for the same reason the keys do — nothing about them throws a visible error. Confirm the new site’s domain matches exactly what subscribers originally opted in under, since a domain change is its own separate re-opt-in event regardless of key status. Verify HTTPS is active on the new install before restoring the backup, since push delivery requires it and a migration that temporarily runs on HTTP will silently fail delivery even with valid keys. Re-check the service worker is registering correctly on the new install — a caching plugin or CDN configuration carried over from the old site can occasionally serve a stale or missing service worker file. Confirm the PWA manifest and install shortcode, if in use, are pointing at the correct new domain rather than a leftover staging URL. And send that test campaign last, after every other piece is confirmed, rather than treating the restore step itself as the finish line.

Spotting a Key Mismatch Before Anyone Else Does

Because a VAPID mismatch produces no error, catching it depends on watching the right number rather than waiting for an alert that will never fire. The clearest signal is a subscriber count that looks intact — the database rows are still there, nothing was deleted — paired with a click or delivery rate that’s dropped to effectively zero starting from a specific date. That date almost always lines up with a migration, even one that happened weeks earlier and was otherwise considered a non-event. A campaign sent to a genuinely engaged list showing zero opens across the board is a stronger signal than a slow decline would be — a slow decline suggests fatigue or list quality; an abrupt drop to zero suggests every subscription simultaneously stopped validating on the same day.

The fastest confirmation is the direct one: subscribe a single test browser, send a campaign, and check whether that fresh subscription — created under whatever key pair is currently active — receives it. If a brand-new subscription works but nothing sent to the pre-migration list does, the key mismatch is confirmed, and the fix from that point forward is rebuilding rather than repairing, since the old private key is gone and there’s no technical bridge back to it.

If the Keys Are Already Gone

There’s no way to soften this part: if a migration already happened without a backup and the old keys are gone, there’s no recovery path. The old subscriptions are permanently invalid, and there’s no technical mechanism to reconnect them to a new key pair after the fact — this is the same reason migrating away from a vendor-hosted push tool always requires a fresh opt-in rather than an import of the old subscriber list; even vendor migration guides for major platforms treat a full re-subscription as the expected outcome when moving between systems, not an edge case to apologize for.

The only path forward is rebuilding, which at least comes with one piece of good news: Signal’s free tier supports unlimited subscribers at no cost, so rebuilding a list from scratch doesn’t carry the per-subscriber pricing pressure it would on a metered SaaS plan. A rebuild is also a genuine opportunity to fix a subscription popup that wasn’t converting well the first time around — a slightly better-timed prompt or a clearer opt-in message, applied while starting from zero anyway, can mean the rebuilt list ends up more engaged than the one that was lost. It’s a real setback, but not an expensive one to recover from mechanically, and not one that has to be repeated once the backup habit is in place going forward.

Testing a Migration Without Risking the Live List

For anyone planning a larger migration — a host change, a major platform move, or anything more involved than a routine backup restore — running the process once against a staging copy first catches exactly this kind of silent failure before it touches real subscribers. A staging environment that gets its own fresh WordPress install will regenerate its own VAPID keys automatically, the same way a live migration would, which makes it a safe, low-stakes place to rehearse the export-and-restore sequence and confirm the restore option actually produces a working test send before doing the same thing against a subscriber list that took months to build.

This is worth treating as a standing step in any migration checklist rather than a one-off precaution reserved for major moves. A five-minute staging rehearsal costs nothing and catches a mistake that, on the live site, wouldn’t announce itself for days or weeks — by which point the honest fix is a full rebuild rather than a five-minute restore.

Who knew the only thing standing between a clean migration and a silently dead subscriber list was a single export button nobody thought to click.