Knowledge transfer when switching QA vendors

Why transfers fail

Switching QA vendors usually happens because something went wrong, which means relations with the outgoing vendor may already be strained. Knowledge that was never written down sits with a few people who have little reason to share it. Test code sits in repositories nobody on your side has opened. The new vendor is eager to start and may prefer to rebuild rather than learn.

A transfer plan organised by artefact and by person, with a clear finish line, turns this into a checklist. ISO 37500 treats transition as a named phase of the outsourcing life cycle, and European financial regulators expect firms to have exit strategies that allow services to move to another provider without disruption. You do not need to be a bank for the logic to apply.

Start with the outgoing contract

Before you give notice, read the outgoing contract for:

• Exit assistance: whether the vendor must keep providing the service during a notice period, and on what terms.
• Knowledge transfer: whether sessions and handover notes are included, and how many hours.
• Intellectual property: whether test assets are assigned to you.
• Data return and deletion: what is returned, in what format, and with what confirmation.

If these terms exist, use them. If they do not, you are negotiating, and it is better to know that before you announce the change. The framework's clauses for knowledge transfer on exit and the exit plan, available on the contract clause builder, show what to put in the next contract so you are not in the same position again.

The transfer plan by artefact

Artefact	What to capture	Proof it has moved
Automation suite	Repository, branches, dependencies, how to run it, known flaky tests	New team runs it in your CI from a clean checkout
Manual test cases	Test management export, priorities, which cases map to which features	Cases imported into your tool with history
Test data	Data sets, generators, masking scripts, seed procedures	New team sets up data for a full cycle unaided
Environments	Configuration, access lists, known quirks, who fixes what	New team deploys or resets an environment
Defect history	Open defects, recurring problem areas, severity conventions	Open defects reassigned and reviewed
Documentation	Test strategy, plans, reports, runbooks	Reviewed by new team; gaps listed
Access and accounts	Every account the outgoing team uses	Outgoing access revoked, new access working

Move ownership first. Every repository, test management project and CI job should sit in accounts you own before any session starts. That removes the risk of losing access halfway through.

The transfer plan by person

Artefacts do not carry everything. Someone on the outgoing team knows why a test is skipped on one browser, which environment breaks on Mondays, and which developer to ask about the payments module. Name those people and book sessions with each of them:

• a walkthrough of the automation suite by its main author;
• a walkthrough of the manual regression by the lead tester;
• a session on environments and test data;
• a review of open defects and known risk areas.

Record the sessions and store the recordings with the documentation. Ask the new vendor to write up what it learned in its own words; gaps in that write-up show where knowledge did not move.

Shadow, then reverse shadow

Two cycles make the transfer real. In the first, the new team watches the outgoing team run a test cycle. In the second, the new team runs the cycle while the outgoing team watches and answers questions. Only then does the new team run alone.

Acceptance tests for the transfer

Define in advance what proves the transfer is done. For example:

• The new team runs the full regression from a clean checkout in your pipeline.
• It triages a real failure and states whether it is a product defect, a test defect or an environment problem.
• It produces a test report in your tools in the agreed format.
• It sets up test data for a cycle without asking the outgoing team.

Until these pass, keep the outgoing vendor on its exit assistance terms. When they pass, confirm data deletion, revoke access and record any remaining gaps with an owner.

Choosing the new vendor with transfer in mind

When you replace a vendor, the framework raises the weight of knowledge transfer, code ownership and staff continuity. Ask candidates how they would assess an existing suite before deciding to keep or rewrite it, and check their answers on the due diligence checklist. The first month after the switch follows the same pattern as onboarding a QA vendor, and the terms that make the next switch easier are in exit planning.