We recently switched from Parse to Amazon SNS for our push notification service. Parse is shutting down on January 28th, so we had to switch to a different service provider. Fortunately for us, we only used Parse for push notifications, which made the migration process much easier.
Our application is a Spring/Java backend REST API service, which supports Android and iOS applications. Its notification system is based only on remote push notifications. When Parse announced early in 2016 they would be shutting down, we needed to find a new push notification service comparable to Parse. We chose Amazon SNS.

Why we chose Amazon SNS

To handle push notifications, we chose Amazon SNS because of the following reasons:

  • It can send notifications to different platforms (iOS and Android) using simple API
  • It has great scaling potential; this is incredibly useful as your app gains more and more users
  • It tolerates GCM downtime and throttling
  • It gives you the option to send a notification to certain users who are all subscribed to the same topic
  • It gives you the option to send simple notifications to different types of endpoints, so you don’t have to worry about how to integrate your push notification system with a specific platform
  • The price is lower than the competition.

Another important reason to consider Amazon SNS is that you are not locked into their service once you sign up. If you’re unsatisfied with the platform, you can remove your app registration IDs and walk away.

Amazon SNS was also a good option for us because we already have expertise in using Amazon Web Services. We felt there was no need to experiment with new platforms when we were already comfortable with Amazon.

Migration steps and challenges

Before you move from Parse to another push notification service, no matter what that service is, you need to do the following:

  • Analyze your current working relationship with Parse and see what data you are giving them
  • Identify potential obstacles to switching services, such as data reuse, migration time, downtime, potential mobile app updates, and adoption rates
  • Determine whether there is a way to migrate existing devices to your new service by exporting data from Parse.

Ideally, you want to reuse your push notification data, because this will make less work for you. If you are providing Parse with data that is totally dependent on your own configurations, you will be able to export all your data to Amazon SNS. Doing so will allow you to start sending push notifications immediately, just by changing your backend API. There’s no need to submit a new version of your mobile app.

If on the other hand, you have incomplete push notification data, you will not be able to migrate data without modifying your existing mobile app.

If you are supporting iOS and Android push notifications with an invalid registration identification, you can most likely only reuse your iOS data in full. You will have to submit a new Android version of your app in order to switch.

Our first challenge: registering Android devices on SNS

In our migration, the first challenge we faced was registering Android devices on Amazon SNS with our own GCM/FCM sender ID. Parse used its own sender ID to generate registration tokens for push notifications, which meant that Parse was only authorized to send push notifications on a user’s behalf.

There are two ways that you can overcome the problem of having the wrong GCM/FCM sender ID:

1. Release a new version of the Android app that will regenerate registration IDs with your GCM/FCM sender ID. After all your users update their apps, you can start your migration process and fully export your push notification data from Parse. This solution does not require you to make any API changes or integrate to Amazon SNS before you complete the migration of your push notification data.

Once you have released the new version of your Android app, your next step is to change your API so it supports Amazon SNS usage, and remove Parse completely from your API and the mobile apps.

2. Release a new version of your app that will directly register users to Amazon SNS. Until all devices are registered on Amazon SNS (or until Parse shuts down), you will have to support both services. This approach allows you to detach Parse from your app and change your API to support sending push notifications with Amazon SNS all in a single run.

We decided to choose option 2 for both iOS and Android devices. This means that none of our push notification data has been migrated from Parse.

We chose this option because we did not have device UUIDs in our own database; they were only in Parse. Choosing option 1 would have required us to migrate all device UUIDs from Parse’s database to our own database, and this would have been far too time-consuming.

We needed to make a fast transition, so we decided to do the following:

  • Update our backend service to support Amazon SNS registration of existing and newly created users. Here is a simplified SNS endpoint registration example:
public String getEndpointArn(Device device) {
	boolean updateNeeded = false;
	String endpointArn = device.getEndpointArn();

// If device has no endpoint ARN associated with it, create it.
	if (endpointArn == null) {
		endpointArn = createEndpointArn(device);

	try {
// Check if endpoint is disabled for some reason, although we have ARN data.
		updateNeeded = !isEndpointValid(endpointArn, device.getDeviceToken());
	} catch (NotFoundException nfe) {
		// We had stored ARN, but the endpoint associated with it
		// disappeared. Recreate it.
		endpointArn = createEndpointArn(device);

// Enable endpoint on SNS.
	if (updateNeeded) {
		enableAndUpdateEndpoint(endpointArn, device.getDeviceToken());
	return endpointArn;
  • Modify our backend service so it supports sending push notifications via Parse or SNS using dispatcher service, until Parse shuts down. Here is a simplified dispatcher example:
private void notify(final EndUser notifiedUser, final Highlight thanksHighlight) {
	// dispatch push notifications to Amazon or Parse
	List<Device> parseDevices = new ArrayList<Device>();
	List<Device> amazonDevices = new ArrayList<Device>();

	for (Device device : notifiedUser.getDevices()) {
		if (device.getEndpointArn() != null) {
			// if endpoint ARN exists, dispatch to Amazon SNS
		} else if (device.getNotificationToken() != null) {
			// if notification token exists, dispatch to Parse (device not
			// migrated to Amazon)
	if (!parseDevices.isEmpty()) {
		sendNotification(parseNotificationService, notifiedUser, parseDevices, thanksHighlight);
	if (!amazonDevices.isEmpty()) {
		sendNotification(amazonNotificationService, notifiedUser, amazonDevices, thanksHighlight);
  • Update mobile apps in order to provide our API necessary data for registration to Amazon SNS (device UUID for all and registration ID for Android device)

This solution worked for us because we have enough time to get all our users to update their mobile apps before Parse shuts down.


In a short period of time, we managed to migrate almost all our active users to Amazon SNS using the method we described above. All we have left to do is to tell our users that are still on the old mobile app version that they must update their apps before Parse shuts down, so that they can keep receiving push notifications as well as remove Parse support completely from our API.

Read more:
About Parse shutting down: http://blog.parse.com/announcements/moving-on/
Sending Push Notifications via Amazon SNS: https://aws.amazon.com/blogs/aws/push-notifications-to-mobile-devices-using-amazon-sns/
Mobile token management with Amazon SNS: https://aws.amazon.com/blogs/mobile/mobile-token-management-with-amazon-sns/
Migrating push tokens from Parse to Amazon SNS: https://aws.amazon.com/blogs/mobile/migrating-from-parse-push-to-amazon-sns/

Software DevelopmentTech Bites
February 23, 2024

Background Jobs in Elixir – Oban

When and why do we need background jobs? Nowadays, background job processing is indispensable in the world of web development. The need for background jobs stems from the fact that synchronous execution of time-consuming and resource-intensive tasks would heavily impact an application's  performance and user experience.  Even though Elixir is…

Want to discuss this in relation to your project? Get in touch:

Leave a Reply