Transferring an App to Another Google Play Developer Account? Check What Moves — and What Breaks.

What Google requires for a transfer

• Both developer accounts are registered and active; you need the registration transaction ID of each (search the account email for “developer registration fee”, or find it in Google Payments → Activity).
• “The original account and all apps being transferred must comply with all policy guidelines.” An app with an open policy issue or a suspended account cannot be transferred first and cleaned up later.
• For paid apps or apps with in-app products, the target account needs an active payments profile.
• Integrated services — Google Analytics, Firebase, Play Games Services, AdMob — must have their permissions and links updated before the transfer.
• The target developer approves the request in Play Console; Google support reviews it within 2 business days. Plan the transfer as a one-way move — Google’s transfer guide describes no way to undo a completed transfer, and nobody can promise you a way back.

Source: Play Console Help, Transfer apps to a different developer account (verified 22 September 2026).

What transfers — and what does not

What breaks unless you prepare it

Firebase and Google Cloud

The Firebase project is not part of the Play transfer. If the new owner is not made an Owner of the Firebase / Google Cloud project, they lose Crashlytics, Analytics, Cloud Messaging, Remote Config and Authentication overnight — or they keep working while the old owner retains full control of user data. Either transfer project ownership, or plan a project migration (new project, new google-services.json, migrated Authentication users, re-issued FCM credentials).

SHA-1 / SHA-256 fingerprints and Google sign-in

Google Sign-In, Firebase Auth phone/Google providers, Maps and other Google APIs are authorised against the fingerprint of the certificate the distributed build actually carries — under Play App Signing, the app signing key Google holds. That distinction decides how much work a transfer creates:

• Upload key reset only — Google keeps signing releases with the unchanged app signing key, so the certificate on installed and newly downloaded APKs is the same as before and registrations matched against it keep working. Update only the places where the upload certificate itself was registered.
• App signing key upgrade — which certificates sign new installations and updates depends on the upgrade option chosen and on the device's Android version, so there is no single new-installs-versus-existing-installs rule to rely on. Read your own App signing page in Play Console, register the applicable new fingerprints with every affected API provider, and keep the older registrations in place wherever a build that uses them is still being served.
• Debug and directly distributed builds — check the certificate on the actual APK. Debug builds normally use a debug certificate; directly distributed APKs may be locally signed or downloaded already signed from Play Console. Register the fingerprints required for the build and API provider you actually use.

The practical instruction is therefore conditional: read the App signing page in Play Console for the current upload and app signing certificates, then compare each API registration against the build it is meant to authorise. A blanket fingerprint rotation after a transfer is usually unnecessary work, and it can break the registrations that were correct.

AdMob, Play Games Services, Analytics

Each is linked to a Play app under an account. Re-link them to the target account before the transfer or the links break; AdMob app IDs remain in the build, but reporting and payment ownership follow the AdMob account, which is a separate decision.

In-app products, subscriptions and the licence key

Products move with the app, but the receiving account needs a payments profile first, and any backend that verifies purchases with the Play Developer API needs a service account under the new account with access granted to the app. The app’s Base64 licence key stays with the app.

Upload key and Play App Signing

The upload key and app signing key serve different roles. Under Play App Signing you sign the bundle with the upload key so Google can verify who you are; Google then signs the APKs that reach users with the app signing key it holds. A transfer moves the app signing key with the app, so installs and updates continue untouched. The upload key, however, is a file the previous owner still has. If continued use of the existing app signing key is a concern, review the receiving account’s key-upgrade options in Play Console; the certificates used for installations and updates depend on the upgrade configuration and Android version, as explained above. If the app is not on Play App Signing, the new owner must receive the original keystore and password or cannot publish updates at all — see lost keystore or upload key.

Developer verification

Under Android developer verification, the registered owner of a package is the account that holds it and can prove the key. A transfer moves the registration; the receiving account must itself be verified (organisation accounts need a D-U-N-S number).

Common scenarios

Recommended sequence

1. Confirm both accounts are active and verified; collect both transaction IDs; set up the payments profile on the target.
2. Inventory integrations: Firebase/Cloud project, OAuth clients and fingerprints, AdMob, Play Games, Analytics, backend service accounts, push credentials, licence key.
3. Grant the new owner Owner access on Firebase/Cloud; re-link AdMob/Play Games/Analytics to the target account; hand over or plan the upload key.
4. Submit the transfer request from the source account; accept it on the target; wait for Google’s confirmation.
5. After the transfer: create a service account under the new account for the backend, recreate tester groups, and decide whether to reset the upload key or upgrade the app signing key. Update fingerprints in the Google API projects that the change actually affects — see the conditions above — rather than rotating all of them.
6. Ship a small update from the new account to prove the whole chain works.

Before you rotate anything: what actually changed?

Most post-transfer breakage — and most wasted post-transfer work — comes from answering these five questions wrongly. Answer them from Play Console and your API consoles, not from memory:

• Did only the Play developer account change, or did anything about the app itself change with it?
• Did ownership of the Firebase / Google Cloud project or access to its OAuth clients change?
• Was the upload key reset — which changes what Play accepts on upload, and nothing else?
• Was the app signing key upgraded, and which certificates apply to installations and updates on the affected Android versions?
• Which build and distribution channel is the failure actually being reproduced on: a Play release, internal app sharing, a debug build, or a directly distributed APK?

Transferring the iOS version too? The Apple side has different criteria and its own migrations — see App Store app transfer.

Checklist

• Both accounts active and verified; transaction IDs collected; payments profile on the target
• No open policy issues on the app or the source account
• Firebase / Google Cloud ownership transferred or migration planned
• AdMob, Play Games Services and Analytics re-linked
• Upload key decision made (hand-over vs reset); Play App Signing status known
• Backend service account and purchase verification moved to the new account
• Signing change identified (upload key reset, app signing key upgrade or neither), and OAuth clients and API restrictions updated only where that change affects them
• Tester groups recreated; a post-transfer update published successfully

How App Rejection Fix can help

Google moves the listing, the install base and the Play-held app signing key, which stays associated with the app — so existing installs keep updating. What does not move is everything around it: ownership of the Firebase and Google Cloud project, custody of the upload key file, permissions on AdMob, Play Games and Analytics, and the service account your backend verifies purchases with. That is the part that breaks releases weeks later.

• Pre-transfer inventory: Firebase and Google Cloud project ownership, SHA-1 and SHA-256 fingerprints, OAuth clients, AdMob and Play Games links, Play Console service accounts, subscriptions and the payments profile on the receiving side.
• Signing decision: whether the upload key is handed over or reset, whether an app signing key upgrade is warranted, and which API registrations each of those actually affects — see lost keystore or upload key if the old key is gone.
• A sequenced cut-over so sign-in, push and purchase verification are not broken between the transfer and the first update.
• Backend work: moving purchase verification to the receiving account’s service account, updating API restrictions and fingerprints, re-pointing analytics and crash reporting.
• The first post-transfer release, built and tested, to prove the chain actually works end to end — including developer verification registration under the new account.

We cannot promise that a completed transfer can be rolled back, or that Google would approve a later transfer back — ask Play Console support what is available for your case. Account ownership and verification stay with you. The initial review is free; migration work is scoped and quoted separately. Google decides whether the transfer request is approved.

Frequently asked questions