Decision intelligence · India GCC
GCC Transition: How Work Should Actually Move
Transition is where a good business case is either realized or quietly lost. The technical mechanics are well understood; the failures are about knowledge, incentives and pace.
Dual running is not waste. It is the insurance premium on service continuity, and cutting it is the most common false economy in capability-center programs.
Decision intelligenceWritten by NirjiX GCC AdvisoryReviewed by Ramesh Rathi, Vice President — GCC Enablement & ImplementationPublished January 2026Last reviewed February 202610 min read
Direct answer
How should work move into a GCC?
Move it in waves, each with documented processes, a defined knowledge-transfer period, a dual-running phase and explicit acceptance criteria before the sending team stands down. Sequence waves so early ones build credibility and prove the transition machine, and resource knowledge transfer as real work for both teams rather than as an overlay on existing workload. The principal risks are sending-team incentives, undocumented tacit knowledge and compressed timelines — and all three are management decisions rather than execution problems.
Why transitions fail
The most common cause is incentive misalignment. The people who know the process best are frequently the people whose roles change once it moves. Expecting comprehensive knowledge transfer from a team with no stake in the outcome is a design error, not a performance problem, and it is addressed with retention arrangements and explicit recognition rather than with escalation.
The second cause is compression. Timelines are set from the business case rather than from the work, and knowledge transfer is the phase that gets shortened when earlier phases slip. The consequence appears one or two quarters after go-live, as quality degradation and rising escalations that nobody attributes to the compressed transfer.
The third is undocumented tacit knowledge. Processes are transferred as documented, and the documentation omits the exceptions, workarounds and informal judgement that make the process work in practice. The receiving team then rediscovers all of it under production pressure.
Transition phases and their acceptance criteria
Each phase should end in a decision. A phase without an acceptance criterion becomes an elapsed period rather than a gate.
| Phase | Principal activity | Evidence to progress |
|---|---|---|
| Preparation | Process documentation, access provisioning, team hired and onboarded, measures baselined. | Documentation reviewed by the receiving lead; baseline measures agreed by both sides. |
| Knowledge transfer | Structured shadowing, walkthroughs, exception handling, documented Q&A. | Receiving team can describe the process including exceptions, in their own terms. |
| Reverse shadowing | Receiving team performs the work with the sending team observing and correcting. | Quality maintained across a representative period, including a month-end or peak cycle. |
| Dual running | Receiving team owns execution; sending team available for escalation only. | Escalation rate falling and quality stable against the pre-transition baseline. |
| Steady state | Full ownership including exceptions and improvement. | Formal acceptance, measures transferred, sending capacity released. |
Risks to manage explicitly
- Sending-team attrition during transfer, taking undocumented knowledge with it.
- Retention arrangements absent for the people whose cooperation the transfer depends on.
- Receiving-team attrition after knowledge transfer but before steady state.
- Timeline compression driven by business-case dates rather than by demonstrated readiness.
- Peak-cycle exposure: going live immediately before a month-end, quarter-end or seasonal peak.
- Access and tooling provisioning delays, which routinely consume weeks of the transfer window.
- Quality measured only after go-live, leaving no baseline to compare against.
These do not surface in status reporting until they are expensive. Track them deliberately.
How to run a transition wave
The pattern repeats per wave; the discipline is in refusing to progress on schedule rather than on evidence.
- 01
Document before you transfer
Document the process as performed, including exceptions and workarounds. Documenting the idealized process transfers a version of the work that nobody actually does.
- 02
Align the sending team's incentives
Agree retention, recognition and future-role clarity before transfer begins. Cooperation cannot be mandated, and its absence is invisible in reporting until quality moves.
- 03
Resource knowledge transfer as real work
Both teams need protected capacity. Transfer performed on top of full workloads is transfer performed badly, and it is the cheapest place to lose the business case.
- 04
Progress on evidence, not on date
Use the acceptance criteria. Moving to the next phase because the plan says so is how service degradation is scheduled.
- 05
Run dual running properly
Keep the sending team available for escalation through at least one full business cycle. This is the insurance premium on continuity, and it is the item most often cut under cost pressure.
- 06
Accept formally
Close the wave with a documented acceptance covering measures, ownership and residual risks, then release the sending capacity deliberately rather than by drift.
NirjiX view
The NirjiX view
We treat the sending team's incentives as the first design question in any transition, ahead of the plan. Every other risk is manageable; a team with no reason to transfer knowledge well is not, and no amount of governance recovers it.
We also advise clients to plan the first wave for credibility rather than for savings. A wave that lands cleanly buys the organizational confidence to attempt the difficult scope; a first wave that degrades service sets the program back by a year regardless of what it saved.
Frequently asked executive questions
- How long should a transition wave take?
- It depends on process complexity and documentation quality, but the phases should not be skipped. A well-documented, moderately complex process typically needs a knowledge transfer period, a reverse-shadowing period and a dual-running period each measured in weeks — and compressing dual running is where continuity risk concentrates.
- How much dual running is necessary?
- At least one complete business cycle, including a peak or period-end if the process has one. Dual running is where the exceptions that documentation missed appear, and cutting it converts a manageable transition cost into an unmanaged service risk.
- How do we get cooperation from the sending team?
- Address it structurally: retention arrangements, clarity about future roles, and explicit recognition of transfer as part of the job. Relying on professionalism alone is a design decision to accept a significant risk, and it is the most common cause of a knowledge gap that appears months later.
- Should transition be run by an external partner?
- A partner can supply transition management capability, particularly for a first wave. Process ownership and acceptance decisions should stay internal — if a partner decides when the work has been accepted, the organization has outsourced the judgement it most needs to retain.
- What would justify pausing a transition?
- Failure to meet an acceptance criterion, material attrition on either team, or a quality trend moving away from baseline during reverse shadowing. Pausing is inexpensive relative to a degraded service that has to be recovered under scrutiny.
The main guide on this topic
How do you set up a Global Capability Center in India?
This page covers one part of the decision. The full NirjiX guide to GCC setup in India sets out the whole picture.
GCC setup in India →Decide next
Related decisions
- 01 · GCC decisionGCC work splitWhich processes should move end to end, and which should stay.
- 02 · GCC decisionGCC setup roadmapThe realistic sequence from decision to a functioning center, and where timelines slip.
- 03 · GCC decisionGCC talent and attritionWhat actually holds a capability center together once the first hiring wave lands.
- 04 · GCC decisionGCC governanceReporting lines, decision rights and the measures that set the center's ceiling.
Continue
Related intelligence
- DecisionGCC work splitDeciding what should move before deciding how it moves.
- DecisionGCC setup roadmapWhere transition waves sit in the wider establishment sequence.
- DecisionGCC talent and attritionThe retention dynamics that decide whether transferred knowledge stays.
- PortalBuild the GCC blueprintSequence waves, governance and organization design together.
Transparency
Sources and methodology
This page reflects NirjiX practitioner experience designing, costing and standing up capability centers in India, and the same modelling logic used in the NirjiX GCC business case builder and blueprint.
We do not publish generic per-seat or per-FTE benchmarks as if they were universal. Compensation, real estate, statutory cost and attrition vary materially by city, role mix, seniority and hiring speed, and a business case built on an averaged benchmark is usually wrong in both directions at once.
The models we build with clients use your own baseline cost, your own role mix and your own ramp assumptions, then stress-test them with sensitivity ranges rather than presenting a single deterministic number.
Test the decision against your own numbers
The GCC assessment establishes whether the workload and economics support a center; the business case builder models the cost, savings and sensitivities behind it.
Outputs are preliminary and intended for advisor validation before investment decisions.