Switching QA vendors without losing your tests or your release date
Short answer
To switch QA vendors safely, secure your test assets first (test cases, automated tests, bug history, reports and access lists), then bring the new team in on your most important flow while the old one is still in place if you can, and only then cut access. Check the new vendor's team location, legal entity and security certificates before you sign, because those are the reasons switches are most often forced.
Teams change testing vendors for ordinary reasons, such as cost or quality, and for sudden ones: a legal or compliance team decides a vendor can no longer be used, often because of where its engineers are based. This guide covers both, with the steps that protect the work you already paid for.
When the switch is not your choice
A growing number of switches start with a message from legal, compliance or a parent company: the current vendor can no longer be used. The usual reasons are:
- Where the engineers are. Sanctions, export controls or a parent company's policy can rule out teams in certain countries, even when the work itself was good.
- Data protection. Personal or health data may only be handled under GDPR or a specific contract, and the vendor's set-up does not meet it.
- Security requirements. A new customer or regulator asks for certificates such as ISO 27001 that the vendor does not hold.
- An acquisition. The new owner already has approved suppliers.
In each case the deadline is set by someone else, so the steps below are ordered for speed.
Secure your test assets before anything else
Before you announce the change, make sure you hold everything the current vendor produced. After notice is given, cooperation can slow down, and access to the vendor's own tools ends with the contract.
| Asset | Where it should end up | Check |
|---|---|---|
| Test cases | Your test management tool, or a CSV export | Open a sample: do they have steps and expected results? |
| Automated tests | Your own repository | Do they run in your CI without the vendor's platform? |
| Bug history | Your Jira, Azure DevOps or other tracker | Are the open bugs filed there, not only in the vendor's tool? |
| Test reports and release sign-offs | Your shared drive | Can you show an auditor what was tested for the last releases? |
| Test data and accounts | A list you own | Which accounts, roles and data sets exist on staging? |
| Access list | Your security team | Every environment, repository and tool the vendor can reach |
If some of this lives only in the vendor's platform, export it now. We wrote a separate guide on what a QA vendor should leave behind, which is also the checklist to use when you sign the next one.
Check the new vendor for the reason you are leaving the old one
If the switch was forced, make sure the next vendor cannot be forced out for the same reason. Ask directly, and ask for evidence:
- Where exactly will the people working on our product sit? Not where the company is registered: where the engineers are.
- Which legal entity signs, and in which jurisdiction?
- Which security and quality certificates do you hold, and when do they expire? ISO 27001 and ISO 9001 are the common ones; medical and regulated work may need more.
- How is our data handled? GDPR terms, where test data is stored, and whether anything leaves your environment.
- Who owns what you produce? Test cases, automation and reports should be yours from day one.
For reference, BetterQA's engineers work from Cluj-Napoca, Romania, inside the EU, under EU data protection law. We hold ISO 27001, 9001, 14001 and 13485 certificates (see our certifications) and a NATO NCIA Basic Ordering Agreement.
Run the handover around your next release
The safest switch overlaps. If the old vendor is still allowed to work for a few weeks, have the new team start on your most important flow while the old team continues on the rest, then move area by area. If the cut is immediate, do the same thing with your own developers holding the gap.
- Week 1: NDA, access, and the new team tests the flow behind your next release, using the test cases you secured.
- Week 2: the new team reviews the inherited test cases and automation, marks what is outdated, and fills the obvious gaps.
- Weeks 3 and 4: regression for the whole product is owned by the new team; the old vendor's access is removed.
Expect the new team to find bugs the old one did not, and some the old one had already reported and that were never fixed. Both are normal and both are useful. Our checklist of what a new QA team needs in week one covers the access and accounts to prepare.
Use the switch to fix when QA starts
Many teams bring QA in at the end, once a build exists, and then squeeze it to protect the release date. A switch is a natural moment to change that. Bringing testers in when requirements are written costs the least, because a misunderstanding found on paper costs a conversation, while the same one found after release costs a fix, a retest and sometimes a customer. You do not have to change everything at once: start the new vendor on the current release, and involve them earlier on the next feature.
Frequently asked questions
Need to replace a QA vendor fast?
Tell us your next release date. We start on the flow that matters most within days of the NDA, from an EU team, and everything we produce stays in your tools.
Book a call QA outsourcingNeed help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
