Transferring an app to another developer account

When is an app transfer needed?

In three situations: the app was published from an agency's account and the company wants it in its own, it sits in a founder's personal account and needs to move to the company account, or the app has been sold and must go to the buyer. In all three the problem is the same: change the owner without losing the app's identity.

The alternative to a transfer is not “republish from a new account”, because that is not an alternative, it is a loss. Package names and bundle IDs are permanent; a name once used can never be reclaimed. A team that republishes loses its reviews, install history, ranking and the update path for existing users all at once.

Which apps can Apple not transfer?

Apple's list of conditions is short but hard; a transfer that trips one of them never starts. The app must have at least one version released to the App Store and must not be available for pre-order in any country. No version may use an iCloud entitlement or a Passbook entitlement. In-app purchase product IDs on the app must not match product IDs on any app in the recipient's account. TestFlight beta testing must be turned off for all beta versions.

Neither party's account may be in a pending or changing state, and both must have accepted the latest versions of their paid and free agreements. The Account Holder initiates the transfer and needs the recipient's Apple ID and Team ID — get both in writing before you begin.

What does Google Play require for a transfer?

Two essentials: both developer accounts registered and active, and the transaction ID for each of them. The transaction ID is the number generated when the developer account's registration fee was paid; it appears in the receipt email and, if that is gone, can be recovered from Google Payments history. If paid apps are involved, the target account also needs an active merchant account.

Google also expects the original account and the apps being transferred to comply with policy. Transferring an app that is under enforcement does not buy a clean slate; the problem travels with the app.

What happens to Firebase, Analytics and other integrations?

They do not travel, because they are not part of the app. The Play transfer moves the store listing; the Firebase project, the Google Analytics property and the Play Games Services configuration live in separate accounts. For those you add the target account with permissions on the Analytics property and as an Owner on the Cloud project.

This is the most commonly forgotten step, and it shows up weeks later: the app is live on the new account while analytics data still flows into the old one, or a key needs rotating and the Cloud project turns out to be one nobody can access.

Do reviews, installs and ranking survive?

Yes — that is the entire reason a transfer exists. The app stays the same app: ratings, reviews, install history and search ranking are preserved, and users keep receiving updates. What changes is the developer name shown on the store page and the payments profile the revenue flows into.

This is why “we'll just publish it again” is one of the most expensive sentences in store economics. A two-year-old app's rating average and install history start from zero on a new listing, and recovering that in ASO terms takes months.

What belongs in the contract before handover?

Which account the app is published from, and how the transfer happens at handover, should be written down before work starts. If the agency publishes from its own account, the contract needs three things: that the intellectual property belongs to the client, that a transfer will be executed within a defined period on request, and the circumstances in which signing authority and account ownership must be handed over.

Without those clauses the transfer stops being a technical procedure and becomes a negotiation. The party that owns the app has no leverage, because whoever the store account is registered to holds the app in practice.