Skip to content

Most visited

Recently visited

navigation

Retain users and add value when migrating to a new app or merging apps

Even if you've a substantial number of users for your app, migrating to a new app or merging apps may be necessary to develop your business and offer more value to your users. By taking a few simple but carefully planned steps, you should retain the majority of your users and have users who will want to migrate.

Why it happens

There are several reasons you may consider migrating to a different app or merging existing apps. The benefits to your business and users will depend on the cause of the change. The main reasons are:

  • Migrate to a universal APK. You may support multiple form factors, such as Wear, tablet, and phone - but, each version has its own package name and Play Store listing. It may no longer make sense to maintain these separate packages if, for example, you're re-implementing the same features across code bases or the teams managing the apps have combined.
  • Consolidate features. You may have two or more apps with overlapping features. Combine the apps into one, to affirm a unified message to users.
  • Complete re-design or feature pivot. To achieve a broader impact with a different feature set or the app isn't performing as well as you'd like even though you have many users. In these cases, it may be easier to build a new app and migrate users to it, particularly if the changes are a radical departure from the current app.
  • Rotate the app's signing key. Both the Play Store and Android uniquely identify apps by a combination of package name and signing key. If you forgot your private key, you need a stronger signing key, or in the worst case, the key was leaked you will need a new package name.

Best practices

  • Try not to create separate apps in the first place. Separate apps (e.g. for different form factors or use cases) are usually more work to maintain and harder for users to discover and manage themselves, leading to lower quality and under-utilized apps.
  • Choose the app with the larger install base or most desired feature set as your target app. Decide which of your multiple apps will be the final destination for all of your users, typically the one with a larger install base, to minimize user disruption, but it could also be the one with your final desired feature set.
  • Alternatively, create a new unified app and deprecate all others. Build a new app that combines the features of each of your other apps. However, there is a greater risk of losing users by doing so, compared to retaining an existing app as the target.
  • Plan for a gradual migration. A gradual or staged migration will minimize the surprise or frustration for users and limit any potential impact on user retention.
  • Consider an intermediate update to ease users into the change. When updating the target app with the new or combined functionality, if the new or combined features are a drastic departure from the app's current look, feel, or behavior, a gradual approach may work best to make users feel more comfortable with the new app.
  • Include support for additional form factors and ensure new features or device support are properly listed in the Play Store listing. The Play Store provides two options to do so: a single, “universal” APK for all devices so users can install and run the same APK on any of the supported form factors or multiple APKs for different devices. All APKs in this listing must have the same (new) package name.
  • Shift marketing or promotional materials to point exclusively to the new app. Ensure that any new users are going to the right app to minimize the number of users you need to migrate. Do this by re-branding the new app and its Play Store listing. If you're using an intermediate update, take this opportunity to warn users about impending name or brand changes.
  • Inform current users about the migration. You can do this gradually using banners, interstitials, push notifications, or other forms of messaging. Tell users about the new app, and why they should switch to it. Persuading users to switch is a big part of this, so be sure to highlight any benefits or other improvements in the new app. While the old app is still functional at the beginning, users can make a choice whether to switch, so use soft, unobtrusive, and dismissible messaging. Gradually increase the prominence of this messaging and emphasis on the need to switch.
  • Consider providing an incentive for users to switch quickly. For example, a free subscription to the new app or a one-time discount. As you get towards the end of the migration, you might consider a more forceful incentive of disabling features while pointing users to the new app.
  • Collect feedback on the migration. During the migration, it's possible that you will miss something (for example, some feature that people loved) or for some other reason users are unhappy with the change. Don't rush through this step: this period gives you time to assess feedback and make any necessary corrections.
  • Consider releasing a version of the old app that automatically redirects users to the new app. Do this before unpublishing to migrate as many remaining users as possible.
  • Sunset the old apps by unpublishing them. Unpublishing is the best option to avoid any branding confusion or new users accidentally installing the deprecated app. You'll never get all users to migrate, so it'll be a business decision to determine a threshold at which losing those users is acceptable.
This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.