Sometimes an agency closes. Sometimes a freelancer takes a full-time job. Either way the business still depends on the app, and a list of features everyone wanted last month is waiting. The safest way to take over an application from another team is to do the dull things first: make sure the business owns the accounts, prove you can run and ship the app, map it, find what is fragile and fix that, and only then build.
This application handover checklist follows that order, and each step depends on the one before it. A team that doesn’t yet understand a system can easily break things it didn’t know were connected, which is the reason for slowing down at the start.
Make sure the business owns the accounts
Missing access is the biggest risk in a handover, and in our view the cheapest to fix while the previous team still answers email. Check who owns each account. It should be the business, not a person.
- The code repositories, with full history
- Hosting, cloud and database accounts
- The domain registrar and DNS
- Apple and Google developer accounts
- Payment, email, analytics, maps and push notification services
- Secrets and environment settings for every environment
The app store accounts deserve extra care, because moving an app depends on the old account taking part. Apple’s app transfer rules say the membership Account Holder starts a transfer and the receiving Account Holder accepts it. Google Play’s transfer page says both accounts must be registered and active, and the original account must be able to sign in. Several things need attention before either transfer:
| Item | Apple | Google Play |
|---|---|---|
| Back up first | App information, because the app leaves your account | Earnings, payout and sales reports, which don’t transfer |
| Testing | Turn off TestFlight beta testing | Recreate test groups afterwards |
| Push and services | Recipient uses their own APNs certificate or key | Firebase, analytics and ad SDK links need manual updates |
| Subscriptions | Share an app-specific shared secret | Subscriptions transfer; paid apps need a payments profile on the target account |
Both pages list more items that don’t move with the app, so read them before you start. If the previous team stops replying, the Account Holder may be out of reach, and Apple’s page says only they can start the transfer.
Prove you can run and ship it
Ask whether a new engineer can clone the repository and get the app running on their own machine. If something is missing, such as a config file or a database dump someone kept locally, write down every step and workaround as you go. That note becomes the setup guide for whoever joins after you.
Pay attention to configuration. The twelve-factor method calls for strict separation of config from code, with credentials and per-environment settings kept in the environment, and offers a test: could the codebase be made open source at any moment without leaking a credential? If the answer is no, secrets are in the code. Move them out and rotate them.
Then look at how code reaches production. Is there an automated pipeline, or does a release depend on one person’s laptop? You need to know before you change anything, because in our view the first release is a common place for surprises.
Map the system on one page
Nobody needs a 40-page document. A diagram and a page of notes is enough. The C4 model describes four levels (system context, containers, components and code). In our view the first two are enough for a handover. Cover:
- The main pieces (web app, mobile apps, APIs, background jobs, admin tools) and how they talk to each other
- Where the data lives, and which tables matter most
- Which outside services the main user journey depends on
- Scheduled jobs and anything else that runs without a user clicking something
The goal is a shared picture, so everyone on the team is talking about the same system.
Find what is fragile, using evidence
Every inherited codebase has areas that break easily. Rather than guess, look at what the system already tells you:
| Where to look | What it tells you | How |
|---|---|---|
| Error logs | What fails most often | Your logging or monitoring |
| Support tickets | Where real users get stuck | Helpdesk or inbox |
| Dependency audit | Known-vulnerable or abandoned packages | npm audit, composer audit |
| Money and personal data code | Where a bug costs most | Read those paths, check for tests |
| A backup restore | Whether backups work | Restore to a new place, check the data |
The dependency tools are worth a closer look. npm audit sends a description of the project’s dependencies to the registry and returns a report of known vulnerabilities, and it needs a lockfile to run. composer audit checks installed packages against security advisories and also flags abandoned packages and ones marked as malware.
Backups need a test, not a glance. AWS’s reliability guidance lists assuming a backup exists, and assuming it can be restored, as anti-patterns. It recommends restoring a backup periodically, then validating that the data is complete and checking how long the restore took.
If the app was built with an AI assistant, add keys left in the code and unreviewed database rules to the list. The vibe coding security risks piece covers why. For a second opinion on the findings, a technical and security audit covers the same ground.
Then rank what you find by business risk. For example, messy code that never breaks can wait, and a checkout that fails every Friday cannot.
Stabilize before you build
Spend the first stretch on the highest-risk fixes: security updates, failing background jobs, backups that were never tested, and the one bug everyone has learned to live with. Add monitoring so problems show up on a dashboard before a customer reports them. Signs your architecture is slowing your growth lists the measures worth tracking.
This is also where trust gets built. The business sees fewer incidents, and the team learns the system by fixing real problems inside it, which in our view beats reading code in the abstract.
Then plan the roadmap
Plan new features and bigger changes only when the app is stable and understood. In our view estimates are more realistic by then, and it is clearer what can be improved step by step and what, if anything, really needs rebuilding.
Start with one list: every account the app depends on, and who holds it today. Ask the previous team to move anything the business doesn’t own while they still answer email, and write down their setup steps the same day. Everything else on this checklist waits until that is done.
Sources
- Apple: Overview of app transfer
- Google Play Console Help: Transfer apps to another developer account
- The Twelve-Factor App: Config
- C4 model: software architecture diagramming
- npm documentation: npm audit
- Composer documentation: audit command
- AWS Well-Architected Reliability Pillar: REL09-BP04, periodic recovery of data to verify backups
Frequently asked questions
What should I ask the previous team for first?
Access, before anything else. That means the code repositories with full history, hosting and database accounts, the domain registrar and DNS, the Apple and Google developer accounts, third-party services, and the secrets for every environment. Ask for written setup notes at the same time, while they are still answering email.
Can I move an iOS or Android app to a new account?
Yes, but the old account has to take part. Apple says the membership Account Holder starts an app transfer and the receiving Account Holder accepts it. Google Play says both accounts must be registered and active, and the original account must be able to sign in. Both platforms list things that do not move with the app, so read their transfer pages before you start.
Should I change passwords and keys after a handover?
In our view, yes. Rotate every secret you were given, and any secret you find in the code. The twelve-factor method keeps credentials in the environment, not in the codebase, and offers a test: could the code be made open source tomorrow without leaking a credential? If not, rotate and move them.
How do I find the security problems in an app I inherited?
Start with the dependencies. npm audit reports known vulnerabilities in a project's dependencies, and composer audit checks installed packages against security advisories and flags abandoned ones. Add a look at code that handles money or personal data, and test a backup restore. An automated check covers only part of the picture.
Should I start on new features straight away?
In our view, not yet. Until the system is mapped and stable, a new team can easily break things it didn't know were connected. Spend the first stretch on access, setup, a one-page map and the highest-risk fixes, then plan the roadmap.
