Replacing a QA vendor: checklist for a clean switch

Your current testing vendor is not delivering and you have decided to replace it. The new selection is shaped by what went wrong, and the switch itself carries risk: test assets, knowledge and access sit with a supplier that is about to lose the account. Plan the exit from the old vendor as carefully as the choice of the new one.

What changes in criteria and weights

Staff continuity, ownership of test code, reporting that shows risk and knowledge transfer all rise to 5, and onboarding and the exit plan rise to 4. Nothing is lowered, because a replacement has to meet the normal bar and also fix the specific failures you have already lived through.

Criteria whose weight differs from the default
Criterion	Default weight	Weight here
Staff continuity and replacement terms	3	5
Ownership of test code and assets	3	5
Reporting that shows risk	3	5
Knowledge transfer	3	5
Onboarding plan and turnaround	3	4
Exit plan and assistance	3	4

Weights run from 0 (not scored) to 5. Every other criterion keeps its default weight of 3. The scoring template loads these weights when you choose this situation.

Which tools, in which order

Contract clauses: Read your current contract against the clause library first, so you know what exit assistance and asset handover you are already entitled to and what the new contract must add.

Due-diligence checklist: Use the IP and code ownership checks to confirm that the outgoing vendor can hand over test code and assets, including anything written by its subcontractors.

RFP generator: Write the RFP around the handover: state what assets exist, what the new vendor inherits, and the overlap period you expect.

Vendor questionnaire: Filter the questions by this situation to probe staff continuity, knowledge transfer and how the vendor reports risk before it becomes a missed release.

Proposal red-flag checker: Check proposals for the same patterns that hurt you last time, such as pooled staff or a vague service level with no remedy.

Reference-call script: Ask references whether the vendor took over from another supplier and how the first months of that transition went.

Scoring template: Score with the replacement weights so continuity, ownership and reporting outweigh a polished proposal.

Cost model: Include the overlap period, onboarding and any exit fees from the old contract when you compare the total cost of switching.

Typical mistakes

Giving notice before the new vendor is selected and the exit assistance from the old one is scheduled.

Discovering after notice that the test code, test management space or tool licences are held in the outgoing vendor's accounts.

Accepting a handover that is a folder of files, with no walkthrough sessions and no way to ask questions afterwards.

Choosing the new vendor on the same criteria that picked the old one, without writing down what actually failed.

Leaving the outgoing vendor's access to repositories, environments and test data open after the handover.

Skipping an overlap period, so a release goes out with nobody testing it.

Before you give notice

Read the current contract for notice periods, termination terms, exit assistance and ownership of deliverables. Then build an inventory: repositories and branches, automation code, test cases and their history, test data sets, environment and tool credentials, pipeline jobs, dashboards and any documentation. Record who holds each item. Where the vendor holds an account that should be yours, ask for it to be transferred now, while the relationship is still working.

Write down what went wrong, in concrete terms. Missed defects in a specific area, testers replaced without notice, reports that showed green until release day. This list becomes the core of your RFP and your scoring notes.

During the handover

Agree an exit plan with the outgoing vendor that names the sessions, the documents and the people who will attend. Knowledge transfer works when the new team asks questions of the people who did the work, not when it receives an archive. Keep a log of open questions and close each one before the old team leaves.

After the switch

Revoke the outgoing vendor's access to code, environments, data and chat on a set date, and confirm in writing that it has returned or deleted your data. Put the lessons into the new contract: staff replacement terms, key personnel, measurable service levels and an exit clause that you will never need to negotiate from a weak position again.

Questions buyers ask

What should we secure from the outgoing vendor before giving notice?

An inventory of every asset and account: repositories, automation code, test cases, test data, environment credentials, pipeline configuration, tool licences and documentation. Confirm who holds each one and move ownership to your accounts where you can before the relationship becomes strained.

How long should the overlap between vendors be?

Long enough for the new team to run at least one full release cycle alongside the outgoing team. The right length depends on how often you release and how much undocumented knowledge exists. Agree it in the exit plan with the old vendor and in the onboarding plan with the new one.

Can we require the old vendor to help with the transition?

Only if your contract says so or you negotiate it. Check the exit, termination and knowledge transfer clauses. If they are thin, a paid exit assistance arrangement is usually cheaper than rebuilding lost knowledge.

Should the new vendor keep the old test suite?

Ask the new vendor to assess it first and to state what it will keep, fix or retire, with reasons. Avoid a vendor that proposes to rewrite everything in its own framework before it understands your product.