Every few months the same chorus surfaces: “Azure DevOps (AzDO) is going away,” others declare, while many teams continue to use it with enormous success. Then there are the pragmatic hybrid adopters who quietly get on with delivering value.

I am firmly in the pragmatic camp. We must consistently pursue what is right for the organisation and our stakeholders, rather than what merely appears right for engineering or reflects the latest vendor trends. With that in mind, I see absolutely no stakeholder value, risk reduction, or cost avoidance in migrating thousands of repositories and pipelines from one platform to another simply because of market hype. While I admire the innovation GitHub is driving with Artificial Intelligence, I am cautious not to lock our engineering ecosystem into a single vendor. We have the skills and the vision to build our own agentic AI engineering capabilities that serve a hybrid mindset across GitHub, Azure DevOps, and any other service that makes sense.

The Myth of Azure DevOps Sustainment

Some argue that Azure DevOps is in sustainment mode. If that is true, then why is GitHub integrating seamlessly with Azure Boards and other AzDO services? The answer is simple. Real value comes from integration and interoperability, not from an ideological commitment to one platform or another.

Azure DevOps is mature. It does not need a flood of new features to remain relevant. When combined with agentic Artificial Intelligence, it becomes a stable foundation for an engineering platform that is future‑proof, vendor‑agnostic, and designed to enable teams rather than box them in. I appreciate GitHub Copilot, but I do not want our engineers forced into a single technology stack. Choice is power. Let us explore what our investigations have revealed.

Azure DevOps and GitHub Enterprise: Coexistence, Not Competition

Azure DevOps Remains a Key Player

Recent conversations with Microsoft engineers confirmed what our experience already suggests. Azure DevOps is alive, well, and growing. Since Microsoft acquired GitHub, Azure DevOps has not shrunk but expanded dramatically to more than 4 million customers.

The story is not replacement. It is coexistence.

The integration between GitHub Enterprise and Azure DevOps continues to improve. GitHub works seamlessly with Azure Pipelines. GitHub uses Azure Boards internally. This is not a company preparing to deprecate a product. This is a company deliberately supporting hybrid enterprise engineering environments.

A Hybrid Ecosystem That Reflects Reality

Modern enterprises rarely operate in absolutes. The market no longer demands a monolithic toolchain. Instead, it rewards flexibility. A hybrid approach allows us to choose the right tool for each initiative. Some projects will benefit from GitHub Enterprise’s rapidly evolving AI capabilities. Others will remain better served by the maturity and stability of Azure DevOps.

The result is a more responsive engineering ecosystem, one aligned with project requirements, stakeholder expectations, and long-term maintainability.

Navigating AI Innovation with Intent

GitHub Enterprise is accelerating the development of Artificial Intelligence features at an impressive pace. However, not every feature will deliver meaningful value across every application or team. Transitioning repositories from Azure DevOps simply to gain access to AI features must be justified by a real return in stakeholder experience, risk reduction, or cost avoidance.

This is disciplined engineering, not blind adoption.

GitHub Copilot as the Bridge

GitHub Copilot serves as an intelligent bridge between the two platforms. Many of the emerging GitHub AI capabilities will surface in Azure DevOps over time. Others may never appear. That is fine. What matters is that we evaluate each capability carefully, understand its organisational impact, and adopt only what genuinely moves the needle.

Adoption Must Be Case by Case

As we evaluate GitHub Enterprise, we are taking a measured, strategic approach. Our decisions must be grounded in value. Some projects will justify adoption. Others will not. And many will thrive in a hybrid model.

This is not about choosing sides. It is about choosing outcomes.

Final Thoughts: The Cost of Forced Migrations

Before we conclude, I want to highlight an important principle that often gets overlooked in the technology landscape. Vendors should never pressure enterprises into product migrations without first considering the downstream impact on stakeholder experience, organisational risk, and the real cost of such transitions. When a vendor insists on a forced or accelerated migration path, they unintentionally introduce the very risk they claim to be helping us avoid.

If an organisation feels pressured into a migration, what prevents that organisation from using the moment to evaluate alternative solutions? In the worst‑case scenario, the enterprise may not only abandon the forced migration but may also reconsider its long‑term relationship with the vendor and its products altogether. Strategic trust is fragile, and once it is compromised, it can accelerate a shift away from a vendor far faster than any technical roadmap. This is why our approach must remain deliberate, value‑driven, and grounded in disciplined engineering principles. Our decisions must serve our people, reduce risk, and avoid unnecessary cost — never the other way around.

In Closing

I am not here to push anyone in a particular direction. I am here to reinforce a simple truth: you have options. The engineering ecosystem does not need to be defined by vendor allegiance or platform zealotry.

Our responsibility is to deliver value, reduce risk, and avoid unnecessary costs.

• Azure DevOps is not dead.
• GitHub is not the only future.
• A hybrid, agentic, vendor‑agnostic engineering platform might very well give us the best of both worlds.

Enjoy your favourite brew. I will savour my hot chocolate and raise it to disciplined engineering, sound judgement, and value‑driven progress.