Changing software vendors: what a real handover has to include

You have decided to part ways with the agency that built your software, and they have offered to "send over the code." That is not a handover. The real test fits in one sentence: can the incoming team set up a development environment from scratch, build the application, ship a release to production and roll it back, without asking the old team anything? Getting there takes far more than source code. It takes ownership of the domain and DNS, the cloud and store accounts, the build pipeline, the secrets, the data, and the operational knowledge nobody ever wrote down. This piece covers what to ask for in writing, and what the incoming team should do in its first two weeks.

Sequence matters, because these separations are rarely warm. Draw up the list before you announce the decision, and check account ownership before the announcement too. A domain registered under a former employee's personal email address is much harder to claw back once the relationship has cooled.

A handover is an account handover, not a code handover

Start with an inventory. One page, one row per account, three columns: which email address it was opened with, who gets the invoice, who is the admin.

The list usually runs long. Domain registrar, DNS, cloud provider or hosting, code repository, CI/CD, Apple and Google developer accounts, error tracking, logging and monitoring, analytics and Search Console, transactional email provider, SMS provider, payment gateway dashboard, e-invoicing integrator, maps and other API keys, design files, package registry accounts such as npm or a container registry.

As you fill it in, split the rows into two groups. Accounts opened in your company's name but administered by the vendor are the easy case: you change the admin and you are done. The hard case is infrastructure living inside the vendor's own account. There, "transfer" is not a button. It usually means opening a new account and moving, which takes days and belongs in a plan, not in a checklist item.

Domain and DNS: the lock can hold you up

A domain is the asset that costs the most to recover once it is lost. Verify that the registrant on file is your company and that the contact address is a mailbox you can actually open.

Moving a domain between registrars requires an authorization code from the current registrar, long known as the EPP or auth code and renamed the Transfer Authorization Code (TAC) in ICANN's revised transfer policy. There is also a lock period: ICANN's transfer policy blocks inter-registrar transfers for up to 60 days after a new registration and after a previous transfer, and a change of registrant details can trigger a similar hold. The revised policy shortens these windows, but do not build your plan on the assumption that you can move the domain the same day you decide to.

There is something you can do without moving the registration, and it is usually more urgent: take over DNS management. Before you do, ask for a full export of the current zone. Some of those records do invisible work, including the SPF, DKIM and DMARC records that keep your mail flowing and the TXT records that store and payment providers use for verification. Miss one and you quietly break your email authentication chain, then hear about it a week later as "customers aren't getting the password reset email."

When your cloud account sits inside someone else's organization

Here is a common setup: your systems run in a member account under the vendor's AWS organization, and the bill lands on their management account. Making that account standalone is not a few clicks. AWS requires a member account to have its own payment method, a chosen support plan and verified contact information before it can be removed from an organization; without those, the removal simply fails. Other providers apply the same logic to their team and organization structures.

Answer two questions early. Is the account actually transferable, or are you sharing a tenancy with the vendor's other clients? If it is shared, transfer is impossible and a migration project starts. Second: after the transfer, where does the bill go and whose card is on file? We have seen environments suspended over exactly that detail. Expect costs to look higher afterwards as well, since the outgoing vendor takes their committed-use discounts and reservations with them. Put a cloud cost review in the first month after the switch.

Store accounts and the signing key

If you have a mobile app, you are dealing with two processes that share almost nothing.

On Apple's side, app transfers run through App Store Connect and the rules are explicit. Only the Account Holder can initiate one, and the recipient has 60 days to accept. The app must have at least one version already released on the App Store; an app that is in review, pending release or available for pre-order cannot be transferred. In-app purchase product IDs must not collide with products in the receiving account. Do not skip Apple's own warning either: the app leaves your account once the transfer completes, so metadata and sales history should be exported beforehand.

On Google's side, an app transfer requires both developer accounts to be active and the transaction IDs from each account's registration fee payment. The part that really matters, though, is the signing key. Apps created after August 2021 must ship as Android App Bundles, which requires Play App Signing, so the signing key sits with Google. On older apps the key may still live on a machine at the vendor's office or in a keystore file somewhere. If that key is lost, you cannot ship updates to the existing app at all; your only way out is moving users to a new listing. That question belongs at the top of the handover list. Other friction in store releases is covered in store review and rejection reasons.

Repository, pipeline, and the from-scratch test

Take the repository with its history, not as a zip file. Commit history is the fastest way to find when and why a bug arrived, and a flattened history destroys the best documentation you have.

A GitHub repository transfer handles most of it: issues, pull requests, the wiki, stars and commit history move across, and Git links to the old location redirect. Two details are worth knowing. GitHub Pages links are not redirected, so a site served from the repo will break. And webhooks, repository secrets and deploy keys stay associated after the transfer, which is the subject of the next section.

What gets forgotten more often than the code is the build pipeline: CI/CD configuration, environment variables, private package registries used during the build, signing certificates, database migration files, provisioning scripts, the list of scheduled jobs. Half of this typically lives somewhere nobody committed. For how a pipeline should be shaped once you own it, see CI/CD for small teams.

