The budget is spent
There’s no line item for switching costs or a transition plan. Paying two teams to cover the overlap typically isn’t something you can take to finance.
Switch vendors without a coverage gap
You’re paying for staff aug that isn’t working, and your budget is committed. We take on defined portions of work in phases, so coverage holds through the switch and legacy vendor budget is released as each portion is accepted.
Challenges of switching
The handoff has no owner
The team on its way out has no reason to train the team coming in. Assume the documentation is limited and the knowledge walks with the previous team.
How the transition works
We work with you to identify a defined portion of work. You choose the work that fits how your operation is organized. The switch typically runs in four phases.
Phase 01
Discovery and access
Your investment is time and access, not budget. We absorb the cost of assessment so there’s nothing to fund before you’ve seen the plan. Scope and limits are agreed per engagement and written into the SOW.
Phase 02
Fund the first portion
Match the initial scope to contractor budget you can release.
Phase 03
Verify readiness
We shadow your team, then reverse shadow until you accept that we’re ready.
Phase 04
Expand coverage
The next shift, service, or channel moves across once we’re ready and the matching legacy vendor budget can be released.
By shift
One shift, then the rotation
For a 24/7 shift we can take on one shift (for example 8/5), then the entire rotation. We own a set block of hours. When it’s steady, we take the next block, through to full coverage.
By service
One service, then the next
We own a single service end to end. Once it runs clean, the next one moves across.
By channel
One channel at a time
The ticket queue, the support channel, or the pager. Which comes first depends on where your need is greatest.
Every portion we own is a portion you stop buying from the legacy vendor. Coverage grows on one side as it winds down on the other, so the budget moves instead of increasing.
Coverage holds. Spend moves, it doesn’t grow
Each step is a portion of work you release from the legacy vendor and we take on.
Total coverage: 100% throughout
Phase 1: Discovery and accessYour investment is time and access, not budget
Phase 2: Fund the first portionOne released line funds a pilot scope
Phase 3: Verify readinessShadow, then reverse shadow, until you accept readiness
Phase 4: Expand coverageNext portion moves as legacy budget is released
Illustrative. Step count and pace depend on scope, access, and how fast portions are released. Typically a few months inside a multi-year relationship.
One process regardless of the handoff
Every transition lands somewhere between two cases, and we’ve run both.
The cooperative case
The legacy vendor works the plan. We shadow, then reverse shadow, on the schedule you agreed. Everyone plans for this one; it’s the rarer one.
The dark case
The day you announce, they go quiet: Slack stops, people get reassigned, documentation turns out thin or missing. We’ve taken over from many vendors that stopped cooperating.
How the budget moves
You reallocate budget freed from the legacy vendor. No new funds. Every transition is priced for the work in front of us, not off a rate card.
Step 01Free up contractor budget. As low as a single contractor line. That line is the entry point. No new funding request to finance.
Step 02That line funds the first portion. One line typically funds 8/5 coverage, set where the hours overlap your subject matter experts so knowledge transfer happens. You get a team, and the team trains itself.
Step 03Price follows coverage. Early months are priced for the coverage in place, not full coverage.
Step 04The schedule is in the SOW. Pricing and coverage changes are agreed upfront, so you transition off the legacy vendor as coverage moves.
What we need from you
Access, started early
IT access, background checks if you require them, ticket history, monitoring tools, wikis, docs, and runbooks. Standard access takes one to two days; anything needing a security review typically takes one to three weeks.
Time with your engineers
Pairing is how knowledge moves. We can’t count on the outgoing team to hand over what they know.
One owner, plus a technical contact
One decides what transfers next. One knows how things actually work.
Their contract, not just the end date
Notice periods, change-order terms, handback duties, and any clause that lets you reduce scope. Those terms decide what can move and when.
Where to start
- Read the contract first. The people running operations rarely signed it and almost never read it. Find the notice period, change order, scope reduction, and handback clauses, and hold the legacy vendor to them; if they aren’t there, plan for the dark case.
- The safe start is the ticket queue. Over 10 years alongside the world’s leading engineering teams has taught us that. With a longer SLA (e.g., two days), it’s an effective place to learn your environment, processes, and tools.
- If the pain is the pager, we take the pager. Pages still come back to your engineers while we ramp. We shadow those pages until we’re ready to take them over.
- Every portion gets a discovery pass before it moves. What it does, who owns it, what it depends on, how it escalates today, and how much work comes through and when. Same onboarding template on every engagement.
- The score sets the order. We score each portion for complexity, volume, and difficulty, and that decides what moves next.
- We schedule the next portion during the current one. If something slips (a knowledge transfer session with nobody to run it, or a scheduling conflict), you hear it from us with what we’re doing about it.
We’ve done this before
The worst case, handled
A large enterprise’s search platform, serving multiple internal teams, was staffed through one of the world’s biggest, best-known IT outsourcing firms. It wasn’t delivering. Simple asks, a runbook or a report, came back as someone else’s job and landed on the customer’s senior engineers.
- The vendor went dark. About a week into the handoff, communication stopped. The customer’s engineers had to onboard us on their own time.
- Pager first. We took the pager from day one, the noisiest channel. Much of it was alert noise, so we tuned thresholds until a page meant a real problem. Support channels and tickets came across in the quieter hours.
- Shadow, then own. We shadowed each escalation and took over each type of page as we learned it, taking load off the customer’s engineers as we went.
- Platform operations, too. We picked up upgrades, scheduled with each internal team, plus day-to-day operations of the platform.
- Runbooks rebuilt. What existed was out of date and missing environment-specific steps, so we rebuilt them for the whole team. We’d run other platforms for the same customer, which shortened the ramp.
- Why, not just how. We cross-trained the whole team and asked why each step exists, so knowledge didn’t sit with one person and a broken process didn’t just get repeated.
The lesson: even when the legacy vendor walks away, the transition holds. The customer’s engineers still carried onboarding their vendor was paid to do, which is why we say start before you announce.
If it isn’t working
You’ll know inside the first quarter, and so will we. We hand back the portions we hold; the rest of your coverage is untouched. The real risk of a bad switch is finding out in month nine, not month three.
Next step
Let’s map your transition
Bring your current coverage model and the legacy vendor’s contract. We’ll come back with the transition plan and what the first contractor line delivers.
OpsWerks runs 24/7 platform and infrastructure operations as a managed service, not staff augmentation.