The vendor still sends invoices. But replies are slow, every release breaks something, and the answers feel vague. You no longer trust what you are told.
Leaving feels risky because they hold the keys. They know how the app is deployed. Some of the accounts may sit in their name. You worry the app stops the day you say goodbye.
It does not have to. A takeover is mostly careful admin work, done in the right order. This checklist is the order we follow.
Start quietly, with what you already own
Before you tell the vendor anything, find out what you control today. Read your contract first. Most development contracts assign the code to you once invoices are paid. Check that yours does.
Then list every login you already have. Note which ones are in your company's name and which are not. That list tells you how much the vendor really holds.
Keep paying the vendor while you do this. You want them helpful during the handover, not surprised.
1. Accounts and credentials
Your app depends on more services than you think. List every one of them:
- Hosting and servers
- Email sending and SMS
- Payments
- Push notifications
- Analytics and error tracking
- Maps, search and any other paid API
For each service, answer three questions. Whose name is on it? Whose email address? Whose card pays for it?
Move each account to a company email address you control. A shared inbox works better than one person's address. Store every password in a password manager the company owns.
Once the handover ends, rotate every secret and API key. The vendor may have copies, even with good intentions.
2. Code and repositories in your name
The code should live in a repository under your own organization. That could be GitHub, GitLab or Bitbucket. Ask for the full history, every branch and every tag.
A zip file of the code is not a handover. History shows why things changed, and it is often the only documentation.
Then test it. A new engineer should be able to build the app from the repository alone. If they cannot, something is missing. Common gaps are config files, environment variables and build scripts that live on one laptop.
3. The cloud account
This is the most common trap we see. The app runs inside the vendor's own cloud account, mixed in with other clients.
What you want instead:
- A cloud account registered to your company, paid with your card.
- You hold the top-level login, protected with two-factor.
- The vendor gets a named user you can switch off in one click.
If the app sits in their account today, plan a move. That means a new account, the setup rebuilt inside it, and the data copied across. It takes planning, but it is routine work.
While you are in there, look at the bill. Nobody tunes an account they do not own.
4. App store accounts
Mobile apps add two accounts that are easy to forget: Apple's developer program and Google Play. Both should be in your organization's name.
If the apps are listed under the vendor's account, both stores offer a transfer process. It takes time, so start it early.
Also ask for the signing keys and certificates used to publish each app. Some are hard to replace if they are lost.
5. Domains and DNS
Find out where your domain is registered and who controls the login. Check the DNS settings too, including the records that make your email work.
A domain that expires inside a former vendor's account is a classic way to lose a site. Move it, turn on auto-renew, and put the renewal on a company card.
6. Data export
Ask for a full database backup and every stored file, like images and uploads. Then restore that backup somewhere you control.
A backup that has never been restored is a hope, not a backup. Restore it, open the data, and check it looks complete.
7. Documentation
Ask the vendor to write down what only they know:
- How the parts of the system fit together.
- How a change gets from code to production.
- Every environment variable and what it does.
- Every third-party service and why it is there.
- Known bugs and anything they were afraid to touch.
Expect gaps. Good handover notes are rare. The rest gets written by whoever takes over, as they learn the system.
Signs the handover is being made harder
Most vendors hand over cleanly once they know the date. A few do not. Watch for these signs:
- Access promised for next week, every week.
- A new fee that must be paid before anything is released.
- A repository that arrives without its history, or missing whole folders.
- Logins that work once, then stop.
If you see these, stay calm and keep everything in writing. Point back to the contract and its ownership terms. If the code is truly held back, a lawyer can help.
Meanwhile, secure what you already control. Start with the domain and the cloud account, because those keep the app online.
Keep the old app running the whole time
Your users should not notice any of this. The app stays live, in its current form, until the new owner can deploy it safely.
A few rules help:
- Freeze big changes during the handover.
- Agree an end date with the vendor, with paid time for questions.
- Overlap the two teams for a short period if you can.
- Do not switch anything off until its replacement works.
The first 30 days after the handover
The handover is the start, not the finish. Here is what a good first month looks like.
Week one. Access and backups secured. Secrets rotated. Monitoring and alerts switched on, so you hear about problems before customers do.
Week two. A written audit of the code and the infrastructure. What is risky, what is fine, and what to fix first.
Weeks three and four. A first small release through a proper release pipeline. It proves the new team can ship without breaking things. Then a look at the cloud bill, line by line.
After that, the work turns from rescue to improvement. Fix the riskiest parts first, one release at a time.
What this looked like for Remnant Tribe
WeRemnant Inc runs Remnant Tribe, a faith community app. The old version looked dated and did very little. Maintenance sat with a vendor that could not deliver what the team needed.
We took over the code and the AWS account. We kept the old app running and mapped how everything worked. Then we right-sized the cloud setup. The cloud bill is now about a third of what it was.
After that, we rebuilt every part: the API, the admin, the iOS and Android apps, and the website. The app is live in both stores and gets releases every month. You can read the Remnant Tribe case study for the full story.
You do not have to do this alone
Some owners run this checklist themselves. Others want someone who has done it before. Our rescue and modernization work starts with exactly these steps. If you mainly want to know how risky your app is, start with a technical audit.
Talk it through
Worried about the app your vendor holds? Book a 30 minute call. You leave knowing what you own, what to secure first, and roughly what a takeover costs.
