Changing software vendors
Software vendor handover: a CTO's checklist
A firm with takeover experience, such as Briebug, can take over a project from another vendor. A planned handover makes it safer: before the old contract ends, move every account into your name, collect the code, environments, documentation and open defects, and have the new partner assess the system before it commits to a plan.
Updated
What a software vendor handover should include
A software vendor handover should move six things to you and your new partner: access to every account, working environments, documentation, the list of open defects and work in progress, the release process, and the third-party contracts. Start it before the old contract ends, while the outgoing vendor is still paid to help.
This checklist is for a planned change, when the outgoing vendor is still under contract and still answering. That is the safest time to move a project: the people who know the system can still explain it. Pick the guide that fits where you are.
| Where you stand | What it calls for | Guide |
|---|---|---|
| The vendor is under contract and will help | A planned handover: this checklist, an overlap, and an assessment by the new partner. | The handover checklist below |
| The vendor has left, or will not hand things over | Take back the accounts without them, change every credential, then assess. | Taking over from another vendor |
| The developer has stopped answering | Protect the code, accounts and data in the first 48 hours, before you hire anyone. | Your developer disappeared |
| An offshore team is missing deadlines | Decide whether to fix the engagement or change teams, then follow the same handover. | Replacing an offshore team |
The handover checklist
Six areas. For each item, record who owns it today, who will own it after the handover, and the date it moves. An item is done when the new team has used it, not when a document says it exists.
Access and ownership
- Code repositories: your company is an owner of the organization, with every repository and branch in it
- Cloud and hosting: root or global administrator, and the billing account
- Domains, DNS and SSL certificates, with their renewal dates
- Apple and Google app-store accounts, and the app-signing keys
- A list of every credential the outgoing vendor holds, to change on their last day
Environments
- Every environment named: production, staging, test and any developer sandboxes
- The configuration and environment variables for each, kept in a secrets store you own
- Database backups, and a restore that someone on your side has run
- The infrastructure definition, if one exists, or a written list of what was set up by hand
Documentation
- An architecture overview: the main parts, how they connect, and where the data lives
- How to build and run the product from a clean checkout, tried by someone new
- Integrations: each external service, what it does, and how the product calls it
- Recorded walkthroughs of the business-critical flows
Open defects and work in progress
- The issue tracker, moved into an account you own, with its history
- Known defects and their workarounds, in order of how much they hurt
- Open branches and half-built features, and what each one was for
- What was promised and paid for, against what was delivered
Release process
- The CI/CD pipeline, running from accounts you own, with its stored secrets
- Every manual step between a merged change and production, written down
- How to roll back a bad release, and when that was last done
- One release run by the new partner while the outgoing vendor watches
Third-party contracts and licenses
- Every paid service and license the product depends on, and whose name and card it is in
- Renewal dates and notice periods, so nothing lapses during the change
- Support contracts and the contacts at each provider
- Open-source licenses the product uses, if your customers or investors ask for them
We built a new Azure DevOps environment owned by PSIA and moved every repository, pipeline and document into it, ending reliance on a third party.Read the PSIA / SnowPro case study
This page is general guidance, not legal advice. Check your contract with a lawyer before you act on ownership or end an agreement.
What to ask the outgoing vendor
Ask in writing, early, and keep it friendly. The outgoing vendor knows things no document holds, and a respectful exit is the one most likely to come with real answers.
- Which accounts, keys and services do you hold that we do not, and when will you transfer each one?
- What would break if you stopped working on this tomorrow?
- Which parts of the system do you avoid changing, and why?
- What is in progress right now, and what state is each piece in?
- What has gone wrong in production before, and how did you fix it?
- Is there anything in the code or the pipeline that only one person understands?
- Will you answer questions from the new team during the overlap, and for how many hours a week?
Plan the overlap
Agree a period when both vendors work on the product. First the new partner shadows: it reads the code and watches a full release. Then the roles reverse: the new partner runs a release while the outgoing vendor reviews. Agree the end date, the hours and the handover items in writing, and pay for that time.
On the last day, remove the outgoing vendor's access, change every credential they held, and confirm the product builds and deploys from accounts you own. Keys can be hardcoded in the code and stored in the pipeline, so update the application in the same change, or production can stop.
How to vet a software project takeover partner
The incoming partner will see your code, your accounts and often your production data. Choose it on evidence, and ask every candidate the same questions. Briebug's own answer is under each one.
Takeover and rescue experience
Ask: Which projects have you taken over from another vendor? What did you find, and what did you do first?
Briebug: our case studies describe what we found and what we did first on each project.
An assessment before a plan
Ask: What will you review before you commit to a plan or a price, and is the report ours to keep if we do not hire you?
Briebug: the Technical Assessment is $10K, about 1 week. The assessment ends with a milestone-based estimate for the rest of the work. The fee is not credited if you hire us, because the report stands on its own.
A plan to hand the project back
Ask: How will this engagement end? What documentation and pairing do we get, so our team can run the system without you?
Briebug: We document what we changed and why, and we pair with your engineers until they own the code and the process. An optional senior oversight retainer after handback.
Security posture
Ask: Which security certification do you hold, who audited it, and how will you handle our credentials and data during the handover?
Briebug works on any stack, has delivered software since 2009 and is ISO 27001 certified. All client code and data stays on US-based infrastructure.
Who does the work
Ask: Who exactly will work on our code, how senior are they, and where are they based?
Briebug: Every engineer on a client engagement is a US citizen or US person physically located in the US. No offshore subcontracting.
Your accounts stay yours
Ask: Will every account stay in our company's name, with your team given access rather than ownership?
Briebug: everything the product runs on is put in accounts you own.
Read our case studies for what we found and did first on each project. For more criteria, see how to choose a software project rescue firm.
Red flags during a handover
- The incoming partner quotes a date or a price before anyone has read the code.
- Its plan moves your repositories, cloud accounts or domains into its own name.
- It cannot name the engineers who will do the work.
- It has no written answer to how and when the engagement ends.
- The outgoing vendor asks to keep admin access "just in case" after the handover ends.
- Nobody plans to change the credentials the outgoing vendor held.
- The first release by the new team is planned for the week after the old vendor leaves.
Assess before you commit
Briebug's Technical Assessment reviews the code, architecture, release pipeline and security. You get a triage report of what to fix in what order and a milestone-based estimate. The report is yours to take to anyone, and the fee is not credited if you hire us.
- Fixed fee
- $10K
- Duration
- About 1 week
Then we stabilize the project and hand it back to your team.
Common questions
Who can take over a software project from another development vendor?
Any firm with experience taking over code it did not write, that will assess the system before it commits to a plan, and that leaves every account in your company's name. Briebug does this as part of its rescue work: assess, stabilize, and hand the project back to your team.
What should a software vendor handover include?
Access to every account, working environments, documentation, the open defects and work in progress, the release process, and the third-party contracts and licenses. Each one should be in your company's name and tested by the new team before the old vendor leaves.
When should we start the handover?
Before the old contract ends, while the outgoing vendor is still paid to help. Check the notice period and any transition terms in the contract first, and plan an overlap in which the new partner runs a release while the old vendor watches.
What if the outgoing vendor will not cooperate?
It is easier if we can work with your old vendor to transfer the accounts, but it is not necessary. We can recreate accounts, and contact service providers to transfer accounts to you. Then we rotate the credentials and remove the old vendor's access, so the project no longer depends on them.
How long does a vendor handover take with Briebug?
Depending on the number of accounts, this can take a few days to a few weeks. It depends most on how willing your old vendor is to help. After that, the Technical Assessment takes about 1 week.
Will Briebug sign an NDA before the handover?
Yes. We always sign a mutual NDA, to protect both of us. We can set up code escrow, but it is not our preference.
Plan the handover before the contract ends.
Book a short call with a senior engineer. Tell us where the handover stands, and we will tell you what to move first.