You built your push subscriber list one hard-won opt-in at a time, and every opt-in cost real acquisition money. So when it’s time to switch push notification providers, the fear is specific: cancel the old contract and the list disappears with it. Your current vendor may even tell you exactly that.
It isn’t true, and this guide shows you why at the browser level. A web push subscription is bound to your domain, not to your vendor. Once you see the mechanics, every switch resolves into one of two clean scenarios, a short list of written questions for your current vendor, and a one-week checklist your team can run without drama.
One honest note up front. Every vendor’s sales team, ours included, will tell you migration is easy. Most stop there. This post shows you the mechanism instead, so your developer can verify every claim, including the ones we make at the end.
What a web push subscription actually is
When a visitor clicks “Allow” on your site, the browser creates a web push subscription built on three parts:
- Your origin. The exact domain the permission was granted on (
https://yoursite.com). The permission lives in the browser, attached to the origin. It does not mention any vendor. - A service worker. A small JavaScript file hosted on your domain that receives and displays notifications. Whichever service worker is registered controls delivery.
- An application server key. The public half of a VAPID key pair. The browser’s push service only accepts sends signed with the matching private key. Whoever holds that private key can message the subscription. (web.dev’s push notifications overview covers the full protocol.)
The subscription record itself is three strings: an endpoint URL plus two short keys, p256dh and auth. That is the entire asset. Your whole list is a table of those records.
One rule decides everything downstream: browsers accept sends only from the holder of the matching VAPID private key. Which means every vendor switch resolves into exactly two scenarios, depending on where those keys live.
Scenario A: your VAPID keys travel, so you import push subscribers on day one
Scenario A applies when the keys are yours to take: you configured your own VAPID keys or your own Firebase project at setup, or your outgoing vendor agrees to hand the key pair over. Some teams set this up deliberately from day one; the approach is covered in our guide to implementing web push without vendor lock-in.
With the private key in hand, your new provider can import push subscribers directly: every endpoint, p256dh, and auth record moves over, and you can message your entire existing list from day one. That includes dormant subscribers who haven’t visited in months. Nobody re-opts-in. Nobody notices.
One nuance worth stating plainly. Even in Scenario A, the durable migration still completes through revisits, because every subscriber eventually needs to land on the new service worker. The imported keys buy you day-one reach while that rollover happens quietly in the background.
Scenario B: keys stay behind, and the silent re-subscribe takes over
Scenario B is the common default: the vendor generated the VAPID keys and keeps them. Without the private key, exported records are cryptographically useless. Day-one reach is zero, and your old vendor’s warning sounds true for about one more paragraph.
Here is what actually happens. The next time each subscriber visits your site, the new provider’s service worker takes over: it unregisters the old registration, unsubscribes the old subscription, and re-subscribes the visitor under the new keys. Silently, in a single visit, with no second permission prompt.
Why the new service worker needs no second prompt
Notification permission is granted to your origin, not to a vendor. The browser already trusts your domain. Swapping the service worker and keys underneath an already-granted permission is invisible to the visitor, because the browser treats it as your site reorganizing its own plumbing. That is exactly what it is.
Two traps your developer should know about
One origin, one subscription. A browser cannot hold two push subscriptions for the same origin. Subscribing with a different key fails until the old subscription is released. So “run both vendors in parallel” works at the list level, never inside a single browser: each subscriber is on the old vendor or the new one, and every revisit moves one more over.
Vendor-subdomain opt-ins never move. Subscriptions collected on yoursite.vendor.com belong to the vendor’s origin, and no provider can migrate them. That base rebuilds from scratch. It is the biggest trap in any push notification migration, and the strongest argument for anchoring subscriptions to a domain you control this time. If you operate several brands or regional domains, the same origin logic shapes your whole architecture; we cover it in web push across multiple domains.
Here are the two scenarios side by side:
| Scenario A: keys travel | Scenario B: keys stay behind | |
|---|---|---|
| When it applies | Own VAPID keys / own Firebase project, or the vendor releases the pair | Vendor generated and retains the keys (the common default) |
| Day-1 reach | Your entire list, including dormant subscribers | Zero, until visitors return |
| On each revisit | Subscriber quietly moves onto the new keys | Silent re-subscribe under the new keys, no second prompt |
| Who you recover | Everyone | Everyone who visits again |
| Who you lose | Nobody | Subscribers who never return (who were no longer reachable revenue anyway) |
Why daily-visit audiences finish a push notification migration fastest
In Scenario B, the takeover clock is your audience’s return frequency. Nothing else. An eCommerce subscriber might visit monthly, so the takeover stretches across months. A bettor checks odds, lines, and results daily. A news reader comes back for every headline cycle.
That return rhythm is why betting and news sites are the best-positioned verticals on the internet to switch push notification providers: the same visit frequency that makes push notifications for betting sites a retention engine also compresses a migration that takes other sites a quarter into a week or two. Betting and gaming sites on PushEngage have sent over 3.5 billion notifications, so these takeover mechanics are daily production reality for us, not theory.
| Audience return pattern | Typical active-base takeover |
|---|---|
| Daily visitors (live odds, breaking news, daily promos) | Days to about a week |
| Several visits per week (weekend bettors, regulars) | 1–2 weeks |
| Weekly or less (seasonal visitors, lapsed users) | Weeks, accelerated by old-vendor sends and big events |
| Dormant (no visit in months) | Recoverable only under Scenario A |
These are typical patterns for daily-visit audiences, not guarantees; your curve depends on your traffic rhythm, and you’ll watch it live in the dashboard. You can also bend the curve: schedule the transition the week before a major fixture weekend and event traffic does the takeover for you. Sportsbooks planning a match-day push sequence already know which weekends those are.
App push is simpler: your tokens were always yours
If you also send app push, take a breath. This half is structurally easy, because no vendor can hold it hostage.
APNs certificates and keys are issued to your Apple Developer account. Your FCM project lives in your Google console. A push vendor is a layer on top of credentials you own, so switching means pointing a new layer at the same credentials. Device tokens export and import cleanly, with no reinstalls and no second permission prompt.
Two practical notes. First, filter token exports to roughly 270-day-active devices before importing, because FCM treats tokens inactive beyond ~270 days as stale. A five-year token dump inflates your subscriber count, and on pricing that only counts active subscribers, nobody benefits from that. Second, full SDK coverage arrives at the speed users update your app, typically a week or two for a daily-use app with auto-updates.
If your iOS app currently sends through Firebase, the step-by-step flow is its own topic; see our guide to migrating from Firebase Cloud Messaging on iOS rather than improvising it from this post.
Before you switch push notification providers, ask these six questions in writing
Vendor export and key policies vary, and they change. Instead of trusting any table of vendor verdicts (including one we could publish), get your own vendor’s answers on the record. Email works; a support ticket works better. If you’re evaluating destinations at the same time, the same questions make a useful screen while comparing OneSignal alternatives.
- Can you export my complete web push subscription records — endpoint URL plus the
p256dhandauthkeys for every subscriber — or only internal IDs? Internal IDs are meaningless outside the vendor’s system. - Will you release the VAPID key pair my subscriptions were created under? This single answer decides Scenario A versus Scenario B.
- Whose FCM or Firebase project does my web push run on, mine or yours? If it’s yours, the keys may already be in your own console.
- Can I export segments, tags, subscriber attributes, and suppression lists separately? They don’t ride along with subscription records automatically.
- Can I export my app push device tokens, and in what format?
- What happens to my data if I downgrade or cancel — is there an auto-deletion or retention window? Some vendors purge inactive subscriber data on lower tiers. Export first, always.
The migration-week checklist
Print this section. Eight steps, in order.
- Export everything before cancelling or downgrading anything. Subscription records, app tokens, segments, tags, attributes, suppression lists. Export access dies with your contract.
- Get the VAPID keys answer in writing. It decides your scenario and whether you can import push subscribers on day one.
- Move suppression lists first, not last. For betting and gaming operators this is non-negotiable: self-excluded players must be suppressed on the new platform before a single campaign resumes, not reconciled afterwards.
- Filter app tokens to ~270-day-active before import.
- Install the new SDK and service worker, and merge with any existing service worker (a PWA shell, the old vendor’s worker) rather than overwriting it.
- Do not delete the old vendor’s service worker file on day one. Returning visitors still carry registrations pointing at it; the takeover unregisters them gracefully. Rip the file out early and you generate console errors instead of migrations. Remove it at final teardown.
- Keep the old vendor sending through the parallel window. Counterintuitive but critical: every notification the old vendor sends drives a revisit, and every revisit completes one more subscriber’s migration. Your outgoing vendor becomes your best migration tool.
- Measure takeover daily and cut over at the plateau. Track new active base against old active base. When the curve flattens, finish the teardown, cancel the old contract, and archive the exports.
What switching costs when PushEngage does it for you
At PushEngage, migration is a white-glove service included free on paid plans. You get a migration engineer, not a help-center article: they handle export mapping, key handling, the service-worker merge, and the takeover plan. That matters because the failure modes are quiet ones — a raw import with mismatched payload formats can deliver technically-successful-but-blank notifications, which is exactly the class of silent failure a specialist catches before your subscribers do.
The scoping call takes about fifteen minutes: subscriber counts per channel, current vendor, and the keys question above. By the end of it you know whether you’re Scenario A or B, and you have a dated plan.
If you’re ready to switch push notification providers, start with the six written questions in this post and see how your current vendor answers. Then look at what a web push notification platform built around segmentation and revenue attribution would do with the list you already own, and check PushEngage pricing against your current invoice. Every paid plan carries a 14-day money-back guarantee, so the push notification migration itself is the lowest-risk part of the decision.
