What Buyers Have to Own in an Outsourcing Transition

If the contract negotiation was the awkward "meeting of the parents," the transition is the first six months of living together, marriage, kids…pretty much everything else besides retirement and death slammed into one 6-month project.

In my experience, it's the single biggest point of failure in the whole outsourcing lifecycle. At Google and as a consultant, I saw transitions so smooth they felt like magic, and others that looked like a slow-motion train wreck inside a dumpster fire. The difference usually wasn't the provider's price or the "proprietary AI" in their proposal. It was how well everyone handled the client's own internal mess.

And for those of us on the buyer side, that mess is ours. Signing the contract doesn't hand it to the provider.

Most transition plans get treated like a project management exercise. "Here's the Gantt chart, let's check the boxes." Wrong. A transition is a psychological and operational transplant. You're cutting a piece of your organization's heart out and sewing in a mechanical one. If the body rejects the organ, it doesn't matter how good the mechanical heart is.

In this metaphor, the body is your company. And companies are very good at rejecting things.

Your own team is part of the surgery

Here's the truth no buyer likes to admit: some of the people you need most for the transition wouldn't be heartbroken if it failed.

Think about it from their side. The provider is the "replacement." The team doing the work today can see the new people as a threat to their jobs, their status or their way of doing things. They'll smile in the meetings and then "forget" to send the login credentials. They'll hand over documentation that's five years out of date and written in a language only three people in the basement understand.

That usually isn't sabotage. It's human. You've asked them to train their replacements while doing their day jobs, often without telling them what happens next.

Your provider can help you spot the resistance, but it can't be your team's therapist. That part is your job, so start early:

• Work with HR on when and how to tell people what's changing and what isn't, then do it as early as you can. Don't promise what you don't know yet.
• Make knowledge transfer part of their job for the next few months. If it sits on top of a full workload, you've already decided it won't happen.
• Figure out who you truly can't lose before go-live, and have a plan to keep them through it.
• Give someone with authority the job of settling fights between "keep the lights on" and "teach the new team."

"Move the work" is not a transition plan

Break the transition down the way the work runs: by domain, then by process, then by the steps inside each process.

The domain matters more than people expect. If the work lives inside your systems and your security rules, like IT operations or finance, the body is much more likely to reject the organ than if you're moving marketing and creative work. Plan for more antibodies, more approvals and more time.

Then get to the process level. Before anything moves, you should have a map of each process detailed enough that someone new could follow it: where the work comes from, which systems it touches, what gets decided, where the exceptions live and which other teams have to do something first. Many process teams call that a Level 3 process map. You can call it whatever you want, as long as it exists.

If your plan is "just shadow our people and you'll figure it out," you're scheduling the argument you'll have in month four about whose fault the backlog is. The person who has done the job for ten years doesn't notice the little decisions that keep it working anymore. Those are exactly the decisions that go missing.

For transactional work, get it documented down to the mouse click. Yes, really. If it isn't written down, it doesn't exist, and good luck holding anyone to it.

The three black holes of transition

1. Knowledge transfer

Assume your documentation is garbage. The people who know the work best have been too busy doing it to write it down.

Don't wait for your team to write the perfect manual before the transition starts. That day isn't coming. Make creating and updating the procedures part of the provider's transition work, and have your process owners review and approve them. That way the documentation matches how the work will run, not how someone remembers it working in 2019.

Then check whether the knowledge transferred. Shadowing is when the provider watches your people do the work. Reverse shadowing is when your people watch the provider do it. Only one of those tells you whether they can do the job. Use live work, including the ugly exceptions, and agree up front what "good" looks like.

2. Technology and access (the administrative abyss)

I've watched big deals sit still for weeks because somebody couldn't get a guest badge or a VPN login. Your corporate IT is a fortress designed to keep everyone out, including the people you just hired to do the work.

So start a technical access log on day one. Every credential, software license, piece of hardware and security approval goes on it, with a named owner on your side next to each one. Not "IT." A person. If Jane from IT hasn't granted the access by Tuesday, you want to know on Wednesday, not the Friday before go-live, and it belongs on the risk report your executive sponsor reads.

