Why vendor handoffs break, what to do before you announce, and how to move the work without paying twice.
You already know the vendor isn't working. A runbook or a report comes back as someone else's job, and the work lands on your senior engineers anyway. The harder question is how to leave.
Source: Deloitte, Global Outsourcing Survey 2024
You're not alone in wanting out. In Deloitte's 2024 Global Outsourcing Survey, most organizations had taken back part of their outsourced scope in the past five years, and the most common reason was better control over service quality and performance. Leaving a vendor is routine; leaving without a gap in coverage is not.
So how do you move operations off a vendor without a new budget line, a coverage gap, or your own engineers absorbing the cost? Here's what we've learned from taking over from vendors, in good handoffs and bad ones.
Most transition plans assume the outgoing team will hand over what it knows. That assumption fails for three reasons, and none of them is about bad people.
Once a vendor knows it isn't renewing, your transition competes with the accounts it's keeping. Knowledge transfer sessions slip, staff get reassigned, and the team rides out the remaining term.
Documentation is usually thin, out of date, or written for people who already know the system. What matters lives with the team that's leaving.
When the handoff fails, someone still has to onboard the new team, and it's your senior people, on their own time, while they cover the gap. That's the real price of a bad switch, and it never shows up on an invoice.
The most important work happens before the vendor knows you're leaving.
A single cutover date puts all the risk on one day and all the cost on one budget. Moving the work in portions spreads both. Split the work the way your operation is already organized: by shift, by service, or by channel.
See how we run each phase of a vendor transition.
See how it worksEvery transition lands somewhere between two cases. In the cooperative one, the outgoing vendor works the plan, and the new team shadows, then reverse shadows, on the schedule you agreed. In the other, the outgoing team stops talking.
We've been on the receiving end of the second. A large enterprise's search platform, serving multiple internal teams, was staffed through one of the world's biggest IT outsourcing firms. About a week into the handoff, communication stopped, and the customer's engineers had to onboard us on their own time.
So we started with the noisiest channel. We took the pager from day one, and much of what it carried was alert noise, so we tuned thresholds until a page meant a real problem. We shadowed each escalation and took over each type of page as we learned it, while support channels and tickets came across in the quieter hours.
The runbooks that existed were out of date and missing environment-specific steps, so we rebuilt them from what was actually running. We cross-trained the whole team and asked why each step existed, so knowledge didn't sit with one person and a broken process didn't get repeated. We'd already run other platforms for the same customer, which shortened the ramp.
The transition held. But it was a hard cutover with no warning, and the customer's engineers carried onboarding their old vendor was paid to do. That's the cost the rest of this guide is designed to avoid, and it's why we tell every team to start before they announce.
Knowledge that belongs to a whole team, not one person, is what makes a switch stick. As an SRE manager at another customer put it:
"I've been in this industry for almost 19 years. I've never seen a vendor that does such a great job of cross-training their teams and following through on the information given to them."
Whoever you bring in, these questions separate a plan from a pitch.
Bring your current coverage model and your vendor's contract. We'll walk through where the risk sits and what the first portion could look like.
You define the outcomes. We own the delivery.