How to migrate Mobile Push to Batch?
Batch allows you to migrate seamlessly from most push solutions on the market. Our migration methodology allows you to keep reaching your whole audience and migrate your running campaigns without interruption.
Here is an overview of the migration steps:
Integrate Batch SDK in your app (optionally keep the other provider's SDK for the first release);
Tag your app to keep collecting the necessary custom data on your users;
Get the push payload expected by your former push solution and Import your current push tokens to target users who have not upgraded the app yet;
Migrate your push campaigns from your former push solution to Batch without interruption.
Prerequisites
Follow these steps to start the migration:
Create an account on https://batch.com/register.
We recommend that you invite your team members from the account manager section (in the bottom left corner of your dashboard, under "Manage Team" → "Invite user").
Create your apps on the Batch dashboard.
We recommend creating two applications per OS on the dashboard: one for tests and one for production (e.g. MyApp and [DEV] MyApp).
Integrate Batch SDK in your app.
Follow our dedicated documentation: iOS / Android / Cordova / Flutter / React Native.
Migration types
Depending on your constraints, you will choose to keep or remove the SDK of your previous push provider for the first release of your app with Batch. Here are details on these two migration types to help you make a decision.
Keep both SDKs: Staged migration
In this case, the first app release integrates both the previous push solution’s SDK and Batch SDK. This makes it possible to use one or the other solution in parallel to send push notifications as long as the SDKs coexist in the app.
The timeline for teams training on Batch dashboard and tokens export/import is more flexible with this method. There is no sudden service interruption with your former push provider. The cohabitation of SDKs can cause duplicate pushes on Android. In this case, you need to use an Interceptor in your app (see Push payload).
Include only Batch SDK: Hot swap migration
The SDK of the previous push solution is removed from the app once Batch SDK is integrated. As soon as the version of the app with Batch is released, Batch is the only solution that collects the new push tokens, and becomes the only solution that you can use to target your userbase.
This method allows you to migrate within a short timeframe, but implies fixed tokens export dates and that your marketing teams are comfortable using the dashboard before the first app release with Batch.
Tagging plan
You should list the campaigns to be migrated to determine the tagging plan to be implemented.
You should keep the same attributes and arrays names as your previous tagging plan to ensure that your imported tokens will be targeted by your campaigns (see how to import custom data with your push tokens).
Push tokens import
A push token is an anonymous ID generated by the push services (Apple, Google, etc.) that is used to target your users via push notifications. In the context of a migration, importing all your existing tokens makes it possible to reach your whole userbase, including users who don’t have a version of the app that includes Batch SDK yet.
You should plan to export the tokens after the apps have been released with the Batch SDK to avoid any loss in the collection of tokens between the time of export and the time when Batch starts collecting them.
Here are the detailed specifications for the tokens import: Importing your tokens.
Push payload
After migrating your push tokens to Batch, you will be able to target users who are still using a version of the app that does not include Batch SDK.
To contact these users correctly, you need to use the payload that is expected by the SDK of your previous push solution. You have to get in touch with your previous push provider to get it.
iOS
The iOS payload of a push notification is standard and push notifications are displayed by the system. The expected payload is still needed to manage deeplinks.
Android
On Android, push notifications are handled by the SDK. The expected payload is required to manage the whole content: the title and body of the push notification, the deeplinks, etc. In case of a staged migration (see Migration types), both SDKs might try to display the notification sent by Batch, which may result in duplicate push notifications.
To address this, here is an interceptor to be integrated into your app that disables the Batch receiver when the payload of another solution is detected (read more on how to register it here):
In case you cannot import your push tokens or retrieve the payload expected by your previous push provider, you will need to start collecting your userbase from scratch. This happens, for example, if you previously used Firebase as a push service (read more here).
Testing
Once all elements have been integrated, you need to test the basic implementation following these guides: iOS / Android.
As part of the migration process, it is crucial to ensure that all users will be contacted correctly and that there is no unexpected behavior in any version of the app. You will find all the extra testing steps here: Testing.
Campaigns migration

Once your app has been released with Batch SDK and your tokens have been imported, you can start migrating your push campaigns. Here is how to proceed:
Create your campaigns as drafts on the Batch dashboard.
Deactivate the campaigns running with your previous push provider.
Activate your campaigns on the Batch dashboard.
You must never run the same campaign from both push solutions: some tokens might be present in both userbases and might receive the notification twice.
The process of campaign migration is detailed here: Campaigns migration.
Last updated
Was this helpful?