Migrate from PushEngage
PushEngage migrations split into two cases. Older accounts expose the VAPID key pair, which makes this a clean key import — bring the keys across and every subscriber stays subscribed. Newer accounts manage the keys server-side and don't hand them out; for those, ReachBell's silent re-subscribe rolls your active list over with no permission prompt. This guide covers both.
New to the general approach? Read the migration overview first — this guide is the PushEngage-specific version of that playbook.
Why teams switch from PushEngage
- Email in the same tool. PushEngage is push-only and points you to a partner for email. ReachBell ships campaign and transactional email on AWS SES in the same dashboard, against the same segments.
- Automations without an upsell. Welcome series, drip nurtures, and win-back journeys are included on paid plans — no "talk to sales" gate to unlock a workflow builder.
- Rupee pricing, GST invoices. PushEngage bills in USD with no GST invoice. ReachBell bills in INR via UPI, cards, or net banking and ships an invoice your accountant accepts.
1. Pull your VAPID keys — or skip to silent re-subscribe
Check Settings → Site Settings → API Keys in PushEngage. Two outcomes:
If the VAPID pair is there (older accounts): export it and import it into ReachBell. Subscriptions are bound to the key pair and your origin, so every browser keeps working the moment the keys are in place.
curl -X POST https://api.reachbell.com/migration/project/proj_01HX2.../vapid-import \
-H "x-api-key: rb_live_yourkey" \
-H "Content-Type: application/json" \
-d '{
"publicKey": "BNc...",
"privateKey": "tZk..."
}'{
"success": true,
"message": "VAPID keys imported. Existing subscribers registered with these keys will continue working silently."
}If the keys aren't exposed (the common case on newer accounts): don't try to extract them. ReachBell's SDK detects the existing push permission on your origin, generates a fresh subscription under your new VAPID pair, and registers it in the background. Over one to two weeks of traffic, the bulk of your active list rolls over.
No permission re-prompt either way. The browser already granted push for your origin. Importing keys keeps the same subscription; silent re-subscribe creates a new one against your keys — but neither shows a permission dialog, a banner, or any interruption.
2. Replace the SDK script
Delete the clientcdn.pushengage.com snippet and its service-worker file (service-worker.js or pushengage-sw.js) from your site root. Drop in ReachBell's loader plus reachbell-sw.js — see the JavaScript integration for the complete walkthrough.
<!-- Remove the clientcdn.pushengage.com script and its service worker -->
<!-- Add -->
<script src="https://app.reachbell.com/reachbell.js" defer></script>
<script>
window.addEventListener("DOMContentLoaded", () => {
ReachBell.init({
apiKey: "rb_live_yourkey",
silentResubscribe: true, // only needed when PushEngage owns your VAPID keys
});
});
</script>Set silentResubscribe: true only if you couldn't extract the keys in step 1; drop the flag once your list has rolled over. The service worker must live at the root of your origin (https://yoursite.com/reachbell-sw.js) so its scope covers every page.
3. Import segments and tags
Export your audience from Audience → Subscribers → Export — PushEngage emails you a CSV with subscriber IDs, tags, segments, browser type, geo, and last-seen timestamp. Bring it in via the CSV uploader, or POST the rows to the import endpoint in batches of up to 10,000:
curl -X POST https://api.reachbell.com/migration/project/proj_01HX2.../subscribers-import \
-H "x-api-key: rb_live_yourkey" \
-H "Content-Type: application/json" \
-d '{
"source": "pushengage",
"subscribers": [
{
"channel": "web_push",
"subscription": {
"endpoint": "https://fcm.googleapis.com/fcm/send/...",
"keys": { "p256dh": "BNc...", "auth": "tZk..." }
},
"tags": ["cart-abandoned", "india"],
"country": "IN",
"browser": "Chrome"
}
]
}'{ "imported": 1, "skipped": 0, "failed": 0, "errors": [] }Every imported subscriber is auto-tagged migrated and migrated_from_pushengage. The import dedupes on the subscription, so re-running the same file is safe. Your saved segments rebuild automatically from the tag columns.
4. Verify subscriber sync
Open ReachBell → Project → Verification and reload your site in a logged-in browser — you should see a "subscriber matched" event within seconds. Confirm the count:
curl https://api.reachbell.com/migration/project/proj_01HX2.../status \
-H "x-api-key: rb_live_yourkey"{
"totalActive": 22140,
"migrated": 21890,
"bySource": [{ "source": "pushengage", "count": 21890 }]
}If you imported the keys, totalActive matches PushEngage almost immediately. If you're relying on silent re-subscribe, the count climbs as visitors return — 70–80% of an active list typically rolls over within a week. Send a test push, confirm it lands, then retire the PushEngage account.
Run both in parallel during cutover
Both SDKs can coexist on the page without conflict. Keep PushEngage active for a week alongside ReachBell, run a single A/B test (a ReachBell campaign vs. a PushEngage trigger) to confirm parity on CTR and delivery, then disable the PushEngage triggers and remove its script and service-worker file.
What about trigger campaigns?
Cart abandonment, browse abandonment, price-drop, and inventory-back triggers all map 1:1 to ReachBell automations, and the team will rebuild them for you on every paid plan. Email sale@reachbell.com with your PushEngage site ID and a sample subscriber export — they handle the import, the automation rebuild, and a verification call before you flip the SDK. Most PushEngage migrations finish in one afternoon.
What's next?
- Wire up the SDK in full with the JavaScript integration.
- Rebuild your audiences with the Segments guide.
- Recreate your trigger campaigns in the Automation guide.