How to transfer an app to another Google Play and App Store account without losing users

The app has been in the store for years, it has thousands of ratings and active users, except that it sits on the account of a former software house, a freelancer or a company that is no longer part of your group. Sooner or later you will need to transfer the app to another Google Play and App Store account, one that belongs to you.

The good news: both Google Play and the App Store let you transfer an app together with its users, ratings and reviews. Nobody has to reinstall anything. The bad news: the transfer itself takes a few clicks in the console, but everything around it (push notifications, sign-in, links, Firebase) can quietly stop working. This article explains how to transfer an app so that your users don't notice a thing.

First: can the app be transferred at all?

One rule applies in both stores: the transfer is initiated by the owner of the source account. Neither Google nor Apple will move an app at your request if you don't have access to the account it is published on. So the first question is not "how" but "who is going to click the button".

• You have admin or owner access to the source account: you can go ahead straight away.
• The account belongs to a former contractor who is cooperating: you need one specific action from them, namely initiating the transfer to the account you designate. It is best to ask for this in writing, with the target account details ready.
• The account belongs to someone you can't reach: that is a different scenario, described in our article on what to do with your app when the developer disappears. Without the account owner, there will be no transfer.

While you're at it, check your contract: transferring an app in the store does not transfer the copyright to the code. That is a separate matter, worth sorting out in the same step; we covered it in our checklist for taking over a project from another software house.

Prepare the target account

Before anything happens, the target account has to be ready, and it has to be a company account, not a personal one.

Google Play. Create an organization account in Play Console and complete identity and business verification. The account must be active and in good standing, and if the app has payments, set up the payments profile that will receive payouts. Organization accounts are not subject to the closed testing requirement before first publication that applies to new personal accounts.

App Store. An organization account in the Apple Developer Program requires a D-U-N-S number for the company. Getting one can take several days, so start early. The person who will be the Account Holder must accept the current agreements in App Store Connect, and if the app is paid or has in-app purchases, also the Paid Apps agreement with banking and tax details filled in. An unaccepted agreement is the most common reason the transfer button is greyed out.

What transfers with the app and what doesn't

This is the most important table in the article. The store transfers the app's "storefront", but not the services linked to it outside the store.

Both companies publish the exact conditions and exceptions in their documentation and change them from time to time, so read the current version before the transfer. But the overall picture stays the same: the store transfers the app, not the infrastructure.

Pitfalls on the iOS side

On iOS, the transfer changes the team (Team ID) the app belongs to. Several mechanisms are tied to it:

• Push notifications. The APNs key (the .p8 file) belongs to the team. After the transfer you need to generate a new key on the target account and swap it on the backend or in Firebase Cloud Messaging. The safest approach is to prepare this in advance, so that on transfer day the change is a single operation.
• Keychain data. Keychain access groups are tied to the team identifier prefix. If the app stores login tokens there, it may not be able to read them after the team changes, and the user will see the login screen. This doesn't always happen, but you need to check the code and test it before your users find out.
• Universal Links. The apple-app-site-association file on your domain contains an identifier in the TEAMID.bundle.id format. Add an entry with the new Team ID, ideally next to the old one for a transition period.
• Sign in with Apple. User identifiers are tied to the team. Apple provides a migration process (transfer identifiers) that has to be completed within a limited time after the transfer; Apple specifies 60 days. If you skip it, users who sign in with Apple will reach your backend as new accounts.
• App Groups, iCloud, extensions. If the app shares data with a widget or extension, or uses iCloud containers, check Apple's documentation for how these resources behave during a transfer. This is the most common source of surprises in more complex apps.

Pitfalls on the Android side

On Android the transfer is usually gentler, because the app identifier and the signing key (with Play App Signing) stay the same. The problems come from the services around the app:

• Firebase. The Firebase project is not part of the app in the store. Don't create a new project; move the existing one by adding the new owner in the Google Cloud project permissions and then removing the old one. A new project means new notification tokens, the loss of analytics and crash report history, and push notifications no longer reaching users who haven't updated the app.
• Upload key. If the former contractor doesn't hand over the upload key, the new owner can request a reset in Play Console. The app signing key stays with Google, so users won't notice anything.
• API keys restricted by certificate fingerprint. Google Maps, Google Sign-In and other services often have keys restricted to the package name and SHA-1 fingerprint. The app key's fingerprint doesn't change, but the keys live in the Google Cloud project, which, as above, has to be moved separately.
• Older apps without Play App Signing. If the app was never moved to Play App Signing, the signing key is a file on someone's drive. Without it you can't release any update, regardless of whose account the app is on. Make sure you have it before you end your relationship with the former contractor.

Step-by-step plan to transfer an app to another account

1. Inventory. A list of all services linked to the app: Firebase, backend, push, social login, maps, payments, domains. For each one: whose account it is on and whether it transfers with the store listing.
2. Target account. Created, verified, with agreements accepted and a payments profile in place.
3. Release freeze. Don't submit new versions for review during the transfer. A version waiting for review can block the transfer.
4. Prepare the technical changes. A new APNs key ready to swap in, a new entry in apple-app-site-association, a Sign in with Apple migration plan, and reviewed keychain code.
5. Transfer. The owner of the source account initiates the transfer, providing the target account identifier, and the target account accepts it. In Google Play the transfer is also reviewed by Google and can take a few days.
6. Move the services. Firebase, Google Cloud, APNs keys, user permissions in the consoles.
7. Verification. On the production version of the app, check: do notifications arrive? Does the user stay logged in? Do links from emails and the website work? Do purchases work and do subscriptions renew?
8. First release from the new account. A small technical release, ideally with an automated release process configured for the new account from the start. Only this release confirms that the whole chain works.

How long it takes

Clicking the transfer button takes minutes; acceptance and review on the store side usually take from one to several days. The real timeline is set by the preparation: the D-U-N-S number, Google account verification, App Store Connect agreements and the former contractor's response. For a mid-sized app with Firebase, push notifications and sign-in, plan for two to three weeks in total, of which the transfer day itself is the shortest part.

Summary

Transferring an app to another Google Play and App Store account keeps your users, ratings and reviews, provided you take care of everything the store doesn't transfer. On iOS that mainly means push, keychain, Universal Links and Sign in with Apple. On Android: Firebase, Google Cloud and the upload key. Most problems don't come from the transfer itself, but from the fact that nobody ever wrote down what the app is connected to.

An account transfer is usually the first stage of a mobile app takeover from another contractor. We carry it out together with the client and check whether the handed-over materials are complete. If you don't know what state your project is in, start with a free app analysis: we'll check the accounts, configuration and code and tell you what needs to be done before the transfer.