Selling a shell account, merging two portfolios, or moving a successful app to a company account — every one of these comes down to the same thing: a Google Play transfer. The process looks simple from the outside, but it has a strict order of operations, and skipping one step can leave your app unpublished, your payments profile orphaned, or your signing keys in the wrong hands. This checklist covers both transfer types in 2026: moving an app to a different developer account, and handing over account ownership itself.
Part 1: App Transfer — The Official Path
Google's official mechanism is the app transfer request in Play Console. It moves an app (and everything attached to it) from your original account to a target account. Before you submit anything, run through these steps in order.
Step 1: Confirm policy compliance and service fee impact
- Both the original account and every app being transferred must comply with all Google Play policy guidelines — a policy-violating app will be rejected mid-transfer and can flag both accounts.
- If you are enrolled in the 15% service fee tier: when an app moves between accounts in separate Account Groups, its earnings count toward both groups' annual totals. A $100k app moved from Group A to Group B counts $100k against each group's first $1M threshold. Factor this into the price you pay for the account — and into your 2026 tax planning.
Step 2: Download reports you will need later
When an app transfers, your bulk export reports, payout reports, and earnings reports do NOT transfer with it. Download everything you might need from Play Console before submitting — after the transfer, the new account starts fresh reports from zero.
Step 3: Verify both accounts are registered and active
- Original account: you can sign in normally.
- Target account: registration complete — no "Why can't I publish" message in the app header. If the target is a brand-new account, remember the US$25 registration fee applies. (Good news: after a completed transfer, Google support can refund the original account's registration fee if you close it.)
Step 4: Collect both registration transaction IDs
You need the registration transaction ID for your account AND the target account. Find it in the account owner's email (search for "developer registration fee") or in Google Payments → Activity. Common ID formats:
01234567890123456789.token.0123456789012345
0.G.123456789012345
Registration-1234ab56-7c89-12d3-4567-8e91234567f8
PDS.1234-5678-9012-3456
Critical: when entering the ID in the transfer request, strip the order-ID prefix — drop the 0.G. part and everything before the word token or Registration.
Step 5: Sort out Play App Signing keys
- Upload key: if you don't want the target account using your current upload key, the new owner can request a replacement upload key after transfer.
- App signing key: if key security is a concern, the target account can request a key upgrade for new installs — Google then signs new installs and updates with a fresh key. Review the implications before requesting, because old installs are affected.
Step 6: Check paid apps and IAP requirements
- The target account needs an active payments profile to receive paid apps or apps with in-app products.
- If the target account uses a different default currency: IAP apps get unpublished automatically after transfer until you verify new prices and republish. Paid apps get prices converted automatically. Plan a republish window so your users aren't left hanging.
Step 7: Re-wire integrated services
- Google Analytics: add the target account as a permission holder.
- Google Developers Console projects: add the target account as an Owner.
- Firebase: unlink projects from the original Play Console account, link them to the target.
- AdMob / ad SDKs: ad traffic is credited by the SDK inside the APK — you must update ad SDK integration and ship an update so revenue lands in the correct account.
- In-progress translations via Google Play's translation service must be completed before transfer.
- Managed Google Play private apps: temporarily unpublish and remove organization restrictions before transfer; the app is re-published by support with minimal downtime.
Step 8: Know exactly what transfers — and what doesn't
Transfers: users, download statistics, ratings and reviews, content ratings, store listing, subscriptions, policy submissions and app-content documentation.
Does NOT transfer: bulk export / payout / earnings reports, promotions (though already-issued promo codes still work), test groups (recreate them — testers must opt in again), and integrated-service permission settings.
Orders created before transfer stay in the original account — refunds for those must be issued from the original account or via the Developer API.
Step 9: Submit and wait
Submit the transfer request in Play Console. The target account owner reviews and approves it, then Google support confirms — replies typically land within 2 business days.
Part 2: Account Ownership Transfer
If you're not moving apps but handing over the whole developer account (a common shell-account sale), note the limits:
- Google does not officially support changing the legal owner of an Individual developer account. The registered name, tax identity, and payments profile stay with the original person.
- The practical handover path is: transfer each app to a target account (Part 1), then optionally close the original account and claim the $25 registration fee refund.
- For Organization accounts, ownership can change via Play Console user management — invite the new owner as an admin, then remove the old one. Update the payments profile and tax info to match the new controlling entity.
- ⚠️ 2026 risk note: account correlation scoring is active. Moving many apps in a pattern that mirrors your old portfolio can link the new account to the old one. If your goal is isolation (e.g. separating a risky vertical), transfer apps gradually and keep metadata, devices, and payment methods genuinely distinct — otherwise the transfer itself can become a correlation signal.
Final Pre-Submit Checklist
- Both accounts active, target registration complete
- Transaction IDs collected for both accounts, prefixes stripped
- Reports (bulk export, payout, earnings) downloaded
- Payments profile active on target (paid/IAP apps)
- Upload key / signing key decision made
- Firebase, Analytics, Developers Console, AdMob re-wired
- Currency-change republish plan ready
- Transfer request submitted → target approval → Google confirmation
- After transfer: republish if needed, ship ad-SDK update, recreate test groups, verify new reports are generating
A transfer done right takes about a week and causes zero user-facing disruption. A transfer done wrong takes a month of appeals to undo. Run the checklist, verify every line, and your apps — and your accounts — land exactly where you intended.