How to Migrate from OneSignal to ReachBell

You cannot directly port web push subscriptions from one platform to another — VAPID keys belong to whoever generated them, and Chrome/Firefox/Safari treat a new vendor as a fresh world. But you can move your audience over without losing the engaged majority, by running both platforms in parallel for a couple of weeks. Here is the exact playbook.

Before you start

• Inventory — your current OneSignal MAU, total subscribers, and active-7-day count. The last one is the migration target.
• Owner sign-off — running two SDKs briefly means slightly heavier page weight. Loop in whoever owns Core Web Vitals.
• Calendar — pick a 21-day migration window that does not overlap a major campaign or sale.

Step 1 — Create the ReachBell project (day 0)

Sign up, create a project for production. Generate fresh VAPID keys. Download the service worker file and confirm you can host it at your domain root (`/reachbell-sw.js`). If you cannot — because of Shopify, a managed CDN with locked paths, etc. — use the WordPress/Shopify integration paths, which handle this for you.

Configure default UTM tags, quiet hours, and frequency caps in the dashboard before you ship code. Migration is the right time to retune defaults.

Step 2 — Export the OneSignal subscriber list (day 0)

In OneSignal, Audience → All Users → Export to CSV. The export contains player IDs, last-active timestamps, language, country, tags, and external user IDs (if you set them).

Step 3 — Install ReachBell SDK alongside OneSignal (day 0-1)

Add the ReachBell snippet to your site. Crucial: name your service workers so they do not collide.

// OneSignal
window.OneSignal = window.OneSignal || [];
OneSignal.push(function() {
  OneSignal.init({
    appId: "your-onesignal-app-id",
    serviceWorkerPath: "/OneSignalSDKWorker.js",
  });
});

// ReachBell — different SW path
<script
  src="https://cdn.reachbell.com/sdk/v1/reachbell.js"
  data-project="prj_xxxxxxxx"
  data-sw-path="/reachbell-sw.js"
  async
></script>

Both service workers live in `/public` (or your equivalent). They register at different scopes and do not conflict — service workers are scoped to their own URL path.

Step 4 — Decide your soft-prompt strategy (day 1)

You have two options for the dual-run period. Pick one and document it for the team:

• ReachBell prompts new visitors only — suppress the ReachBell soft prompt for visitors who already have a OneSignal subscription token in their browser. Cleaner UX, slower migration.
• Both prompts shown to active visitors — anyone who returns sees a one-time "Switching to our new notifications" banner asking them to opt in to ReachBell. Faster migration, slight UX cost.

The second is what most teams pick. Wire it as a one-time banner gated by a localStorage flag:

if (!localStorage.getItem("rb_migration_seen")) {
  ReachBell.showSoftPrompt({
    title: "We have upgraded our notifications",
    body: "Stay subscribed for order updates and offers.",
    onClose: () => localStorage.setItem("rb_migration_seen", "1"),
  });
}

Step 5 — Re-engagement campaign (day 1-14)

Use OneSignal to send 2-3 normal sends during the window that link back to your site. Active subscribers click, land on a page where the ReachBell soft prompt fires, and dual-subscribe. Inactive subscribers do not — and you would have lost them anyway.

Send a transactional push (order shipped, etc.) over OneSignal as usual; the click brings them to a confirmation page where the ReachBell prompt waits.

Step 6 — Measure crossover (day 14)

In the ReachBell dashboard, count active-7-day subscribers. Compare to your OneSignal active-7-day count from day 0. The pattern we see:

• Day 7 — ReachBell active subscribers at 30-50% of OneSignal active.
• Day 14 — 60-80%.
• Day 21 — 80-95%; further gains slow rapidly.

If you are above 70% at day 14 you can proceed to cutover. Below that, extend dual-run by another week or push a second re-engagement campaign.

Step 7 — Cutover (day 14-21)

Move sends to ReachBell. Stop scheduling new campaigns in OneSignal. Leave OneSignal SDK installed for 7-14 more days as a safety net in case any segment did not re-subscribe.

• Move triggered automations (cart, win-back) to ReachBell first — they generate the most subscriber engagement.
• Move scheduled promos next.
• Move transactional pushes last; they are the ones you cannot afford to break.

Step 8 — Sunset OneSignal (day 21+)

Remove the OneSignal snippet from your site. Delete the OneSignal service worker file. Downgrade or cancel your OneSignal plan only after the SDK has been removed from production for at least 7 days — otherwise active service workers keep registered tokens alive.

Common gotchas

• Service worker scope conflicts — symptom: ReachBell subscriptions fail silently. Fix: confirm scopes do not overlap and that both files are served as `application/javascript`.
• External user IDs not transferred — if you target by external user ID in OneSignal, set the same ID on the ReachBell subscribe call (`externalId`) so user-targeting works immediately.
• Browser-prompt suppression — users who blocked OneSignal will not see the ReachBell prompt either. Browser-level Block is global, not per-vendor. Accept this loss; it is the right behaviour.
• iOS Home Screen users — they need to re-add the app to home screen and re-subscribe. Plan a small in-app banner for them.

Why this works

Migration is mostly a recovery problem: keep your engaged audience, accept loss of the dormant tail. A 14-21 day dual-run captures roughly the same audience that an industry-wide engagement campaign would surface anyway. The economics tend to pay for themselves within the first month on the new platform.

Read the OneSignal alternative page for the pricing math, or jump to the from-OneSignal migration page for the up-to-date copy-paste snippets. Free ReachBell project covers the entire migration window for sites under 1,000 subscribers.