The Build-Operate-Transfer Exit Nobody Documents
A build-operate-transfer exit is the moment a vendor-built Global Capability Center (GCC), a wholly owned offshore team that a company runs as its own extension, stops belonging to the vendor and becomes yours. Every BOT provider sells the build. Far fewer will walk you through the transfer, which is exactly where the model is proven or exposed. Below is what actually changes hands, what a vendor gives up, when you should not transfer at all, and how to write the exit into the contract on the first day rather than the last.
We build these to be given away. That sentence sounds odd coming from a vendor, so let me be plain about it. The whole promise of build-operate-transfer is that the center ends up yours. A vendor that is aligned with you designs the entire engagement around a clean handover, and treats the transfer as the deliverable rather than the loss. A vendor that is not will make the build easy and the exit quietly hard. The difference is visible years before you reach the transfer, if you know where to look.
What triggers a build-operate-transfer exit?
There are two kinds of trigger, and confusing them is the first mistake.
A contractual trigger is a date or a milestone written into the agreement: transfer after a set operate period, or on reaching an agreed headcount, or at the end of a term. It is clean to write and easy to hold both sides to, and it gives everyone a fixed horizon to plan against.
A readiness trigger is different. It asks whether your side can actually run the center: whether you have leadership on the ground or nearby, whether the local entity and compliance are in a state you can carry, whether the team would stay through the change, whether the processes are yours in practice and not just on paper. Readiness is harder to measure and easy to overstate.
The healthiest engagements use the contractual trigger as a planning anchor and the readiness trigger as the real gate. When the two disagree, readiness should win. Transferring a center on the calendar while your side is not ready to hold it is how a good build becomes a bad year. If your BOT partner only ever talks about the date, ask them how they will know you are ready, and listen for whether they have an honest answer.
What actually changes hands at transfer?
People imagine transfer as handing over a login. It is closer to handing over a small company. Here is what actually moves, and what to confirm on each before you sign the build, not the exit.
| What changes hands | What it means at transfer | What to confirm on day one |
|---|---|---|
| Legal entity and compliance | The local company, its registrations, tax, and statutory filings become yours to own and maintain | Whether you inherit the entity or set up a new one, and who carries liabilities during the switch |
| Employment contracts | The team moves onto your payroll and your terms | How contracts novate, what continuity of service and benefits look like, and consent from employees |
| IP and code | Ownership of everything built moves to you, or was always yours | That IP was assigned to you as created, plus repositories, licenses, and third-party components |
| Vendor relationships | Tooling, cloud, and third-party contracts transfer or are renegotiated in your name | Which contracts are assignable, which must be re-signed, and any price changes at your scale |
| Processes and playbooks | The documented way the center works becomes yours to run and change | That documentation is real and current, not written the week before transfer |
| Leadership and management | The reporting line moves from the vendor to you | Who leads on your side from day one, and whether that person was involved through the operate phase |
The pattern across every row is the same. A transfer is clean to the exact degree that these were set up to be yours from the beginning. The entity, the IP, the contracts, and the people all transfer smoothly when the build was structured for the handover. They snag when the build was structured for the vendor.
Who moves to your payroll, and how does attrition behave at transfer?
This is the part vendors soften and I would rather not. A transfer moves people, and people notice.
The team you built is the center. The entity and the code are the easy part; a stable, motivated team is the thing you are actually paying for. At transfer, that team learns that the company they work for is changing, that their contracts are moving, and sometimes that the badge on the building is different from the one they joined. Handled well, this is a promotion in disguise: they become part of the company whose product they have been building. Handled badly, it reads as being sold, and some of your best people will test the market.
What separates the two is not luck. Centers transfer with retention intact when the people were hired for you from the start and knew it, when the plan was shared early rather than sprung, and when the destination is somewhere they want to be. Attrition climbs when the move is a surprise, when the new owner feels like a step down, or when the transfer drags with no clarity. I will not put a number on the swing, because the honest answer is that it depends on how you handled the year before. Plan as though transfer will test retention, because it will, and design the communication, the retention terms, and the leadership presence to pass that test.
What a vendor gives up at transfer, and why an aligned one structures for it anyway
Here is the honest bit from my side of the table. At transfer, the vendor loses recurring operate revenue, a running team, and a reference account that was easy to keep. That is a real cost, and it is why some vendors quietly make the exit sticky.
An aligned vendor structures for the transfer anyway, for reasons that are not charity. A clean exit is the strongest proof the model works, and that proof brings the next client. A team that transfers well and stays becomes a reference that sells for you. And a vendor that is trusted to give a center away is trusted with the next build, the second city, the harder problem. The economics of doing it right are slower but far larger than the economics of holding a client hostage to the operate phase. If a vendor cannot explain why the transfer is good for them too, that is a signal.
What still needs the vendor in the 90 days after transfer?
Transfer is not the end of the relationship; it is the change in its shape. The first stretch after the entity and the team are yours is where a rushed handover shows its cracks.
In that window, the vendor typically still supports the team while your leadership takes full control: answering the questions only the people who built it can answer, staying available for the systems and integrations that were their work, and helping your new managers settle without the original knowledge walking out the door. Frame this as transition support with a defined shape and end, not an open-ended dependency. You want the vendor close enough that nothing breaks and far enough that the center is genuinely yours. Write that support period into the contract with its scope and its end, so it is a plan rather than a favor you have to ask for.
When should you not transfer?
Sometimes the right answer is to stay in the operate phase, and a partner worth having will say so.
Do not transfer if your side does not yet have leadership ready to run the center. Do not transfer if the local entity and compliance are complex enough that carrying them would pull your attention off the work the center exists to do. Do not transfer if the team would not survive the change, and you have not yet built the reasons for them to want to stay. And do not transfer simply because a date arrived, when everything else says wait.
Staying in operate longer is not failure. It is choosing a center that runs over a milestone that looks good in a status update. The model gives you the option to transfer; it does not oblige you to exercise it before you are ready. For a picture of how the earlier phases set this up, our guide to how to set up a GCC in India walks the build and operate stages that make a later transfer clean, and GCC for PE portfolio companies covers the ownership questions when a center sits inside an investment thesis.
How do you write the exit into the contract on day one?
The single most useful thing you can do about the transfer is to negotiate it while you are negotiating the build, when you hold the most bargaining power and the least pressure.
Put the exit in writing on day one. Define the triggers, both the contractual date and the readiness criteria, and say which one governs. Assign IP to you as it is created, so nothing has to move at transfer. Specify how employment contracts novate and what the retention terms are. List which vendor and tooling contracts are assignable. Fix the transition support period, its scope, and its end. And name who leads on your side through operate, so the person taking the center over is not meeting it for the first time at handover.
An engagement that is built to be transferred reads completely differently from one that is built to be extended, and the difference is legible in the contract before a single person is hired. This is the scale the model now operates at: India hosts 583 mid-market GCCs and 504 PE-backed centers per the Zinnov-Nasscom GCC Landscape FY2026 report, and a large share of those were meant, at some point, to change hands. The ones that transfer well were written to.
If you are weighing a build-operate-transfer center and want to know what a clean exit looks like before you commit, that is a conversation we are glad to have. Read how we approach a Global Capability Center build, see the case for a second city once the first center is stable, or talk to us about structuring the transfer into the contract from the first day.
