This deep dive expands on the Loop Asia conversation with Nilesh Gule, Enterprise Architect, Microsoft MVP, and Docker Captain.

In the middle of a conversation about agile teams and shift-left testing, Nilesh Gule dropped a sentence most technology leaders will recognise instantly and most business leaders badly underestimate: "If you have to move from, let's say, one source code management system to another, it could take you years to do that... if it's a very large organization."

He wasn't describing a failed migration — a normal one, in a healthy, well-run enterprise.

The technical work is not the long pole

Gule's point is that "change management plays a key role" in why these migrations run long — not the technical lift of moving data or reconfiguring pipelines. The cutover is schedulable. What isn't is every workflow and undocumented dependency that has quietly grown up around the old system over years of business-as-usual, invisible until someone tries to move it. A board hears "migrate the source control system" and pictures a start date and an end date; the actual timeline is set by how many of those dependencies exist — and nobody has a complete map going in, because if they did, the system wouldn't be this hard to leave.

Why the executive, not the engineer, has to own this

Gule's broader theme — that DevOps outcomes depend more on organisational structure than on tooling — applies here with force. A migration off a core, business-critical system is a sequencing problem: whose workflow breaks first, which roadmap gets frozen, which senior engineers get freed up to move the legacy system safely. Those are executive decisions triggered by a technical event, not technical decisions themselves. An engineering team can plan the cutover; it cannot decide that another business unit's roadmap should slip to make room for it. That takes someone with standing to make trade-offs across the organisation — why these projects stall when left to the team closest to the problem, and why they need active sponsorship, not a quarterly status report.

What "governing it strategically" actually means

Governing a legacy replacement well means treating "it could take you years" as a planning input, not a surprise: map dependencies before committing to a public timeline, decide early who has authority to reprioritise other teams' work, and assume the hardest parts of the project are organisational, not technical.