How to Transfer an App to Another Developer Account

The app can move while the business stays behind

Imagine a small nursery whose ordering app was published from an agency's developer account. The owner wants to bring releases in-house. Customers can still place orders, and the store listing looks healthy, so it is tempting to treat the transfer as an administrative click. The photograph above is an illustrative scene, not an Appfyl client case. The real risk is less visible: the listing changes owner, but the next update still depends on somebody else's Firebase project, signing key or backend login.

This guide is about the store-account move and the first release afterwards. For the wider question of source code, design files, databases and operational knowledge, use the mobile app handover checklist. You need both when changing agency or buying an existing app.

First decide what is actually changing

There are three different requests that people call “transfer the app.” If the same company will continue owning the developer account and only the agency changes, invite the new team with appropriate roles and remove the old access after a verified handover. If the app itself belongs in another company or account, use each store's formal app-transfer flow. Transferring ownership of an entire developer account is a different, wider operation and should not be used as a shortcut for moving one app.

Put the intended owner in writing before touching a console. Which legal entity owns the app and the customer relationship? Who can approve a release, see financial reports, manage subscribers and respond to store notices? The WIPO handbook on mobile-app contracts is useful context for defining responsibilities, but it is not a substitute for advice on your own agreement. Store access is evidence of operational control, not by itself proof that all intellectual-property rights have been assigned.

What Apple and Google actually move

Apple's transfer overview says the app remains available, retains its Bundle ID, reviews and ratings, and users can continue receiving updates. Google Play says the receiving account gets the app's users, listing, download statistics, ratings, reviews and related subscriptions. Neither statement means that a private Git repository, hosting account or support inbox follows automatically.

This is a planning map, not an assertion that every configuration transfers identically. Read the current Apple eligibility rules and Google Play transfer instructions for your specific app immediately before starting.

Prepare the receiving account before inviting a transfer

For Apple, both accounts must be in good standing and have accepted the latest applicable agreements. The app needs a version already released to the App Store; a live pre-order or certain in-review states block transfer. The transferring Account Holder starts the process and the receiving Account Holder accepts it. Do not schedule a store submission and an ownership move for the same hour: close or postpone the release first, then confirm eligibility.

For Google Play, both accounts must be registered and active. The help page asks for the developer-registration transaction IDs; paid apps or apps with in-app products require the target account to have an active payments profile. Download reports you will need later. Google explicitly says bulk export, payout and earnings reports do not move with the app, and orders created before the transfer remain with the original account. Decide who will handle historical refunds and how the finance team will retain access to those records.

The owner should also have access to the business email, support address, privacy-policy domain and any organization verification required by the destination account. Use named roles, not a shared password sent over chat. The development contract checklist helps make ownership and release responsibility explicit before a dispute appears.

List the connections that do not follow the store listing

Start with the installed app as it exists today, not a generic transfer template. A subscription app needs a different preflight from a free information app. Apple requires an app-specific shared secret for an app with auto-renewable subscriptions; the receiving side needs it for server verification and should generate a new one after the move. If the app uses Sign in with Apple, the old team must prepare a transfer identifier for each user before the transfer. Keychain sharing can change on the next update, potentially requiring users to sign in again. Push certificates, Apple Pay merchant IDs and Wallet passes have their own follow-up work. Apple's overview describes these special cases in detail.

On Google Play, test groups cannot be transferred and may need to be recreated. Google also tells developers to reconfigure links to Firebase, Google Analytics and other integrated services; ad integrations may require an app update. Check the upload key and app signing arrangements before the old team leaves. If the app is paid or uses in-app purchases, inspect the receiving payments profile and published prices after the transfer. Do not assume a store console change also changes the owner of Firebase, cloud hosting, domain DNS, transactional email, maps or customer-support tools.

This is where a technical audit of the existing app earns its keep. Write down each system, current owner, new owner, access method, renewal date, recovery option and acceptance check. Keep credentials in a controlled vault and rotate them at the agreed point. A list of passwords without a successful independent login test is not a handover.

Make the move in an order that can be tested

First, the receiving team should inspect a release candidate and prove it can build the app using handed-over source and dependencies. Back up the old store reports and export the records the next owner will not receive. Record the app identifiers, store links, active subscriptions, integrations and any open review or policy issues. Then complete store-specific eligibility checks and agree on a quiet transfer window, with one named decision-maker on each side.

The Apple Account Holder initiates the transfer in App Store Connect. Apple's recipient instructions say the receiving Account Holder must accept within 60 days and supply updated support, privacy and review-contact details where required. After acceptance, Apple says completion can take up to two business days, and the new account must create provisioning profiles for subsequent builds. On Google Play, the current account submits the transfer request, the target developer approves it, and Google reviews it. Follow the live console instructions rather than relying on a screenshot from an older blog post.

The important pause comes after the store marks the transfer complete. Do not immediately remove the former team's access to every service. Confirm that the new owner can log in independently, manage the listing, see the correct subscription and payment settings, receive alerts and prepare a new build. Only then rotate credentials and close old access according to the handover agreement.

Prove continuity with a real customer journey

Consider a courier app after its Play listing has moved to the new company. An engineer can open Play Console, but that does not prove the courier receives an order, the customer gets an update or the dispatcher can resolve a failure. The second photograph illustrates this type of field check; it is not a claim about a client project.

Run one end-to-end scenario on the existing published version and one on a new test build. For a course app, sign in as an existing learner, open a purchased lesson, restore access, trigger an expected notification and check the support route. For a booking app, make and cancel a test reservation. Compare event and server records, not only the success screen. If customer records need to move between backends too, that is a separate data-migration project, not something the stores perform.

The final acceptance test is an update prepared and released by the receiving team, using its own controlled build process. A staged rollout can limit exposure while you watch crashes, purchases and core actions. Keep the former owner available for a defined support window until the new team demonstrates that independence.

When not to press the transfer button yet

Pause if the receiving account is incomplete, nobody can reproduce the build, a subscription verifier belongs to the seller, or users depend on an Apple capability whose post-transfer behavior has not been tested. Pause too if the parties disagree about data, code or financial-report ownership. The store transfer may be technically possible while the business handover is not ready.

If you want Appfyl to assess a takeover, bring the current store links, who owns each account, source-code access, integrations, payment and subscription setup, and the first update you need to ship. Appfyl can use a short project brief to identify the missing evidence and plan the next release. A transfer should finish with a team that can operate the product, not merely a new name in the store.

Questions people ask