The process itself takes ten minutes. Finding the one number Google asks for can take an afternoon of digging through old email. Here is the whole thing, including the part that catches everyone.
The transfer itself is a short form. Open the Play Console, enter three numbers, submit. Google replies within two business days and the app moves with its reviews, ratings and install base intact.
The part nobody warns you about is one of those three numbers. Google asks for the registration transaction ID of both accounts, which is the order ID from the $25 payment made when each account was first created. For an account set up years ago by someone who may have left the company, that number is sitting in an old inbox, and finding it takes longer than the rest of the process combined.
We have run this transfer for client apps. Below is the whole sequence, with the transaction ID hunt covered properly.
Five things. Gather all of them before you open the form, because a half-finished request is worse than no request.
Download your reports first. Bulk export, payout and earnings reports do not move with the app, and once the transfer completes you cannot go back for them.
In the account owner's email, or in Google Payments. This is the step that turns a ten-minute job into an afternoon.
Search the inbox of whoever created the account for "developer registration fee". If that fails, sign in to Google Payments, open Activity, and search for "Google Play Developer". The charge is $25, one-time, dated whenever the account was created.
Then the detail that causes most rejected requests: strip the prefix. Order IDs come in a few shapes, and you submit only the part after the prefix.
If the person who set up the account has left, this is a real blocker rather than an inconvenience. Whoever now controls that mailbox needs to search it, or the account owner needs to pull the record from Google Payments.
Play Console → Settings → App transfer, from the account that currently owns the app. The form asks for the target developer ID and both transaction IDs, plus a reason for the transfer and your business relationship to the receiving party.
Pick the apps to move, submit, and the request goes to the receiving account to accept. Once they accept, it sits as Pending while Google reviews.
Google reviews within two business days. End to end, a few days is normal once the paperwork is right. The app stays live throughout. Users do not see anything change, reviews and ratings survive, and updates keep flowing.
The account was created years ago, possibly by a contractor or a founder who has since left, and nobody knows which inbox holds the receipt. Without it the transfer cannot proceed at all.
This is the single most common reason a transfer stalls, and it is entirely an email archaeology problem rather than a technical one.
The request is submitted with the full order ID including its 0.G. or token or Registration prefix, and it fails verification.
The error message does not always make it obvious that formatting is the problem, so people re-check the number itself rather than the shape of it.
Firebase, Analytics, AdMob and any ad SDKs are linked to the old account, not to the app. They do not follow it across and they do not warn you.
The app keeps working for existing users, so the breakage shows up later as missing analytics or stalled ad revenue rather than as an outage.
The listing, reviews, ratings, install base and update channel all survive. These do not:
One structural limit: private apps created through the managed Google Play iFrame cannot be transferred at all.
If you are moving a product between companies you almost certainly need to move both stores, and Apple's process is a different shape. It has no transaction ID, but it has a much longer list of things that block a transfer outright, including TestFlight, Xcode Cloud data and Apple Pay merchant IDs. It is a different process, and we have written it up separately.
