Exit planning for a QA outsourcing contract

Why exit belongs in the contract, not the ending

Every outsourcing contract ends. The question is whether you can move the work without losing the tests, the knowledge and months of time. Regulators in financial services treat this as a basic control. The European Banking Authority's outsourcing guidelines expect firms to have documented exit strategies for critical or important functions, and DORA requires exit strategies and a transition period in contracts for ICT services supporting critical or important functions. You may not be regulated, but the reasoning is the same: plan exit while the relationship is working.

ISO 37500, the international guidance on outsourcing, also treats exit as part of the outsourcing life cycle rather than an afterthought.

The asset list

Start from a simple question: if the vendor disappeared tomorrow, what would you need to keep testing? For a QA engagement that usually means:

Asset	Where it should live	Check
Automation code and framework	Your repository	Runs in your pipeline without vendor tools
Test cases and suites	Your test management tool	Exportable in an open format
Test data sets and generators	Your repository	No personal data
Environment and pipeline configuration	Your repository and CI	Documented
Defect history	Your issue tracker	Complete, with links to tests
Test strategy, plans and reports	Your document store	Current version
Credentials and service accounts	Your identity system	Listed for rotation
Know-how	People's heads	Captured in runbooks before exit

The strongest exit protection is not a clause about handover. It is keeping every asset in your accounts from the first commit, so there is nothing to transfer. See the ownership and repository clauses in the contract clause builder.

What the exit schedule should contain

Wording to adapt:

Supplier will deliver a draft exit plan within [60] days of the start date and update it [annually]. On notice of termination or expiry, Supplier will continue to provide the services at the agreed service levels and provide exit assistance for an exit period of up to [X] months, as the Customer requires.

Around that, the schedule should cover:

• The exit period. Long enough to bring in a replacement or build your own team. The service and its service levels continue throughout.
• Knowledge transfer. Sessions on the test strategy, the structure of the suite, known flaky tests, open defects and environment quirks, with a named person from the vendor responsible.
• Assistance rates. Fixed in the rate card now. Rates agreed during exit are rates you cannot negotiate.
• Cooperation with a new supplier. An obligation to work with whoever takes over, under confidentiality.
• Access removal. Dates by which each account is removed, with confirmation.
• Data return and deletion. Under GDPR Article 28, a processor must delete or return personal data at the end of the service, at your choice. Ask for written confirmation.
• Staff. Whether you or a new supplier may hire members of the vendor's team, and on what terms. Non-solicitation clauses often block this by default.

The UK Model Services Contract has a full exit management schedule you can read as a reference for what a detailed version covers.

Signs in the proposal

Look for the pattern the red flags checker calls "no exit or knowledge transfer section": a detailed onboarding plan and nothing about handing the work back. Also watch for proprietary frameworks, test code in the vendor's repository, and licences that end with the contract. Each of these turns exit into a rebuild.

Test the plan while things are good

An exit plan nobody has tried is a document, not a plan. Once or twice a year, ask one of your engineers to clone the test repository, run the suite in your pipeline and read the documentation without asking the vendor anything. Note what was missing and ask the vendor to fix it as part of the normal service.

Due diligence links

Exit also depends on the vendor's stability. If it is sold or fails, you need to be able to terminate on change of control and take your assets. The due diligence checklist covers financial signals and what happens to your assets in an insolvency. For the handover itself, see how QA vendors staff projects on continuity during the exit period, and how to run a paid pilot for setting ownership rules from the first day.