You can bring your existing iOS and Android app push subscribers to PushEngage by reusing the same Apple and Firebase credentials your app already uses. Because device tokens are issued by Apple and Google rather than by your push provider, keeping those credentials lets your tokens keep working after the switch. This guide explains how the migration works and the steps to set it up. Migration is a backend process handled together with our team.
Before You Start
- Create your PushEngage account.
- Have access to your Apple push credentials, specifically your App Push ID and the p12 certificate from your Apple Developer account.
- Have access to your Android Firebase settings, specifically your Firebase Sender ID.
- Have a way to export your subscriber data from your current provider.
How Mobile App Migration Works
Device tokens for app push come from Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM), not from your current provider. If you configure PushEngage with the same APNs and FCM credentials you already use, those tokens stay valid, and the migration happens on the backend.
Notification permission also carries over. If a user already granted notification permission in your app, they do not need to grant it again after migration.
Steps to Migrate
Step 1: Export your subscribers from your current provider
Export your subscriber data using either method your provider offers:
- API export, using your current provider’s app ID and API key.
- CSV export, with a file that includes
identifier,device_type,language, and any other relevant fields.
Step 2: Configure Android FCM in PushEngage
- Log in to the PushEngage dashboard.
- Go to Settings » Installation » Android SDK.
- Configure the Google Android FCM settings using the same Firebase Sender ID you already use.
Step 3: Configure iOS APNs in PushEngage
- In the PushEngage dashboard, go to Settings » Installation » iOS SDK.
- Configure the Apple iOS APNs settings using the same App Push ID from your current setup.
- Upload the p12 certificate from your Apple Developer account, the same one you already use.
Important Notes on the App Version Cutover
App push migration depends on which version of your app a subscriber is running, so plan your release cutover carefully.
- Older app versions with the previous provider’s SDK. After migration, subscribers still on older app versions will not receive notifications sent from PushEngage, because the PushEngage payload cannot be decoded by the old SDK.
- New app versions with the PushEngage SDK. If you send from your previous provider’s dashboard after migration, those notifications will not appear on new app versions, because the old payload cannot be decoded by the PushEngage SDK.
In short, send from PushEngage for users on the new app version, and expect that users who have not updated will move over as they upgrade the app.
Frequently Asked Questions
Do subscribers have to grant notification permission again?
No. If permission was already granted in your app, it does not need to be granted again after migration.
Will every subscriber receive notifications right after migration?
Users on the new app version with the PushEngage SDK will. Users still on an older app version with the previous provider’s SDK will not receive PushEngage notifications until they update the app.
Why do I have to reuse the same APNs and Firebase credentials?
Because the device tokens are tied to those credentials. Reusing the same App Push ID, p12 certificate, and Firebase Sender ID keeps your existing tokens valid, which is what makes the migration possible without asking users to re-register.
What data do I need from my current provider?
Either an API export using your provider’s app ID and API key, or a CSV that includes at least identifier, device_type, and language, plus any other relevant fields.
If you run into any issues, please feel free to contact us by clicking here. Our support team will be able to help you.