When you inherit an app
Apps change hands more often than their owners expect. A development company is replaced. A freelancer moves on. A business is acquired with its app included. An internal developer resigns. In each case someone becomes responsible for a product they did not build, usually with less information than they need.
The risk is specific. An app is not only code. It is a listing in two stores, a set of cryptographic keys, a backend, a database of users and a chain of third-party services. Lose one link and you may be unable to update the app at all. The questions below are grouped by link.
Accounts and signing keys
Start here, because this is where a handover fails beyond repair.
- 01
Whose developer accounts hold the app in each store?
Why it mattersIf the listing sits in the previous company's account, it must be transferred. Both stores document a transfer process, with conditions that are easier to meet while that company cooperates.
- 02
Who are the account holders and administrators?
Why it mattersYou need an administrator inside your own organization, on a company email address, before anyone else's access is removed.
- 03
Where are the signing keys and certificates?
Why it mattersUpdates must be signed with the right key. Without it, or a reset arranged through the store, you cannot publish a new version to the existing listing.
- 04
Which keys does the app use for push notifications and sign-in?
Why it mattersThese expire or are tied to accounts. If they lapse, notifications or social sign-in stop without warning.
- 05
Is there anything in a personal account?
Why it mattersKeys on a laptop, a service paid by a private card and a domain in an individual's name are the usual surprises.
Source code and the ability to build it
Receiving a folder of code proves little. What matters is whether a developer who has never seen the project can produce the same app that is in the stores.
- 01
Ask for the full repository with its history
A zip file without history hides who changed what and why. The history is documentation you cannot recreate.
- 02
Confirm it matches the live version
The version in the stores should correspond to a marked point in the repository. If nobody can say which, expect differences.
- 03
Have someone independent build it
A clean build on a fresh machine, following the written instructions, is the real test. Every missing secret and undocumented step shows up here.
- 04
List the dependencies and their age
Outdated frameworks and abandoned libraries are the main source of upgrade cost. Ask when they were last updated.
- 05
Ask what is not in the repository
Configuration, environment secrets, build scripts and server code are often kept elsewhere.
A technical code audit gives you this assessment in writing before you commit to a plan.
Backend, data and third-party services
| Area | What to ask for | Why |
|---|---|---|
| Hosting | Account access, architecture outline, monthly cost | You must be able to run and pay for it |
| Database | Location, access, backup routine, a tested restore | User data is the asset that cannot be rebuilt |
| Third-party services | A list with the account behind each: payments, maps, messaging, analytics, crash reporting | Each is a dependency and a bill |
| Integrations | Which business systems the app talks to, and how | Changes there can break the app |
| Environments | Whether a test environment exists apart from production | Without one, every change is tested on real users |
| Monitoring | What alerts exist and who receives them | Otherwise users report outages before you see them |
Users, rights and obligations
- Usage and health. Ask for active users, crash rates, store ratings and recent reviews. They show what state the app is in and what users are waiting for.
- Rights to the code. Ownership and licensing terms are defined in the project agreement with whoever built the app, so ask for that agreement and read what it says about custom code, reused components and open-source licences.
- Privacy commitments. The privacy policy, the store privacy declarations and any consent wording are promises to users that you now inherit. Confirm that the app does what they say.
- Contracts and subscriptions. Paid plans, service agreements and support contracts may need to be reassigned to you.
- Known problems. Ask plainly what is broken, what was postponed and what the previous team would fix first. Most people answer honestly when asked directly.
A worked example
A retailer changes app company
This example is invented to show the order of events. A retailer ends its contract with the company that built its shopping app and appoints a new one.
- AccountsThe iOS app is in the retailer's own account, but the Android app is listed under the old company. A transfer is requested while the old contract still has a month to run.
- KeysThe Android signing key is found on a former employee's machine at the old company. It is handed over along with the push notification credentials.
- BuildThe new company cannot build the app from the repository at first. Two configuration files and a private library were missing. The old company supplies them within the notice period.
- BackendThe retailer learns that the backend runs in the old company's cloud account. It is moved to the retailer's own account over a weekend, with a tested backup taken first.
- First releaseThe new company publishes a small update to both stores, changing only a version number and a typo, to prove that the whole chain works.
The retailer now controls every link. Had the questions been asked a month later, after the old contract ended, the Android transfer and the missing files would have depended on goodwill alone.
What to do in the first weeks
Once you hold the app, resist the urge to add features. Prove control first, then stabilize, then improve.
A sound start
- Publish a trivial update to both stores
- Change passwords and remove access for those who have left
- Restore a backup to confirm it works
- Write down what you learned while it is fresh
- Fix crashes before adding features
A risky one
- Starting a rewrite before understanding the old app
- Leaving the previous team's access in place
- Assuming backups exist because someone said so
- Promising a feature date before the first clean build
- Letting certificates or subscriptions lapse during the change
If the app turns out to be in poor condition, our comparison of modernizing and replacing legacy software sets out how to decide between repair and rebuild.
App takeover checklist
App takeover checklist
0 of 11 checkedWhat to do next
Send the checklist to the outgoing team today and ask for each item by a date that falls inside their notice period. Follow up on accounts and keys before anything else.
If you would like help assessing what you have received, our mobile app modernization page explains how we take over existing apps. Tell us what you have been given and we will say what we would verify first.
Common questions
What if the previous developer will not hand over the signing keys?
Raise it formally and early, referring to your agreement with them. If the keys cannot be obtained, the stores have documented routes that may help, such as a key reset where the store manages app signing, or publishing a new listing as a last resort. A new listing loses existing installs, ratings and reviews, so it is worth considerable effort to avoid.
Can an app be moved from one developer account to another?
Both major stores document a transfer process that keeps the app's users, ratings and reviews. Conditions apply, and certain features or account states can complicate a transfer, so read the current store documentation before you plan around it. The transfer needs action from the account that currently holds the app, which is why timing matters.
Should we rewrite an inherited app?
Not as a first move. A rewrite discards working behaviour that nobody has documented, and it takes longer than expected. Stabilize the existing app, learn how it is used and have the code assessed. A rewrite is justified when the technology is no longer supported or every change costs more than it should, and that case should be made with evidence.
How do we know whether the code is any good?
Ask an independent developer to build it, read it and report. Useful signals are whether it builds cleanly, how old its dependencies are, whether tests exist, how consistent the structure is and how many crashes users experience. A written audit with priorities is a modest cost compared with planning a year of work on a wrong assumption.
What should we ask the previous team before they leave?
Besides access and files, ask for a walkthrough of the architecture, the release process and the known problems, and record it. Ask what they would fix first and what they would never touch. An hour of recorded conversation with the people who built the app often saves weeks of investigation later.
