Here is a number worth sitting with.
Deloitte surveyed around 170 enterprise leaders in India in February 2025. 82% had an active build-operate-transfer engagement. 12% had completed the transfer.
Seven out of eight intended handovers never happen.
The interesting part is that this is not a story about bad vendors. In Deloitte’s global survey the previous year, 82% of companies said the outsourced service had met or exceeded expectations — and 65% still wanted to bring more of it in-house. People are not insourcing because they are unhappy. They are insourcing because owning a capability is worth more than renting one, and they still cannot finish the job.
So what actually goes wrong between intent and completion?
Transfers fail in the record-keeping
That sounds like an anticlimax. It is not.
A transfer is not one event. It is a few hundred small decisions about a few dozen capabilities, made over eighteen months, by people who mostly leave before it ends. What survives that is whatever was written down in a form that forced a decision rather than described one.
Most programmes keep a project plan. A project plan tracks tasks. What a transfer needs is a record that tracks capabilities — and that refuses to let one move until it is genuinely ready.
We call ours the Capability Ledger. One record per capability. Most of its fields are descriptive: current provider, current cost, headcount, systems touched, data classification, dependencies. Useful, unremarkable.
Five fields are different. They change behaviour rather than describing it, and between them they account for most of the gap between 82% and 12%.
1 · Own, rent or automate — with a decision date
Not a status. A decision, with the day it was made attached.
Without the date, this field decays into a wish. Capabilities sit in “to be decided” for a year because nobody has to say when the decision happens. Attach a date and the ambiguity has a deadline.
The three-way split matters too. Most transfer programmes have two states in their heads — moving, or not moving. Adding automate as a first-class option changes what gets moved. A capability that is largely rules-based should not be transferred at 2026 wages and then automated in year three. It should be automated first and transferred small, or not transferred at all.
Roughly half the arguments a steering committee has about a transfer are really arguments about this field, held without it.
2 · One named client-side owner
Not a team. Not a function. A person, on the client’s side.
The rule we apply is blunt: if the owner field contains one of our names, that is a defect. A capability whose owner works for the vendor has not been transferred, whatever the status column says.
This is the field that stops the most common quiet failure. Work moves across, the paperwork closes, and eighteen months later nobody at the client can say who owns the outcome — so decisions still route back to the vendor by default, because that is where the last person who understood it sits.
Everest Group has a name for the general version of this. Reviewing capability-centre partnerships, it flags “undefined day-two accountability — SLAs, ownership, exit and transfer mechanics” as a recurring risk. A single mandatory field is a crude fix for a real problem, and crude fixes that are enforced beat sophisticated ones that are not.
3 · A value metric, required before transfer
No metric, no transfer. As a gate in the data, not a habit in the process.
Two things happen when this is enforced.
The first is obvious: at the end, you can prove something. The second is more useful. Roughly one capability in five turns out not to have a value metric anybody can agree on — and that is a finding, not an inconvenience. A capability nobody can measure is usually a capability nobody has thought about properly, and it should not be the thing you move first.
The related discipline is freezing the baseline. Measure the current state, sign it, and date it before transition starts. Unfrozen baselines are the single most common reason a centre cannot prove its savings at year two. The saving was real. Nobody can demonstrate it, because the comparison moved.
And measure the right thing. Most programmes track cost in the new location. The number that matters is the cost that came out of the old one. If headquarters headcount is flat a year after transition, two teams are doing one job and there is no saving to find.
4 · A transfer state with a signed exit test
Five states: not started, scoped, transferring, transferred, blocked.
The state on its own is bookkeeping. What makes it load-bearing is the gate attached: a capability cannot reach transferring without an exit test, and the exit test must be written and signed by the client before the wave starts.
The order is the whole thing.
If the vendor defines “done”, “done” arrives when the vendor’s work is finished. If the client defines it afterwards, the definition moves under pressure until it matches whatever happened. Written first, by the receiving side, it is a real test — and it can be failed.
Failing it has to cost the vendor something, or it is theatre. On our own engagements the completion fee is not payable on a failed exit test, and accountability does not transfer: the record stays at transferring, the root cause gets published within five working days, and the wave runs again against the same test.
That is not generosity. It is the only arrangement under which the test means anything.
5 · A confidence marker on every record
Four values: verified, stated, estimated, assumed.
This is the least glamorous field and the one people push back on hardest, because it makes a document admit what it does not know.
That is the point. A ledger with no confidence marking reads as fact throughout. Six months in, somebody makes a sequencing decision on a cost figure that was a guess in week two, and nothing in the record ever said so.
There is a second-order effect worth having. When confidence is visible, it becomes measurable — you can watch the share of assumed fields fall as discovery proceeds, and you can refuse to start a wave where the critical fields are still guesses.
What the five have in common
Each one converts a judgement into a gate.
You cannot move a capability without a decision, an owner, a metric, a signed test and an honest confidence rating. None of those is difficult. All of them are easy to skip when a date is slipping, which is exactly when skipping them does the damage.
The 12% completion rate is not caused by anything exotic. It is caused by a hundred small moments where the record allowed something through that it should have stopped.
Iksula helps retail and consumer brands move commerce operations — product content, catalog, PIM/DAM, digital shelf, marketplace and seller operations — into a capability centre they own. The Capability Ledger is the record our Commerce Capability Center engagements run on, and it lives on the client’s infrastructure, not ours.
Sources: Deloitte India Outsourcing Compass, February 2025 (~170 leaders) · Deloitte Global Outsourcing Survey 2024 · Everest Group commentary on GCC set-up partnerships.
