When a GCC Build-Operate-Transfer engagement reaches its Transfer date, three things move to you: the legal entity (or a clean novation into your own entity), every employee's contract, and the infrastructure the center runs on. If any of those three is vague in your agreement, you'll find out exactly how vague at the worst possible time: during the transfer itself.
What exactly transfers on the Transfer date?
Three categories. A real BOT agreement names all three specifically rather than describing them in general terms.
First, the legal entity itself. Either the India subsidiary changes hands directly, or, if it was structured as a vendor-held entity, there's a clean asset and liability transfer into an entity you control. Second, every employee's contract is novated directly to you, meaning the employment relationship becomes yours, not a sub-contracted arrangement that keeps running through the original partner. Third, the infrastructure: office lease, hardware, software licenses, domain and DNS records, GitHub or GitLab organization ownership, and any internally built tooling the center depends on day to day.
Who owns the IP that was built before the transfer happened?
You should, from the very first line of code, not starting on the transfer date. This is the single most important detail to verify before signing anything, not after.
IP assignment terms belong in the original Build-Operate-Transfer agreement, assigning everything the center produces to you as it's created. A partner who frames IP assignment as something that gets resolved "at transfer" is telling you, whether they mean to or not, that your ownership is conditional until that point. Ask to see the exact IP assignment clause before the center is built. A vague answer here isn't a minor gap, it's the whole deal falling apart in slow motion.
What happens to each employee's tenure, benefits, and statutory dues?
In a properly structured novation, nothing resets. Tenure, accrued leave, gratuity eligibility under the Payment of Gratuity Act, leave entitlements under the Shops and Establishments Act, and Provident Fund contributions tracked under the employee's existing EPFO account (the UAN) all carry forward as though the employee had always been employed by the entity they're moving into. That continuity is the legal point of a novation, as opposed to a termination and rehire.
A transfer that quietly restarts everyone's tenure clock, resets probation, or issues a brand-new offer letter as if day one just happened again isn't a real transfer. It's a relaunch with different paperwork, and it costs you retention exactly when you can least afford it.
Does the infrastructure actually transfer, or does it stay dependent on the vendor?
This is where a lot of "transfers" quietly fail.
Office leases, software licenses, and cloud accounts (AWS, GCP, Azure, whichever you run on) need to be either held in your name from day one or assignable to you without requiring the original partner's continued involvement. Internally built tooling, deployment scripts, Terraform or CDK infrastructure code, monitoring dashboards in Datadog or Grafana, CI/CD pipelines, needs documentation in Confluence or Notion good enough that your own engineers can run it without calling the old partner for help. If any piece of infrastructure still needs the vendor's account, license, or tribal knowledge to keep functioning after transfer, that's a dependency nobody told you about. And it defeats the point of transferring at all.
What should be in writing before the center is even built, not negotiated at transfer time?
Four things, specifically.
The transfer date or the criteria that trigger it, so neither side is guessing when the clock starts. The IP assignment terms, covering everything produced from day one, not just what exists at transfer. The novation mechanics for every employee, so tenure and benefits are explicitly preserved. And a named list of what infrastructure transfers versus what gets freshly licensed in your name at transfer, so there's no ambiguity about which systems you actually own afterward. If a partner can't produce draft language for all four before you sign, the "transfer" part of their BOT offering is marketing, not a structured commitment.
What should you check in the weeks immediately before transfer?
Run a dry audit roughly 60 to 90 days out, and plan for a 30-day handover window once the audit clears.
Confirm every employee's contract is ready to novate, with no gaps in their service record and their Form 16 and PF history intact. Confirm every software license and cloud account is either already in your name or has a documented, tested path to move into it. Confirm the IP assignment chain is complete for everything built, not just the headline product. And confirm there's a named person on your side who will own the center operationally the day after transfer, because a transfer without a receiving owner on your team is a transfer into a vacuum.
For the fuller picture of how we structure this against building your own entity from scratch, see our BOT vs own-entity comparison, and if you're still deciding whether a GCC is the right move at all, read our GCC vs staff augmentation decision guide.
If you're evaluating a GCC and want to see exactly how we write the transfer terms into the agreement before a single person is hired, see our GCC India page or talk to us directly. Before signing with any partner, run them through our GCC vendor vetting checklist, and if you're still scoping the timeline, see how long it actually takes to build a GCC in India.