Then test it with the people who will do the work, using their own accounts. "Request submitted" is not "access working."

And please don't let deadline panic turn into password sharing. Escalate late access. Don't skip your own security rules to make up the time.

3. Client dependencies (yes, that means you)

When a provider says "dependency," they're being polite. What they mean is, "The client is blocking us."

A good provider will tell you what your delays cost, in plain numbers. Something like: "The data migration file arrived four days late, so go-live moves eleven days, because the test team and trainers have to be rebooked."

Your first instinct will be to argue. Don't. Ask them to walk you through the math. If it holds up, you now know exactly where your internal bottleneck is. Once it's in black and white, you can stop debating whose fault it is and start fixing the thing that's late.

Better yet, don't wait for the provider to tell you. Keep your own list of what your side owes the transition: data, decisions, approvals, access and people's time. Put a date and a named owner on each one, and review it every week right next to the provider's status report.

Get a goddamn transition manager (actually, get two)

When a provider told me their account executive or operations lead would "manage the transition," I immediately lowered their risk score. If you're still choosing a provider, do the same with the Transition & Transformation criterion in your RFP scorecard. If you've already signed, ask for the name now.

Transition is a full-time, specialized skill. A good transition manager is part drill sergeant, part diplomat and part forensic accountant. Ask for one who is separate from the team that will run the service day to day, so they can focus on the surgery instead of squeezing it in between monthly business reviews.

Now the part buyers skip: you need one too.

The provider's transition manager can't assign work to your security team, free up your subject matter experts, settle a disagreement between two of your business units or approve a change to your own process. Somebody on your side has to own all of that, with time on their calendar and the authority to make decisions. A box on the project plan labeled "Client" is not a person.

Decide go-live on proof, not status

Every transition plan eventually turns into a status report full of green. Don't let yours become a watermelon: green on the outside, red on the inside. The question that matters is simple: what has been shown to work?

Look at readiness across people, process, technology and governance. Are the right people trained and able to do the work without someone holding their hand? Are the procedures approved and the exceptions covered? Has access been tested by the people who will use it? Does everyone know who makes the go/no-go call?

For every item, separate "claimed done" from "proven." "Training complete" is a claim. "Our team watched them handle live cases, including the weird ones, and signed off" is proof.

Some work deserves a parallel run, where both teams do the same work for a while so you can compare results before you hand it over. It costs more. So does a failed go-live.

Agree on your go/no-go criteria before the date gets close enough to create pressure. Decide who can accept a remaining risk, and write down the fallback. A fallback that depends on people who have already been reassigned isn't much of a plan.

Finally, give hypercare an exit. Hypercare is the extra support and senior attention in the first weeks after go-live. It should end when the service meets exit criteria you agreed in advance, not when the provider needs its senior people for the next deal. Without those criteria, "hypercare" can quietly become the permanent name for a service that can't run on its own.

The provider should be accountable for its commitments. Making ours just as visible is how we get the service we bought.

Take a Transition Readiness Tracker into your next status meeting

The companion workbook turns this article into a working readiness plan. Start with the filled fictional example, then use the tracker for your own transition. It comes with 23 starter items across people, process, technology and governance, and room for 60.

For each item, write what has to be true, how you'll know, your owner, the provider's owner and the date it's needed. Use the status dropdown to separate "Claimed done" from "Proven," and mark whether the item is critical for go-live and whether it's "waiting on our side." Add the provider's go-live impact estimate for anything late on your side.

The flag column does the nagging for you: critical items that aren't proven yet, anything only claimed done and anything late, especially on your side. The Go-Live Summary gives you a plain reading of where you stand, including the biggest go-live delay your side is causing.

One caution: some rows, like retention plans and risks you've accepted, are for your team only. If you walk the provider through the tracker, use a copy without them.

Use it before every weekly transition review. What's proven? What's only claimed? And what are we blocking?