Protecting Your IP When You Change Development Teams: A 2026 Handover Checklist

When you change development teams, take back the accounts first, then the code, then the knowledge. Whoever holds the repository, the app store accounts, the cloud and the domain controls your product day to day, even when the contract says it’s yours. Before you tell the old team, list every account the product depends on and whose name it is in. Then move each one to your company, check that the new team can build and release the product without help, and only then switch off the old team’s access.

This is general information, not legal advice. If your contract is unclear about who owns the code, show it to a lawyer before you act.

What goes wrong in a handover

The same problems come up again and again when founders bring a project to us:

• The code sits in the old team’s or one developer’s personal repository.
• The App Store or Google Play account is in the agency’s name.
• The contract says nothing about who owns the work.
• Secret keys and server passwords live in one person’s head.
• Nothing explains how to build, test and release the product.

Any one of them can stop a new team from shipping. Most are quick to fix while the old team is still cooperating, and slow to fix after.

Step 1. Read the contract before you say anything

Find the clause that says who owns what the team makes. In the US, the Copyright Office’s Circular 30 lists the kinds of commissioned work that can be “made for hire” with a signed agreement, and software isn’t on that list. So a contractor’s code normally becomes yours only through a written transfer of rights. If you can’t find one, ask a lawyer before you announce the change. Our IP checklist for startup founders covers how to set this up from the start.

Step 2. List every account and who holds it

Write one table: the asset, where it lives, who is the owner, who has admin access. Include the code repository, cloud hosting, domain and DNS, Apple and Google developer accounts, the payment account, email sending, analytics, error tracking and any paid APIs. This list is your plan for the rest of the handover.

Step 3. Move each account into your company

Some platforms let you transfer an asset. Others only let you add a new owner. The three that matter most for an app have published rules:

Asset	How it moves	What moves with it	What stays behind or needs redoing
Code on GitHub	An admin transfers the repository; a transfer to a personal account must be accepted within one day	Issues, pull requests, the wiki, stars, watchers and the full commit history; webhooks, secrets and deploy keys stay attached	GitHub Pages redirects; the target can’t already have a repository with the same name
iPhone app	The old Account Holder starts an app transfer in App Store Connect and your Account Holder accepts it	Reviews and ratings; users keep getting updates; the bundle ID	The Apple Pay merchant ID; sales data from before the transfer; the app leaves the old account, so back up its information first
Android app	The old account requests the transfer, your account owner approves it, and Google reviews it within two business days	Users, ratings and reviews, store listing, subscriptions	Earnings reports and orders from before the transfer; links to Firebase, Google Analytics and Google Cloud must be redone by hand

For the Google Play transfer, you need the registration transaction ID of both developer accounts, so find yours early. For the cloud, the domain and payments, the safest route is usually to open the account in your company’s name and have the old team move the resources into it, rather than taking over an account registered to them.

Step 4. Get the code, and prove you can build it

Ask for the full repository with every branch and the whole history, not a zip of the latest files. Then have someone other than the old team build the product from scratch, run the tests and deploy to a test server. If that fails, you have found the missing parts while the old team can still answer questions.

Step 5. Collect the knowledge

Ask for short written notes on how the product is built, how to release it, what the main outside services are and which bugs are known. A recorded call where the old team walks through the code and the setup is often worth more than a long document.

Step 6. Change every secret, then close access

After the new team confirms it can build and release, remove the old team from every account and change every password, API key and token they could see. Until you do, people who no longer work on the product can still reach your data.

Step 7. Have the new team read the code before it commits to a plan

A new team shouldn’t promise dates for code it hasn’t read. Our software project rescue starts with a code and architecture audit at a fixed $3,500, done in 5 working days. The report lists the accounts the product depends on and whose name they are in, the state of the code, security problems with the worst first, what to keep, fix or rebuild, and a takeover plan with hours for each fix. After a takeover, the code, the designs and the accounts stay in your company’s name.

If the old team won’t hand things over

First, check with your lawyer what the contract says about ownership. If you still can’t get the code, a new team can work from what you have: the live app, the designs and any documents. Then the plan is a rebuild, with the old app as the spec. Accounts already registered to your company are much harder to hold back, which is why steps 2 and 3 matter so much.

What our takeovers looked like

• LIVETAG, a live shopping video platform, came back to us after another contractor. We put together a team for the stack the previous contractor had chosen and delivered in two rounds: refactoring on every platform first, then the new features.
• On Humm.ly, a music therapy app, the front-end developers left suddenly. We stepped in at short notice, then went on to rework the backend and build the mobile app.

LIVETAG and Humm.ly were fixed and kept going. Other takeovers, such as YOU(th), LEV and Dusfer, ended in a rebuild.

How we would estimate the work that’s left

1. Our project estimate turns your brief into user stories. You confirm what is in scope, and every hour in the budget traces back to a story you kept.
2. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour.
3. It is a planning range, not a fixed quote. For inherited code, the audit’s takeover plan replaces the range with hours per fix.

You can get a free project estimate for the work that’s left in about four minutes, before you ask anyone for a quote.

What we would do

1. Read the ownership clause, with a lawyer if it is unclear.
2. List every account and who holds it.
3. Move the accounts into your company before you announce the change.
4. Get the full repository and have someone else build and deploy it.
5. Collect notes and a recorded walkthrough.
6. Remove the old team’s access and change every secret.
7. Have the new team audit the code before it promises dates. If it comes from our staff or pool, it can start in 3 to 5 days, or within 2 weeks if we hire someone new.

For choosing and onboarding the new team itself, see our guide on what you need to know when replacing your development team.

FAQ

How do I get my source code back from a development agency?

Check the ownership clause in your contract first, with a lawyer if it is unclear. Then ask for the full repository with all branches and history, or a transfer of the repository to your company’s account. This is general information, not legal advice.

Can an iPhone or Android app be moved to another developer account?

Yes. Apple lets the current Account Holder start an app transfer in App Store Connect, which your Account Holder accepts. Google Play transfers are requested by the old account, approved by the new one and reviewed by Google within two business days.

What doesn’t move when you transfer an app?

On the App Store, the Apple Pay merchant ID and sales data from before the transfer stay behind. On Google Play, earnings reports, earlier orders and links to Firebase, Google Analytics and Google Cloud have to be handled separately.

What should a handover from a development team include?

Admin access or transfer of every account, the full code repository, notes on how to build and release, a walkthrough of the code, and new passwords and keys once the old team’s access is removed.

What if the old team refuses to hand over the code?

Ask a lawyer what your contract says. If you still can’t get it, a new team can rebuild from the live app, the designs and any documents, using the old app as the spec.

Turn your assumptions into a project brief

A team transition needs repository access, build instructions, credentials handover and review of actual IP agreements. Use our dedicated-team service and the Livetag case to frame delivery questions; contract interpretation still belongs with qualified legal advisers. Explore dedicated development team and the Livetag case study.

Discuss technical handover and ownership risks

Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.