Switching Development Companies: A Handover Checklist for Moving Your Software to a New Team

Changing the company that builds or maintains your software is less like changing an accountant and more like moving house with the furniture still in use. The system has to keep running while the keys, the paperwork and the knowledge of how everything fits together pass from one team to another.

Whether your product is a website, a mobile app or the kind of custom software development project that runs a whole operation, the move succeeds or fails on one question: what do you actually hold in your own hands? This guide is a handover checklist for owners and managers in the US and UK, covering what to collect, how a new team will judge the code it inherits, and how to avoid being locked in again.

Why owners switch development companies

The reasons are usually ordinary. Releases slip and estimates stop meaning anything. The same bugs come back. The one developer who understood the system has left. Requests take days to be acknowledged. Sometimes the relationship is fine but the product has outgrown the team's skills, for example when a simple site becomes a platform with payments and integrations.

It is worth naming your reason precisely, because it shapes the brief for the next team. "Too slow" may be a staffing problem at the vendor or a codebase so fragile that every change is risky. A new team inherits the second problem along with the code.

What you must have in your own hands first

Before you give notice, confirm that each item below exists, is current, and is controlled by an account your company owns. Access granted to you by the vendor is not the same as ownership.

• Source code repository: the full version history, not a zip file of the latest version, covering mobile, server and admin code.
• Hosting and domain accounts: the cloud or server account, the domain registrar account and DNS settings, billed to your company.
• App store accounts: the Apple Developer and Google Play developer accounts the apps are published under, plus the app signing keys.
• Database backups: a recent backup of the database and uploaded files, with proof it can be restored.
• Credentials: server logins, environment configuration, API keys and certificates, handed over through a password manager and not by email.
• Third-party service accounts: payment gateway, email and SMS providers, maps, analytics, error monitoring and any paid licenses.
• Documentation: setup and deployment steps, an architecture overview, a list of integrations and a list of known problems.

If something on this list sits in the vendor's own account, moving it becomes the first task of the transition.

Moving accounts that are in the vendor's name

Most platforms have a formal transfer route, but nearly all of them need the current holder to cooperate, which is why this is best done while relations are civil.

A mobile app does not need to be republished. Apple says an app can be transferred to another developer account while staying available on the App Store, keeping its ratings and reviews, and that the Account Holder of the current account starts the transfer. Google's Play Console transfer process moves users, statistics, ratings and subscriptions with the app, although test groups and past earnings reports stay behind.

Code hosted on GitHub can be moved to your own organization with its history intact; GitHub's repository transfer documentation notes that issues, pull requests and wikis move too, and that secrets and deploy keys remain attached, a good reason to replace them afterward. For domains, ICANN's Transfer Policy for generic domains such as .com gives the authority to approve a registrar transfer to the registered name holder, so check whose name is on the registration. Country domains such as .uk follow their own registry's rules.

Check that you own the code, not just a copy of it

Having the files and having the rights are separate matters. In the UK, government guidance states that when you commission a work, the creator is the first owner of the copyright unless you agree otherwise in writing. In the US, the statutory definition of a work made for hire covers work by employees and a limited list of commissioned categories. In both countries, what your contract says about assignment of intellectual property matters a great deal.

Read the clause before you start the conversation, and check whether ownership depends on final payment. This is a general description, not legal advice; ask a qualified adviser about your own agreement.

How a new team assesses inherited code

A responsible team will not quote for new features on a system it has not examined. Expect a short paid assessment first. The team will try to run the application from the repository on a clean machine, which immediately shows whether the documentation is real. It will then check how old the language, framework and packages are, whether automated tests exist, how the software is deployed, how data is structured, and whether the code in the repository matches what is actually running in production.

The result should be a written report in plain language with one of three recommendations.

Continue

The code is in reasonable shape and conventionally built. The new team can take over features and fixes after a brief familiarization period.

Stabilize first

The system works but is risky to change: outdated versions, no tests, manual deployments, missing backups. A fixed block of repair work comes before new features. Our article on software maintenance and support explains why this kind of work cannot be postponed indefinitely.

Partial rewrite

One or two parts are beyond economical repair and are rebuilt while the rest stays in service. A full rewrite is rarely the right first answer, because it discards working behavior that nobody has written down.

Running an orderly transition

Read the notice and handover terms in your current contract, then plan for an overlap period in which both teams are engaged. The outgoing team is the only source of unwritten knowledge, so pay for a few structured walkthrough sessions and record them.

Agree a change freeze date after which the old team stops deploying. Let the new team make one small, low-risk release to prove it can build and ship through your accounts. Only then remove the old team's access and replace every password, API key and deploy key, since copies of the old ones may exist on laptops you will never see.

Common mistakes, and when not to switch

The most damaging mistake is announcing the split before you have the repository, accounts and a backup. The second is choosing the next team on a quote written without seeing the code. Others include accepting a code archive with no history, forgetting scheduled jobs and small integrations that nobody listed, and leaving old credentials active.

Switching is also not always the answer. If the real problem is unclear requirements, shifting priorities or an unrealistic budget, a new company will run into the same wall. And if you are in the middle of a critical release, it is usually safer to finish it and then move.

What to do next, and how to avoid lock-in next time

This week, go through the checklist above and mark each item as owned by us, held by the vendor, or unknown. The unknowns are your real exposure. Request anything missing as routine housekeeping, well before any conversation about leaving.

For the next engagement, set the rules at the start: every account is opened in your company's name and the vendor is invited in, code is pushed to your repository continuously, documentation is a deliverable, the stack is a mainstream one that other teams can pick up, and the contract includes handover obligations on exit.

Conclusion

Switching development companies is manageable when you control the code, the accounts, the data and the rights, and difficult when any of them sit with the team you are leaving. Collect those first, have the incoming team assess what it is inheriting before anyone promises a timeline, and run the handover with an overlap, a freeze date and a full credential change at the end.

If you would like an outside view of a codebase you are thinking of moving, you can contact Entrant Technologies, which builds websites, web applications, mobile apps and custom software.