GuideHow to Switch App Development Teams Without Losing Your Code

To switch app development teams without losing your code, get your company made owner of every account first, and only then talk about the switch. The code is rarely the hard part. The hard part is the repository, cloud, payment, domain and app store accounts the old team set up and still controls. This is the safe order:

1. Ownership first. Get your company made owner or admin of the repository, the cloud accounts, Stripe, the domain and DNS, and the Apple and Google Play developer accounts, before anyone hears about a switch.
2. Read the contract. Find the IP assignment clause (who owns the code) and the notice clause (how you end the work).
3. Snapshot the code. Tag the main branch and make a mirror copy of the repository, kept in an account you own.
4. Independent review. Have someone outside both teams review the code and accounts with read-only access, and write a migration plan with a fixed price for each phase.
5. Overlap, then rotate. Run both teams side by side for a short period, then remove the old team's access and rotate every key and password.

This guide is for a team that is still working. If yours has stopped replying, start with what to do when an app developer disappears instead. For the full list of what to collect, use the app handover checklist.

Why the order matters

The usual reasons for switching are high turnover, nobody who answers for the result, and no clear picture of who owns what. None of that is about where a team is based. Plenty of offshore teams run clean handovers, and plenty of local ones don't. The risk is the same everywhere: whoever holds the owner role on an account decides who else gets in.

If you announce a switch first, you are asking for ownership at the moment the other side has the least reason to hurry. If you ask first, it is a routine request that any well-run team should accept. Most do.

Step 1: who should own each account

Ask for owner or admin on each of these for a person at your company, using a company email address, not a personal one. Then check it yourself; don't take a screenshot on trust.

If an app sits in the agency's own Apple or Google Play account, it has to be transferred to yours. Apple and Google both have a transfer process, and it needs the current account to start or approve it, which is why you ask now, while relations are good. The Firebase ownership guide covers that project move step by step.

Step 2: read the contract

Two clauses decide how this goes:

• IP assignment. Under US law, code written by an outside contractor usually isn't a "work made for hire", since a commissioned work only counts as one if it falls in one of nine listed categories and both sides sign a written agreement saying so (US Copyright Office, Circular 30). Otherwise the contractor keeps the copyright until they sign it over, because a transfer has to be in writing and signed by the owner (17 U.S.C. 204). Look for a clause that assigns the code, designs and other work to your company, and check whether it applies on creation or only after final payment. Other countries have their own rules, so if the team is abroad or the clause is missing, ask a lawyer. This guide isn't legal advice.
• Notice and transition. How many days' notice ending the contract takes, and whether the team owes handover help (documentation, a call with the new team) during that time.

While you're there, list unpaid invoices on both sides. Paying what you owe on time keeps the handover about the work, not about money.

Step 3: snapshot the code

Once your company owns the repository, make two copies:

• A tag on the current main branch, for example pre-switch-2026-10-27, so everyone can point at the exact code that was handed over (git tag).
• A mirror clone (git clone --mirror), which copies every ref, including all branches and tags, not just the branch you're on (git clone). Keep it in storage your company owns.

Then check what a snapshot doesn't hold: the names (not values) of the environment variables the app needs, the build and CI settings, where the Android signing key and the iOS certificates live, and the database. The handover checklist lists each item.

Step 4: get an independent review and a phased plan

Before the new team commits to anything, have someone outside both teams look at the code and the accounts with read-only access. You want three things out of it:

1. What you actually have: whether it builds from a clean copy, what's tested, what's fragile, and which accounts are still missing.
2. A migration plan in phases, for example accounts, then build and deploy, then the first fixes, so each phase ends with something you can check.
3. A fixed price for each phase, so you can stop after any phase without a large bill for unfinished work.

Read-only access is enough: a repository invite, a test login and viewer roles on the cloud project. Nobody needs production passwords for a review.

Step 5: overlap, then rotate credentials

Plan a short overlap where both teams have access, the old team answers questions and the new team runs a full deploy on its own. Don't rotate keys during this period; it breaks the old team's work without warning and muddies who broke what.

When the new team deploys without help, close the overlap the same day:

1. Remove the old team's accounts from the repository, cloud projects, Stripe, the registrar and both app stores.
2. Roll API keys and secrets they could see. Stripe lets you roll a secret key and keep the old one working for up to 7 days while you update your servers (Stripe). Do the same for cloud service account keys, database passwords and third-party API keys.
3. Check for leftovers: deploy keys and webhooks on the repository, OAuth apps, and any email forwarding or DNS records pointing at the old team's systems.

Getting help with the switch

• Collect what you need with the free app handover checklist.
• If the app was built with Lovable, Bolt, Cursor or another AI tool, the AI-Built App Rescue starts with a $450 Launch Check from read-only access, and its report includes a fixed quote for the fixes.
• If you need one developer to take the app over for good, the Monthly Dev Subscription starts at $1,495 a month, one request at a time, and you can pause or cancel anytime.

Not sure where you stand? Send me a short description of which accounts you own today and what the old team still controls, and I'll tell you where I'd start.