A user base does not move to a new app. The app record moves, or nothing does.
Moving a user base to a new app is not a thing either store does. Apple and Google both document one supported move, and it is the same one: transferring an app record you already own to a different developer account, with its users, its ratings and its reviews attached. Neither documents any way to carry users, purchases or reviews from one record to a second record. A second record is a second app. New identifier, zero ratings, no purchase history, no restore. Everything below comes from App Store Connect Help and Play Console Help, read on 16 October 2026.
So the first job is working out which move you are asking for, because most reasons for wanting a new app are answered by the one you have. Then what each store's transfer carries and quietly drops. Then, if you genuinely need a second record, the migration you have to write yourself. The part people skip is the purchases.
Start hereThe short version
The record is the asset. Do not abandon it.
Your downloads, your ratings, your reviews and every purchase ever made sit on one app record, keyed to one identifier. Both stores will move that record to another account and keep all of it. What neither store has is a way to point any of it at a different record. There is no merge, no redirect and no import.
The practical test is the identifier. If the bundle ID and the Android application ID stay the same, you are shipping an update, however little of the code survives, and you keep everything. If either one changes, you are launching. Google says it plainly in its own Android build documentation: once you publish your app you should never change the application ID, because the Play Store treats a changed one as a completely different app, and an update must use the same application ID and signing certificate as the original.
What are you actually trying to move?
Almost nobody wants a new app record. They want something else and assume a new record is how you get it. A new name is metadata, so you edit it. A new owner is a transfer, so you fill in a form. A new price, a new paywall or a whole new business model is the same record with different products attached, and if that is the real question then app monetisation is the thing to read and not this. Even a complete rewrite ships as an update, because the stores do not care how much of the code changed.
Two reasons do force a second record. The first is a change of identifier, usually because the original one carries a company name you no longer use or a typo you have lived with for two years. The second is a split, where one app becomes two products and the second one needs its own listing, its own reviews and its own price. There is a third that is not really a choice: an app pulled for a policy breach. Apple says that once you remove an app record you lose ownership of the app name, the SKU cannot be reused in the same organization, and if you have uploaded a build the bundle ID cannot be reused either.
Be honest about which one you are in before you tell anyone a date. A transfer has criteria, and they bite. Apple requires that the app has had at least one version released to the App Store, that it is not on pre-order anywhere, and that it is not sitting in Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release or Pending Apple Release. Apple Arcade apps cannot be transferred at all.
App Store Connect Help, overview of app transfer, read 16 October 2026
Check yours
Which move you are actually asking for
Tick the reason you want a new app. Most of these do not need one, and the two that do cost you the user base.
Nothing ticked. Start with the reason rather than the mechanism. Six of the eight reasons above are answered by the app record you already own.
What does Apple's app transfer actually carry across?
The headline is good. Apple says you can transfer your app while keeping it available for download, that during and after the transfer the app retains its reviews and ratings, and that users continue to receive updates. The app keeps its bundle ID, and the associated App ID moves into the recipient's developer account once they accept. If the app stores user data in iCloud, the containers and key value store identifiers move too. Nobody has to reinstall anything and nobody notices.
The mechanics are a form. The Account Holder opens the app, clicks App Information, scrolls to Additional Information and clicks Transfer App, then enters the recipient Account Holder's Apple Account and Team ID. The app gains a Pending App Transfer status next to whatever status it already had, and the request expires after 60 days if nobody accepts. While it is pending you cannot edit metadata, pricing, availability or in-app purchases, and any open App Review conversations are closed. The step-by-step version lives in transferring an app to another account.
Now the things that get dropped, because this is where a transfer stops feeling free. TestFlight beta testing has to be turned off before you initiate, and Apple's way of doing that is removing every build and every tester, so your beta group is gone. All Xcode Cloud data attached to the app must be removed first. Nominations do not transfer. The Apple Pay merchant ID does not transfer. Wallet passes have to be reissued under new identifiers. And after the transfer nobody can generate new promo codes for that app.
The money and the history split down the middle. You keep access to sales and payments from before the transfer; the recipient only sees transactions after it. You lose the app in App Analytics while the historical numbers stay in Sales and Trends. The recipient gets analytics data from 1 April 2015 or from the day the app first went live, whichever is later. Two details decide whether the day goes smoothly. If the app sells auto-renewable subscriptions, the sender generates an app specific shared secret before starting and the recipient gets hold of it before accepting, or server side receipt validation breaks the moment it lands. And no in-app purchase product ID on your app may match a product ID on any app already in the recipient's account.
What does Google Play's transfer carry, and what does it drop?
Google's version is a request rather than a switch. You submit a transfer request, the receiving developer reviews and approves it, and Play Console Help says Google replies to transfer requests within 2 business days. You need the target account's registration transaction ID, and if that account is new, registering it costs 25 US dollars. Both the original account and every app being transferred have to comply with policy, and both accounts need to be active and fully registered.
What moves is generous. Users, download statistics, ratings and reviews, content ratings and the store listing all go with the app. Subscriptions and other app data move. Declarations you already filled in, including App content submissions, come along, which saves a week of form filling. Registered package names and their associated keys move for developer verification. Promo codes already issued should keep working, although promotions themselves do not transfer.
What drops is specific enough to plan around. Bulk export, estimated sales, payout and earnings reports do not move, so download anything you need first. Orders created before the transfer stay in the original account. Test tracks do not transfer at all: open, closed and internal testing groups and internal app sharing are gone, and closed testing groups have to be rebuilt by hand, which matters if you were running a staged rollout on Google Play through them. Linked services need redoing by hand too: Analytics permissions, Google Cloud project owners, Firebase links, and any ad SDK that has an account ID compiled into the build.
Two money details catch people. If the app is paid or sells in-app products, the receiving account needs an active payments profile before the transfer, and the default currency may change, which silently repoints prices. An app that sells only in-app products gets unpublished until the new owner republishes it. Finish any translation work in progress first, and if the app sits in the 15 percent service fee tier, note that its earnings count towards the yearly totals of both account groups in the year of the move.
Play Console Help, transfer apps to a different developer account, read 16 October 2026
If you do need a second record, how do people get across?
One person at a time, by choosing to. There is no mechanism, so the whole migration is four things you build. Keep the old app on sale and working. Ship one more update to it whose only job is to explain the move and open the new listing. Carry identity across in your own backend, because an account you host is the single thing that survives a change of identifier. And decide, in advance, what you are giving people who already paid.
Keeping the old app alive is cheap and the stores help. Removing an app from the App Store in all countries takes effect within 24 hours, and Apple says the people who already downloaded it keep receiving updates and can redownload it from their purchase history for as long as the necessary contract stays active. Google says that an unpublished app can still be used and updated by existing users while new users will not find or download it. So you can stop new installs on the old record without cutting off the people you are trying to move. What you must not do is remove the record itself: that costs you the app name, and Apple restores a removed app only if that name is not in use by another developer account.
The pointer update is the part people get wrong. A hard blocking screen on the old app annoys the loyal and teaches nobody. One dismissible banner, a plain sentence about what changes, and a button that opens the new listing does more. Ship it as a small release rather than bundled into other work, and watch the old app's crash rate for a day afterwards, because a late screen wired into a launch path is a classic way to break a build that was fine for a year. If it does break, debugging a crash is the faster route than guessing.
Purchases are the honest problem, and there is no clean answer. Apple's own in-app purchase documentation says every in-app purchase must be associated with an app, that it can be shared across platform versions such as iOS, macOS and tvOS, and that in-app purchases are not shareable between different apps. So a lifetime unlock bought in the old app cannot be restored in the new one. You honour it from your own records, by matching the account the person signs into, or you ask them to buy again and accept the reviews that follow. Apple does document one way for a single purchase to span apps, and it is worth knowing even though it is not a migration tool: a Suite can give subscribers access across up to 15 apps, a Bundle can hold up to 5 subscriptions across one app, several apps or up to five developers, and buying either requires StoreKit 2 and iOS 27, iPadOS 27, macOS 27 or tvOS 27 and later. That can cover an old app and a new one together. It still does not move anybody's existing purchase.
What survives a transfer, and what survives a new record
| What you are worried about | App Store transfer | Google Play transfer | Carries to a different record |
|---|---|---|---|
| Existing users | Keep the app and keep receiving updates | Move to the new account with the app | No |
| Ratings and reviews | Retained during and after the transfer | Move with the app, content rating included | No |
| In-app purchase products | Transfer, but no product ID may clash with the recipient's | Subscriptions and related app data move | No |
| Money already taken | You keep pre-transfer sales, the recipient sees later ones | Orders created before the transfer stay in the original account | No |
| Testers | TestFlight off first, every build and tester removed | Test groups do not transfer, closed groups are recreated | No |
| The identifier | Bundle ID is kept, and cannot change once a build is uploaded | Registered package names and their keys transfer | No |
| Analytics history | Recipient gets data from 1 April 2015 or first release, whichever is later | Statistics move, exported reports do not | No |
| Accounts in your own backend | Not part of the transfer, so not Apple's problem | Not part of the transfer, so not Google's problem | Yes |
Where this lands if a builder generated your app
It changes nothing about the store rules and quite a lot about the cost of the work. The identifier still decides whether you are updating or launching. The transfer forms are still the only supported move. What a generated project changes is who can ship the pointer update to the old app, and how quickly the new app gets built, because both are code and the code is yours.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync so a developer can work in the repository at the same time. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month and there is no free tier. It does not submit to the App Store for you, because Apple requires the owner of the content to submit, and that rule applies to the new record as much as the old one.
Two practical notes if you are running both apps at once. Because the project is a normal repository, the old app and the new one can be two branches of one codebase, which keeps the pointer update a ten minute job instead of a resurrection of a project nobody has opened in a year. And because Newly ships to internal testing and TestFlight rather than straight to the store, you can prove the new app works on real phones before you tell a single customer to move. The honest limit: no builder can migrate purchases, because the stores do not expose a way to do it.
Questions people ask about moving to a new app
Not through the stores. Neither Apple nor Google documents a way to carry users, ratings, reviews or purchases from one app record to a different one. Both document the opposite move: transferring an existing record, with its users and reviews intact, to another developer account. If you publish a second record you are publishing a second app, with its own identifier and no history. Anything that crosses between the two is something you build: an account system of your own, a pointer in the old app, and an entitlement you honour on your own server.
Check the identifier before you build anything
If the bundle ID and the application ID can stay, this is an update and you keep your users. If they cannot, plan a launch, keep the old app on sale, and decide what you owe the people who already paid.
Start building