The only verification that counts is this: one person from the incoming team, on a clean machine, brings the project up using nothing but the delivered documentation. Every step they get stuck on is an item still missing from the handover. Run this while the old vendor is still under contract, not two months after they are gone.

Every secret the old team saw is now an old secret

Once the transfer is done, write a rotation list and work through all of it: database passwords, third-party API keys, payment and SMS provider credentials, webhook signing secrets, session and JWT signing keys, SSH and deploy keys, server admin accounts, dashboard users, VPN access. Remove the vendor's personal accounts from your organizations, revoke the OAuth app grants and personal access tokens you issued. Ask in writing for remaining copies of your data to be deleted.

Do not frame this as distrust, because it isn't. When credentials are shared across years, nobody remembers who saw what, and keys end up scattered across code, scripts and old laptops. GitGuardian's report published in March 2026 counted 28.6 million new hardcoded credentials pushed to public GitHub repositories during 2025 alone, up 34 percent year over year. There is no reason to assume private repositories look better.

If secrets are already in the Git history, rotate rather than rewrite; invalidating the key is the only real fix for a leaked one. For a durable setup, move to the vault approach described in managing hardcoded secrets. Plan the side effects while you are at it: rotating a session signing key logs every user out, and rotating a webhook secret needs a matching change on the other side. Rotation is a sequenced, announced piece of work, not something you do in one evening.

Data: a dump file is not the same as usable data

"We gave you the database backup" is rarely enough. Ask for the schema documentation or at least a readable schema dump, a full copy of the object storage buckets holding user uploads, instructions for rebuilding any search index, and the location of the keys for any fields encrypted at rest.

Then run two checks. Restore the delivered backup into an empty environment and confirm it actually comes up, because an untested backup is not a backup. And compare record counts against the live system. The reconciliation discipline behind this is in migrating data from an old system.

Record sessions instead of commissioning documents

Asking a departing vendor for 200 pages of documentation is well meant and ineffective. Nobody writes it, and if they do, nobody reads it. Book three two-hour sessions instead and record the screen shares: one on system architecture and external dependencies; one on how a release goes to production and how it is rolled back, plus the manual jobs someone performs on live; one on known issues, fragile areas, the "don't touch this" list and the biggest incidents of the past year.

Alongside those, ask for two short written documents. First, the environment and account list: what runs where, and which address logs in. Second, third-party contracts with renewal dates, because a forgotten license renewal shows up as an outage three months after the switch. Breaking single-person dependency is covered in when the only person who knows the code leaves.

Put the exit clause in the contract on day one

All of this is easy when the exit terms are already written down. Financial services learned that through regulation: the EU's DORA regulation, applicable since 17 January 2025, requires documented and sufficiently tested exit strategies for ICT services supporting critical or important functions. You may be nowhere near its scope, but the logic of the clauses travels.

Look for four things in a development contract: an explicit statement that the intellectual property and source code belong to you, a commitment that accounts are opened in your company's name, a defined transition support period on termination (30 to 90 days is common), and delivery of your data in a widely used format. We went deeper on these in source code ownership and escrow and what belongs in a maintenance and support contract. Fix the hourly rate for transition support up front too; support negotiated at the moment of separation is expensive support.

The incoming team's first two weeks

A new team's first instinct is usually "let's rewrite this." Sometimes that instinct is right, but it is not a week-one decision, because in week one you have no evidence. Assess first.

Work in this order: finish the from-scratch setup test, ship a small harmless change to production and roll it back (that is how you learn whether the pipeline really works), inventory dependency versions and components past end of life, list open vulnerabilities, find out what the automated tests actually cover, check license compliance, review the infrastructure bill and idle resources, and read the last three months of incident and error records.

Do not dump the results into one bucket. Security and continuity risks get fixed now, bottlenecks blocking business goals go in the next quarter, the rest joins the normal development rhythm. For making that ranking defensible, see measuring and prioritizing technical debt. And decide the rewrite question with data rather than first impressions: the answer to rewrite or modernize incrementally usually sits between the two.

Switch day and the parallel window

Do not compress the transfer into a single day. The model that works: the incoming team receives access before the outgoing contract ends, runs the from-scratch test, and ships the first production release while the old team is still reachable. Keep that first release tiny, a copy change is fine. The point is not to deliver a feature, it is to prove the whole chain works.

Write down who is on call during the parallel window. "We'll call them if something breaks" is not a plan, particularly once the other side is no longer being paid.

What you can do this week

1. Build the account inventory: which email opened each account, who is billed, who administers it.
2. Verify the domain registrant and contact address, and export the full DNS zone.
3. If you have a mobile app, find out today who holds the signing key.
4. Draft the rotation list now, so switch day becomes an ordered task instead of a scramble.
5. Put transition support and data delivery clauses into your next contract, at the start rather than at the exit.

At Wedevit we work both sides of this. For clients leaving a vendor, we prepare the list of what to demand and manage the access transfer. For clients taking a codebase over, we start with the from-scratch setup test, secret rotation and a technical assessment, then hand back a prioritized roadmap rather than a rewrite proposal. All of it is delivered remotely.