Azure DevOps in 2026: The Quiet Backbone of Enterprise AI

1
00:00:00,000 --> 00:00:04,140
The industry narrative is clear. GitHub has one Microsoft invested billions into it.

2
00:00:04,140 --> 00:00:09,120
Co-pilot is everywhere. GitHub enterprises the future, but in reality, that story is incomplete.

3
00:00:09,120 --> 00:00:14,460
Walk into any Fortune 500 company in 2026. Ask the CIO about their DevOps platform.

4
00:00:14,460 --> 00:00:17,960
You won't hear that they are all in on GitHub. You'll hear something different.

5
00:00:17,960 --> 00:00:22,020
They use GitHub for their AI teams, but as your DevOps is where the governance lives,

6
00:00:22,020 --> 00:00:24,820
this isn't about features. It's not about who has the prettier interface.

7
00:00:24,820 --> 00:00:28,220
It's about a structural reality that nobody talks about. Compliance gravity.

8
00:00:28,220 --> 00:00:33,520
And it's reshaping how enterprises think about AI delivery in ways that most analysts completely miss.

9
00:00:33,520 --> 00:00:36,660
Why everyone thinks a do is dying? The story is consistent.

10
00:00:36,660 --> 00:00:40,520
Every tech publication tells it the same way. Every analyst report reinforces it.

11
00:00:40,520 --> 00:00:44,360
Every migration playbook assumes it. GitHub dominates the developer mindset.

12
00:00:44,360 --> 00:00:47,780
Over 100 million developers use it. It's the default for new projects.

13
00:00:47,780 --> 00:00:50,480
The future of DevOps. The narrative says it's inevitable.

14
00:00:50,480 --> 00:00:53,040
Meanwhile, Azure DevOps gets labeled as legacy.

15
00:00:53,040 --> 00:00:56,720
Mature, stable. The thing you use because you already have it, not because you chose it.

16
00:00:56,720 --> 00:00:59,220
The platform people are desperately trying to escape.

17
00:00:59,220 --> 00:01:01,700
And Microsoft itself seems to have made the choice.

18
00:01:01,700 --> 00:01:05,920
GitHub gets the AI investment. Co-pilot lives there. Repository intelligence.

19
00:01:05,920 --> 00:01:10,220
Agente workflows. These are the frontier features that get announced at conferences.

20
00:01:10,220 --> 00:01:14,560
Azure DevOps gets incremental updates to governance features nobody's excited about.

21
00:01:14,560 --> 00:01:19,140
Enterprise migration playbooks are literally titled from Azure DevOps to GitHub.

22
00:01:19,140 --> 00:01:22,120
Not the other way around. The direction of travel seems obvious.

23
00:01:22,120 --> 00:01:25,680
The numbers appear to support this. GitHub Enterprise adoption is rising.

24
00:01:25,680 --> 00:01:32,640
Azure DevOps MindShare dropped from 16.7% to 9.5% between 2025 and mid-2026.

25
00:01:32,640 --> 00:01:34,280
That's a collapse on paper.

26
00:01:34,280 --> 00:01:38,880
The conversation in tech communities is dominated by when you should move off ADO, not if you should.

27
00:01:38,880 --> 00:01:42,280
So the narrative becomes self-reinforcing. Everyone believes ADO is legacy.

28
00:01:42,280 --> 00:01:45,180
That belief makes choosing ADO feel like choosing the past.

29
00:01:45,180 --> 00:01:46,880
Why invest in something dying?

30
00:01:46,880 --> 00:01:48,800
But here's where the narrative breaks completely.

31
00:01:48,800 --> 00:01:53,680
Walk into a regulated industry. A bank, a farmer company, a defense contractor, a healthcare system,

32
00:01:53,680 --> 00:01:58,580
ask them about their DevOps platform choice. The answer is almost never that they are moving everything to GitHub.

33
00:01:58,580 --> 00:02:02,180
Instead, you hear that they are using both GitHub for innovation teams.

34
00:02:02,180 --> 00:02:05,880
Azure DevOps for core systems, or you hear that they can't move to GitHub yet

35
00:02:05,880 --> 00:02:09,180
because their compliance requirements aren't met, or you hear that they try to migrate

36
00:02:09,180 --> 00:02:11,080
and it costs more than they expected.

37
00:02:11,080 --> 00:02:14,280
So they are keeping ADO for the parts where it actually delivers value.

38
00:02:14,280 --> 00:02:19,080
This is the narrative gap. The public conversation assumes a binary choice between two platforms.

39
00:02:19,080 --> 00:02:21,280
The enterprise reality is a portfolio decision.

40
00:02:21,280 --> 00:02:24,280
Different tools for different purposes. The research shows this clearly.

41
00:02:24,280 --> 00:02:29,880
Organizations that attempted a full migration from ADO to GitHub without careful workload analysis

42
00:02:29,880 --> 00:02:34,080
saw a 28% increase in developer tooling spend in year one.

43
00:02:34,080 --> 00:02:38,680
Organizations that use the selective hybrid approach realize 12 to 18% savings

44
00:02:38,680 --> 00:02:41,880
compared to maintaining the full legacy ADO estate.

45
00:02:41,880 --> 00:02:43,880
That's not a story about legacy tools dying.

46
00:02:43,880 --> 00:02:50,480
That's the story about structural value. Nobody's talking about the mindset decline from 16.7% to 9.5% looks like a collapse.

47
00:02:50,480 --> 00:02:52,880
But it's actually a relative decline, not an absolute one.

48
00:02:52,880 --> 00:02:55,380
ADO still serves a massive installed base.

49
00:02:55,380 --> 00:02:59,080
The decline reflects GitHub's explosive growth, not ADO's irrelevance.

50
00:02:59,080 --> 00:03:05,280
When analysts call ADO mature, they mean it's stable, well integrated, and governance heavy.

51
00:03:05,280 --> 00:03:09,280
For a Fortune 500 company managing mission critical systems, that's not a weakness.

52
00:03:09,280 --> 00:03:12,280
It's the entire point GitHub's innovation advantage is real.

53
00:03:12,280 --> 00:03:15,380
It's winning in AI, developer experience, and ecosystem breads,

54
00:03:15,380 --> 00:03:18,780
but it's not winning in compliance, test management, or portfolio governance.

55
00:03:18,780 --> 00:03:21,980
Those are exactly the areas where regulated enterprises need the most help.

56
00:03:21,980 --> 00:03:23,580
The migration narrative is self-serving.

57
00:03:23,580 --> 00:03:27,780
Migration playbooks and consulting firms have an obvious incentive to recommend migration.

58
00:03:27,780 --> 00:03:30,980
But the actual ROI data tells a completely different story.

59
00:03:30,980 --> 00:03:34,880
The narrative gap exists because the public conversation is dominated by Greenfield,

60
00:03:34,880 --> 00:03:36,880
cloud native start-up adjacent thinking.

61
00:03:36,880 --> 00:03:40,780
But the enterprise, the place where the actual money and real risk lives,

62
00:03:40,780 --> 00:03:42,980
operates under completely different constraints.

63
00:03:42,980 --> 00:03:46,880
And in 2026, those constraints are getting tighter, not looser.

64
00:03:46,880 --> 00:03:48,580
The compliance gravity model.

65
00:03:48,580 --> 00:03:51,280
There is a concept in physics called gravity wells.

66
00:03:51,280 --> 00:03:54,380
Massive objects create fields that pull everything toward them.

67
00:03:54,380 --> 00:03:57,280
The more mass you have, the stronger that pull becomes.

68
00:03:57,280 --> 00:04:01,280
Once you are inside the well, getting out takes an incredible amount of energy.

69
00:04:01,280 --> 00:04:04,980
In the world of enterprise software, compliance works exactly the same way.

70
00:04:04,980 --> 00:04:09,980
When an organization builds its governance, its audit trails, and its release processes around one platform.

71
00:04:09,980 --> 00:04:11,680
Leaving isn't just a technical move.

72
00:04:11,680 --> 00:04:15,080
It is a structural reorganization of how the company actually functions.

73
00:04:15,080 --> 00:04:18,380
The deeper your compliance routes go, the harder it is to pull them out.

74
00:04:18,380 --> 00:04:20,780
Azure DevOps was built for this gravity well.

75
00:04:20,780 --> 00:04:22,980
It isn't necessarily because the tech is better.

76
00:04:22,980 --> 00:04:25,980
It is because the tool was designed for that specific reality.

77
00:04:25,980 --> 00:04:29,280
In practice, Azure DevOps is a fully integrated suite.

78
00:04:29,280 --> 00:04:33,080
Your repos, pipelines, boards and test plans, or live in one house.

79
00:04:33,080 --> 00:04:36,380
They are connected, a work item in a board links to a commit in a repo,

80
00:04:36,380 --> 00:04:40,280
which triggers a pipeline, which runs a test, which then creates the evidence for an audit.

81
00:04:40,280 --> 00:04:43,580
You can trace any change in production backward through the entire chain.

82
00:04:43,580 --> 00:04:46,780
Work item, to code, to test, to deployment, to the approval record.

83
00:04:46,780 --> 00:04:48,780
That integration is the gravity well.

84
00:04:48,780 --> 00:04:53,480
If you are a bank needing to prove socks compliance, or a healthcare provider protecting HIPAA data,

85
00:04:53,480 --> 00:04:56,180
that traceability isn't a "nice to have" feature.

86
00:04:56,180 --> 00:04:58,480
It is the reason you use the tool in the first place.

87
00:04:58,480 --> 00:05:01,680
You have spent five years building your audit processes around it.

88
00:05:01,680 --> 00:05:03,880
Your legal team knows how to find evidence there.

89
00:05:03,880 --> 00:05:06,880
Your lawyers know how to reconstruct the chain if something goes wrong.

90
00:05:06,880 --> 00:05:08,180
GitHub was built differently.

91
00:05:08,180 --> 00:05:10,080
It is a repository first platform.

92
00:05:10,080 --> 00:05:12,280
It is amazing at source control and collaboration.

93
00:05:12,280 --> 00:05:16,380
But things like work management and former release gates are not native to the core of GitHub.

94
00:05:16,380 --> 00:05:17,380
They are add-ons.

95
00:05:17,380 --> 00:05:19,480
They are integrations you have to layer on top.

96
00:05:19,480 --> 00:05:21,280
For a small startup, that is perfectly fine.

97
00:05:21,280 --> 00:05:25,180
You use GitHub for code, GERA for your boards, and service now for your changes.

98
00:05:25,180 --> 00:05:27,280
You are building from scratch so you can pick and choose.

99
00:05:27,280 --> 00:05:29,080
But imagine a Fortune 500 bank.

100
00:05:29,080 --> 00:05:33,680
They have spent years perfecting their audit workflows inside Azure DevOps boards and test plans.

101
00:05:33,680 --> 00:05:37,580
Moving to GitHub means rebuilding every single one of those connections.

102
00:05:37,580 --> 00:05:39,280
The problem isn't that GitHub is worse.

103
00:05:39,280 --> 00:05:41,480
The problem is that the governance model doesn't map.

104
00:05:41,480 --> 00:05:43,380
Your auditors expect data from boards.

105
00:05:43,380 --> 00:05:46,080
Your compliance workflows look for evidence from test plans.

106
00:05:46,080 --> 00:05:49,080
Your release process is waiting for approvals from Ado pipelines.

107
00:05:49,080 --> 00:05:53,380
Replacing those pieces requires you to rebuild the entire compliance chain from the ground up.

108
00:05:53,380 --> 00:05:54,380
That work is expensive.

109
00:05:54,380 --> 00:05:55,080
It is risky.

110
00:05:55,080 --> 00:05:58,080
It breaks processes that auditors have already signed off on.

111
00:05:58,080 --> 00:06:01,680
It creates gaps where your evidence used to be a solid, continuous line.

112
00:06:01,680 --> 00:06:03,780
This is why big organizations stay put.

113
00:06:03,780 --> 00:06:05,680
Even when GitHub looks better on paper.

114
00:06:05,680 --> 00:06:07,680
This is the compliance gravity model.

115
00:06:07,680 --> 00:06:10,980
It explains the reality that the marketing narrative usually ignores.

116
00:06:10,980 --> 00:06:15,980
Regulated companies stay on ADO longer than startups because the cost of leaving is structural.

117
00:06:15,980 --> 00:06:18,080
It isn't about which button is easier to click.

118
00:06:18,080 --> 00:06:22,680
It is about the fact that your compliance infrastructure is tangled up with the platform itself.

119
00:06:22,680 --> 00:06:24,980
This is why hybrid models are becoming the standard.

120
00:06:24,980 --> 00:06:27,580
Organizations cannot afford to move everything at once.

121
00:06:27,580 --> 00:06:31,880
They move what makes sense like repositories and they keep what is embedded in their governance.

122
00:06:31,880 --> 00:06:35,580
What people call a migration is usually just the birth of a hybrid stack.

123
00:06:35,580 --> 00:06:37,180
Companies aren't leaving Ado.

124
00:06:37,180 --> 00:06:39,280
They are just putting GitHub on top of it.

125
00:06:39,280 --> 00:06:42,680
That is why you see a 28% spike in costs during the first year.

126
00:06:42,680 --> 00:06:46,780
You are paying for two platforms while you try to manage the messy integrations between them.

127
00:06:46,780 --> 00:06:49,280
Azure DevOps isn't dying. It is specializing.

128
00:06:49,280 --> 00:06:54,480
It is becoming the control plane for the enterprise while GitHub becomes the place where developers actually innovate.

129
00:06:54,480 --> 00:06:57,580
That isn't a legacy problem. That is architectural clarity.

130
00:06:57,580 --> 00:06:59,880
Why AI changes everything.

131
00:06:59,880 --> 00:07:05,280
Back in 2025, the debate between Azure DevOps and GitHub was mostly about features.

132
00:07:05,280 --> 00:07:07,180
People talked about CICD speed.

133
00:07:07,180 --> 00:07:08,980
They compared the repository experience.

134
00:07:08,980 --> 00:07:12,380
They looked at how well boards tracked work across different teams.

135
00:07:12,380 --> 00:07:16,180
The goal was always to find the platform that gave developers the smoothest experience.

136
00:07:16,180 --> 00:07:19,480
In 2026, that conversation is being completely rewritten.

137
00:07:19,480 --> 00:07:22,780
It isn't happening because of a new UI or a better feature set.

138
00:07:22,780 --> 00:07:24,580
It is happening because of AI governance.

139
00:07:24,580 --> 00:07:27,080
The EU AI Act is now being enforced.

140
00:07:27,080 --> 00:07:30,580
And it has introduced a requirement that changes the game for enterprise compliance.

141
00:07:30,580 --> 00:07:34,680
If you are deploying high-risk AI, you have to maintain continuous, structured evidence.

142
00:07:34,680 --> 00:07:37,180
This isn't an annual review where you hope nothing broke.

143
00:07:37,180 --> 00:07:40,480
This isn't a point in time audit where you check the boxes at the end of the year.

144
00:07:40,480 --> 00:07:45,680
This is proof that your AI was built, tested and monitored under strict controls every single day it was running.

145
00:07:45,680 --> 00:07:47,880
That is a massive shift in how governance works.

146
00:07:47,880 --> 00:07:50,580
Traditional software governance was about managing change.

147
00:07:50,580 --> 00:07:51,580
Who approved the release?

148
00:07:51,580 --> 00:07:52,480
What was in the log?

149
00:07:52,480 --> 00:07:54,280
You could answer those questions after the fact.

150
00:07:54,280 --> 00:07:58,180
You could gather your evidence during an audit and tell a story about what happened.

151
00:07:58,180 --> 00:08:00,380
AI governance is about the entire pipeline.

152
00:08:00,380 --> 00:08:02,380
You have to know what data trained the model.

153
00:08:02,380 --> 00:08:03,880
You have to show how it was processed.

154
00:08:03,880 --> 00:08:07,180
You need to prove which safety checks ran before training started.

155
00:08:07,180 --> 00:08:11,080
You have to track how the system behaves in production and what happens when it starts to drift.

156
00:08:11,080 --> 00:08:12,980
Is it respecting access controls?

157
00:08:12,980 --> 00:08:13,880
Is it leaking data?

158
00:08:13,880 --> 00:08:14,380
It shouldn't.

159
00:08:14,380 --> 00:08:16,580
Here is the part most companies are still missing.

160
00:08:16,580 --> 00:08:18,880
You cannot answer these questions after the fact.

161
00:08:18,880 --> 00:08:20,780
You have to prove it while it is happening.

162
00:08:20,780 --> 00:08:23,680
You have to show the test results and the deployment approvals in real time.

163
00:08:23,680 --> 00:08:25,180
It can't be a report you write later.

164
00:08:25,180 --> 00:08:26,980
It has to be an auditable chain of evidence.

165
00:08:26,980 --> 00:08:28,480
This is an orchestration problem.

166
00:08:28,480 --> 00:08:29,580
It is a logging problem.

167
00:08:29,580 --> 00:08:32,080
And it is exactly what Azure DevOps was built to handle.

168
00:08:32,080 --> 00:08:35,280
Azure DevOps pipelines don't just move code from point A to point B.

169
00:08:35,280 --> 00:08:36,680
They manage entire workflows.

170
00:08:36,680 --> 00:08:40,580
They log every single step, every approval and every failure along the way.

171
00:08:40,580 --> 00:08:45,280
Think about a real world scenario and organization builds a rag system for customer support.

172
00:08:45,280 --> 00:08:49,280
It pulls documents, ranks them and uses them to give an LLM the right context.

173
00:08:49,280 --> 00:08:52,580
It sounds simple until you actually try to build it for an enterprise.

174
00:08:52,580 --> 00:08:54,880
The pipeline has to pull data from source systems.

175
00:08:54,880 --> 00:08:57,680
It has to validate that data against your compliance rules.

176
00:08:57,680 --> 00:09:01,980
It has to generate embeddings, update the vector store and run retrieval tests.

177
00:09:01,980 --> 00:09:05,780
Then it has to run generation tests to make sure the AI isn't hallucinating.

178
00:09:05,780 --> 00:09:06,980
You need safety metrics.

179
00:09:06,980 --> 00:09:09,480
You need human approvals before it goes to production.

180
00:09:09,480 --> 00:09:11,780
You need to monitor it for drift once it is live.

181
00:09:11,780 --> 00:09:14,680
And if the quality drops, you need to trigger a re-evaluation.

182
00:09:14,680 --> 00:09:16,080
That isn't a simple script.

183
00:09:16,080 --> 00:09:18,780
That is a complex orchestration with seven different gates.

184
00:09:18,780 --> 00:09:22,980
Every one of those gates produces evidence that an auditor will eventually want to see.

185
00:09:22,980 --> 00:09:28,180
In 2026, you cannot deploy that system without proof that every step followed the rules.

186
00:09:28,180 --> 00:09:28,980
You need the logs.

187
00:09:28,980 --> 00:09:30,180
You need the approval records.

188
00:09:30,180 --> 00:09:34,480
You need the ability to trace a decision in production all the way back to the data that started it.

189
00:09:34,480 --> 00:09:36,380
Azure DevOps does this natively.

190
00:09:36,380 --> 00:09:39,080
The pipeline pulls the data, runs the checks, updates the store,

191
00:09:39,080 --> 00:09:41,680
and only moves to production if every single gate stays green.

192
00:09:41,680 --> 00:09:43,080
Every move is recorded.

193
00:09:43,080 --> 00:09:44,280
Every failure is traceable.

194
00:09:44,280 --> 00:09:45,980
GitHub is great at CICD.

195
00:09:45,980 --> 00:09:50,480
But building an end-to-end AI pipeline with formal gates and audit trails isn't what it was made for.

196
00:09:50,480 --> 00:09:53,280
You would have to build that logic yourself on top of GitHub action.

197
00:09:53,280 --> 00:09:56,380
You would have to stitch together different tools and manage the mess.

198
00:09:56,380 --> 00:09:57,680
Adior just does it.

199
00:09:57,680 --> 00:09:58,680
This is the turning point.

200
00:09:58,680 --> 00:10:01,480
In 2025, GitHub was winning because developers loved it.

201
00:10:01,480 --> 00:10:05,980
In 2026, Azure DevOps is becoming essential because the compliance team requires it.

202
00:10:05,980 --> 00:10:09,080
And in the enterprise, compliance is no longer a side project.

203
00:10:09,080 --> 00:10:10,780
It is the main constraint.

204
00:10:10,780 --> 00:10:12,480
The LLMOps control plane.

205
00:10:12,480 --> 00:10:17,580
In 2026, something is happening inside Azure DevOps that the analyst reports haven't caught up with yet.

206
00:10:17,580 --> 00:10:21,380
Organizations aren't just using Adior for traditional software delivery anymore.

207
00:10:21,380 --> 00:10:23,180
They're repurposing it for something new.

208
00:10:23,180 --> 00:10:24,680
The LLMOps control plane.

209
00:10:24,680 --> 00:10:26,780
This isn't the LLM development platform.

210
00:10:26,780 --> 00:10:28,880
And it's not the infrastructure where models are trained.

211
00:10:28,880 --> 00:10:32,280
It's the orchestration layer that sits between experimentation and production.

212
00:10:32,280 --> 00:10:35,580
The system that says, you've built something promising in a notebook.

213
00:10:35,580 --> 00:10:37,080
Now we move it to production.

214
00:10:37,080 --> 00:10:40,680
And here's how we ensure it stays safe, auditable and compliant.

215
00:10:40,680 --> 00:10:43,780
Think about what an LLMOps control plane actually has to do.

216
00:10:43,780 --> 00:10:46,880
It manages versioning of prompts and retrieval configurations.

217
00:10:46,880 --> 00:10:50,780
While orchestrating evaluation pipelines that test for safety, quality and regression

218
00:10:50,780 --> 00:10:53,580
before anything reaches production, it enforces approval gates

219
00:10:53,580 --> 00:10:56,780
so a human has to sign off before a new model version goes live.

220
00:10:56,780 --> 00:10:59,380
And it maintains audit trails of every single change.

221
00:10:59,380 --> 00:11:02,680
It monitors for drift once the system is live and triggers re-evaluation

222
00:11:02,680 --> 00:11:06,180
if behavior shifts, integrating security, scanning and compliance checks

223
00:11:06,180 --> 00:11:07,980
as automatic gates in the pipeline.

224
00:11:07,980 --> 00:11:09,180
That's not a small job.

225
00:11:09,180 --> 00:11:10,280
And here's what matters.

226
00:11:10,280 --> 00:11:13,980
Azure DevOps pipelines were architected to do exactly that.

227
00:11:13,980 --> 00:11:17,180
Organizations in 2026 are implementing this in concrete ways.

228
00:11:17,180 --> 00:11:20,980
They're storing prompt templates and rag configurations in Azure Repos

229
00:11:20,980 --> 00:11:23,880
and they're running automated evaluation tests in pipelines

230
00:11:23,880 --> 00:11:26,080
before any promotion to higher environments.

231
00:11:26,080 --> 00:11:29,680
They're using environment approvals to enforce that a human from the compliance team

232
00:11:29,680 --> 00:11:32,180
has to review and approve every production change.

233
00:11:32,180 --> 00:11:35,680
They're integrating safety checks, toxicity filters, bias detection,

234
00:11:35,680 --> 00:11:40,480
hallucination tests as automatic gates that either pass or block the pipeline.

235
00:11:40,480 --> 00:11:43,980
They're maintaining full traceability from the original requirement

236
00:11:43,980 --> 00:11:47,180
through code, through test results, through deployment to monitoring.

237
00:11:47,180 --> 00:11:49,580
This is not a new feature announcement from Microsoft.

238
00:11:49,580 --> 00:11:50,880
It's a new use case.

239
00:11:50,880 --> 00:11:54,380
Organizations are taking the existing ADO pipeline infrastructure

240
00:11:54,380 --> 00:11:58,080
that was built for traditional software and extending it to govern AI systems.

241
00:11:58,080 --> 00:12:01,380
And it works because the underlying architecture was already designed for this

242
00:12:01,380 --> 00:12:05,780
gated releases, approval workflows, artifact versioning, integrated logging.

243
00:12:05,780 --> 00:12:07,680
That's the DNA of Azure DevOps.

244
00:12:07,680 --> 00:12:10,980
It's purpose-built for situations where you need to prove that something happened

245
00:12:10,980 --> 00:12:12,380
under controlled conditions.

246
00:12:12,380 --> 00:12:15,180
GitHub can do similar things, but it requires more work.

247
00:12:15,180 --> 00:12:17,280
You'd have to build more custom integration

248
00:12:17,280 --> 00:12:19,680
and you'd have to string together more separate tools.

249
00:12:19,680 --> 00:12:21,880
You'd have to manage more of the orchestration yourself.

250
00:12:21,880 --> 00:12:25,180
It's possible, but it's more operational complexity for an organization

251
00:12:25,180 --> 00:12:28,080
that already has compliance infrastructure built around Azure DevOps

252
00:12:28,080 --> 00:12:30,780
that has spent years building audit processes around ADO.

253
00:12:30,780 --> 00:12:32,880
The path of least resistance is obvious.

254
00:12:32,880 --> 00:12:35,280
Extend that same infrastructure to LLM ops.

255
00:12:35,280 --> 00:12:38,480
Use the tools you already have in the way they were designed to be used.

256
00:12:38,480 --> 00:12:41,080
This is why something unexpected is happening in 2026.

257
00:12:41,080 --> 00:12:44,280
Organizations that were planning a full migration to GitHub are hitting pause.

258
00:12:44,280 --> 00:12:48,080
Not because GitHub is bad and not because they've decided GitHub can't work,

259
00:12:48,080 --> 00:12:51,280
but because they're starting to realize they need a governance layer for AI

260
00:12:51,280 --> 00:12:53,480
and Azure DevOps already provides it.

261
00:12:53,480 --> 00:12:55,680
And rebuilding that governance on a different platform

262
00:12:55,680 --> 00:12:58,480
adds cost and complexity they didn't anticipate.

263
00:12:58,480 --> 00:13:01,380
The organization's deploying LLM ops today are using Azure DevOps

264
00:13:01,380 --> 00:13:02,780
as the orchestration backbone.

265
00:13:02,780 --> 00:13:06,080
They're using GitHub for repositories and AI assisted coding,

266
00:13:06,080 --> 00:13:10,080
but the control plane, the system that ensures the LLM application stays safe,

267
00:13:10,080 --> 00:13:13,280
remains auditable and stays compliant, is Azure DevOps.

268
00:13:13,280 --> 00:13:17,080
This represents a fundamental shift in how enterprises think about these platforms.

269
00:13:17,080 --> 00:13:18,480
It's not about features anymore.

270
00:13:18,480 --> 00:13:21,680
It's not about which interface is nicer or which ecosystem is bigger.

271
00:13:21,680 --> 00:13:26,080
It's about which platform was designed for the specific problem you're trying to solve.

272
00:13:26,080 --> 00:13:28,680
LLM ops requires something different from traditional DevOps.

273
00:13:28,680 --> 00:13:31,280
It's not just about orchestrating code and infrastructure.

274
00:13:31,280 --> 00:13:34,880
It's about orchestrating data, models, evaluations and safety checks.

275
00:13:34,880 --> 00:13:37,280
Azure DevOps pipelines map directly to those needs.

276
00:13:37,280 --> 00:13:39,280
GitHub actions can handle CI/CD,

277
00:13:39,280 --> 00:13:42,680
but orchestrating a complete LLM ops pipeline with formal gates,

278
00:13:42,680 --> 00:13:44,080
that's more complex on GitHub.

279
00:13:44,080 --> 00:13:46,480
This is the role that's emerging in 2026.

280
00:13:46,480 --> 00:13:50,880
Azure DevOps is becoming the system that ensures AI applications are deployed safely and

281
00:13:50,880 --> 00:13:53,080
compliantly, not the flashy innovation platform,

282
00:13:53,080 --> 00:13:56,480
the quiet backbone that keeps the AI system governance intact.

283
00:13:56,480 --> 00:13:58,080
Why hybrid is winning?

284
00:13:58,080 --> 00:14:02,080
By 2026, the market has settled this question in a way that surprised most analysts.

285
00:14:02,080 --> 00:14:06,080
The answer isn't "pick one", it's "use both" intentionally.

286
00:14:06,080 --> 00:14:09,280
Not because one platform is universally better than the other,

287
00:14:09,280 --> 00:14:11,480
but because they were designed for different purposes.

288
00:14:11,480 --> 00:14:15,680
GitHub is the developer-facing innovation-focused layer where your best thinking happens.

289
00:14:15,680 --> 00:14:19,280
It's where AI assisted coding actually changes how fast you move.

290
00:14:19,280 --> 00:14:22,280
It's where co-pilot workspace and repository intelligence live,

291
00:14:22,280 --> 00:14:25,880
where the developer experience is optimized around how people actually work.

292
00:14:25,880 --> 00:14:29,280
Azure DevOps is the enterprise-facing governance-focused layer.

293
00:14:29,280 --> 00:14:32,280
It's where compliance gets enforced, where audit trails get maintained,

294
00:14:32,280 --> 00:14:35,880
where release gates ensure that safety checks run before anything reaches production,

295
00:14:35,880 --> 00:14:39,680
where work items stay connected to code changes to test results, to deployments.

296
00:14:39,680 --> 00:14:41,080
You don't have to choose between them,

297
00:14:41,080 --> 00:14:43,480
and increasingly organizations realize they shouldn't.

298
00:14:43,480 --> 00:14:47,080
The pragmatic approach that's winning in 2026 looks like this.

299
00:14:47,080 --> 00:14:50,680
GitHub for repositories, pull requests, and CI/CD,

300
00:14:50,680 --> 00:14:52,880
Azure DevOps for boards, test plans,

301
00:14:52,880 --> 00:14:56,280
and the formal release orchestration that keeps high-risk systems safe.

302
00:14:56,280 --> 00:14:58,880
And integration automation to keep them talking to each other.

303
00:14:58,880 --> 00:15:02,080
This works because each platform is doing what it was designed to do.

304
00:15:02,080 --> 00:15:05,480
GitHub gives you the full AI-assisted development experience,

305
00:15:05,480 --> 00:15:08,480
a thriving ecosystem of community tools and templates,

306
00:15:08,480 --> 00:15:10,880
and an interface that makes developers productive.

307
00:15:10,880 --> 00:15:14,280
Azure DevOps gives you integrated governance compliance infrastructure

308
00:15:14,280 --> 00:15:17,280
that actually works, and the ability to trace any production change

309
00:15:17,280 --> 00:15:19,280
backward through its entire life cycle.

310
00:15:19,280 --> 00:15:20,680
You're not forcing a compromise.

311
00:15:20,680 --> 00:15:23,280
You're using the right tool for each layer of the problem.

312
00:15:23,280 --> 00:15:26,080
The integration story has actually improved significantly.

313
00:15:26,080 --> 00:15:30,880
In 2026, you can link GitHub commits and pull requests directly to Azure Boards' work items.

314
00:15:30,880 --> 00:15:33,880
You can trigger Azure pipelines when events happen in GitHub.

315
00:15:33,880 --> 00:15:36,280
You can mirror Azure Repos into GitHub,

316
00:15:36,280 --> 00:15:41,080
or use GitHub as your primary repository while maintaining secondary visibility in ADO.

317
00:15:41,080 --> 00:15:45,680
You can synchronize identity and access management across both platforms from a single source.

318
00:15:45,680 --> 00:15:47,480
These integrations aren't perfect.

319
00:15:47,480 --> 00:15:49,880
They're not seamless like using a single platform would be.

320
00:15:49,880 --> 00:15:50,880
But they're functional.

321
00:15:50,880 --> 00:15:52,480
They're supported and they're getting better.

322
00:15:52,480 --> 00:15:54,480
This means hybrid isn't a workaround anymore.

323
00:15:54,480 --> 00:15:57,880
It's becoming an architectural pattern that Microsoft actively supports.

324
00:15:57,880 --> 00:16:00,880
Here's how this looks in practice across real organizations.

325
00:16:00,880 --> 00:16:04,680
A financial services company moves new cloud-native repositories to GitHub.

326
00:16:04,680 --> 00:16:07,680
The team working on the core banking system stays on Azure DevOps.

327
00:16:07,680 --> 00:16:11,080
Why? Because that system has five years of audit process built around ADO.

328
00:16:11,080 --> 00:16:13,880
The cost to replace that is higher than the cost to maintain it.

329
00:16:13,880 --> 00:16:17,280
New systems don't have that baggage, so GitHub makes sense.

330
00:16:17,280 --> 00:16:21,280
A pharmaceutical company uses GitHub for their research and development AI models.

331
00:16:21,280 --> 00:16:24,480
But the systems that actually move compounds through clinical trials,

332
00:16:24,480 --> 00:16:29,080
those stay on Azure DevOps because the regulatory trail matters more than developer velocity.

333
00:16:29,080 --> 00:16:31,480
The traceability requirements are non-negotiable.

334
00:16:31,480 --> 00:16:35,480
A healthcare organization uses Azure boards as the portfolio-level tracking system

335
00:16:35,480 --> 00:16:37,080
across the entire organization.

336
00:16:37,080 --> 00:16:40,880
Individual GitHub repositories handle tactical task management and code review.

337
00:16:40,880 --> 00:16:45,480
It's not perfect symmetry, but it works because each system is doing what it's actually good at.

338
00:16:45,480 --> 00:16:48,680
This isn't a compromised born of indecision, it's pragmatism.

339
00:16:48,680 --> 00:16:52,680
Organizations are solving the problem they have, not the problem they think they should have.

340
00:16:52,680 --> 00:16:54,480
And the evidence suggests it's working.

341
00:16:54,480 --> 00:16:58,480
Organizations running this hybrid model report lower total cost of ownership

342
00:16:58,480 --> 00:17:01,280
than organizations that tried forced full migration.

343
00:17:01,280 --> 00:17:05,280
They report higher developer satisfaction than organizations staying on ADO alone.

344
00:17:05,280 --> 00:17:09,280
They report better compliance posture than organizations that moved everything to GitHub alone.

345
00:17:09,280 --> 00:17:13,680
They have clearer governance boundaries than organizations trying to use one platform for everything.

346
00:17:13,680 --> 00:17:17,280
Hybrid is winning because it's honest about what each platform does well

347
00:17:17,280 --> 00:17:20,280
and stops forcing platforms to be something they're not.

348
00:17:20,280 --> 00:17:22,080
The portfolio decision framework.

349
00:17:22,080 --> 00:17:24,480
At this point, you've probably realized something.

350
00:17:24,480 --> 00:17:27,680
Choosing between Azure DevOps and GitHub isn't a binary choice.

351
00:17:27,680 --> 00:17:29,080
It's a portfolio problem.

352
00:17:29,080 --> 00:17:33,280
And portfolio problems need frameworks. The question isn't which platform should we use.

353
00:17:33,280 --> 00:17:38,880
The real question is which platform should we use for which workloads and how do we make that decision consistently?

354
00:17:38,880 --> 00:17:41,480
CIOs in 2026 are approaching the systematically.

355
00:17:41,480 --> 00:17:46,080
They aren't debating philosophically. They're classifying workloads and making allocation decisions

356
00:17:46,080 --> 00:17:48,080
based on specific characteristics.

357
00:17:48,080 --> 00:17:50,080
Start with workload classification.

358
00:17:50,080 --> 00:17:53,080
What actually matters when you're deciding where a system lives?

359
00:17:53,080 --> 00:17:55,680
Strategic importance.

360
00:17:55,680 --> 00:17:59,880
Does this workload drive competitive advantage or is it just supporting infrastructure?

361
00:17:59,880 --> 00:18:05,480
An AI model that predicts customer churn is strategically different from an internal timekeeping system.

362
00:18:05,480 --> 00:18:06,680
One shapes how you compete.

363
00:18:06,680 --> 00:18:09,280
The other just keeps the lights on. Regulatory exposure.

364
00:18:09,280 --> 00:18:12,680
Does the workload touch regulated data or is it internal tooling?

365
00:18:12,680 --> 00:18:18,680
A system handling healthcare data lives under different constraints than a project management tool for your engineering team.

366
00:18:18,680 --> 00:18:19,880
Development velocity.

367
00:18:19,880 --> 00:18:23,280
Does the team need to move fast or does stability matter more?

368
00:18:23,280 --> 00:18:28,280
A research and development initiative has different timeline requirements than a system running transactions.

369
00:18:28,280 --> 00:18:30,280
Team maturity.

370
00:18:30,280 --> 00:18:33,280
Are these experienced engineers who can operate with minimal structure?

371
00:18:33,280 --> 00:18:35,680
Or do they benefit from more framework and guardrails?

372
00:18:35,680 --> 00:18:38,680
That matters for which platform works best? Integration complexity.

373
00:18:38,680 --> 00:18:42,880
Does this system need to plug into legacy infrastructure or is it greenfield?

374
00:18:42,880 --> 00:18:46,880
A system that has to synchronize with the mainframe system has different requirements

375
00:18:46,880 --> 00:18:50,280
than something you're building from scratch on cloud-native infrastructure.

376
00:18:50,280 --> 00:18:54,880
Once you've classified workloads along those dimensions, platform mapping becomes clearer.

377
00:18:54,880 --> 00:18:59,880
GitHub makes the most sense when you have greenfield work, experience teams, minimal regulatory exposure

378
00:18:59,880 --> 00:19:01,880
and velocity is the primary constraint.

379
00:19:01,880 --> 00:19:07,880
Cloud-native applications, open source projects, AI assisted development initiatives, where you want to move fast.

380
00:19:07,880 --> 00:19:11,680
These workloads benefit from GitHub's developer experience, its ecosystem,

381
00:19:11,680 --> 00:19:14,680
and the AI capabilities built directly into the platform.

382
00:19:14,680 --> 00:19:19,480
Azure DevOps makes the most sense when the workload is regulated, legacy integration is required,

383
00:19:19,480 --> 00:19:24,880
formal governance is non-negotiable, or the team benefits from more structured processes.

384
00:19:24,880 --> 00:19:28,880
Financial systems, healthcare applications, complex enterprise programs

385
00:19:28,880 --> 00:19:32,880
where change management and audit trails are foundational to how the work happens.

386
00:19:32,880 --> 00:19:36,080
Hybrid makes sense for workloads with mixed characteristics.

387
00:19:36,080 --> 00:19:40,080
You want GitHub's speed and AI capabilities, but you need ADO's governance infrastructure.

388
00:19:40,080 --> 00:19:44,280
The system isn't fully greenfield but isn't deeply entrenched in legacy systems either.

389
00:19:44,280 --> 00:19:47,880
It's important enough to govern formally but fast enough to move quickly.

390
00:19:47,880 --> 00:19:50,280
Migration sequencing matters too.

391
00:19:50,280 --> 00:19:53,680
If you're actually moving workloads, don't start with your highest risk systems.

392
00:19:53,680 --> 00:19:58,480
Start with low-risk greenfield projects on GitHub, build confidence, learn what works and what doesn't,

393
00:19:58,480 --> 00:20:00,680
then take that learning to more complex scenarios.

394
00:20:00,680 --> 00:20:06,480
Keep high-risk regulated workloads on Azure DevOps until you've proven you can maintain the same level of compliance on GitHub.

395
00:20:06,480 --> 00:20:09,680
Use hybrid for transitional workloads where you're testing the model,

396
00:20:09,680 --> 00:20:11,680
but not betting the company on the outcome.

397
00:20:11,680 --> 00:20:13,680
Cost modeling brings this down to dollars.

398
00:20:13,680 --> 00:20:17,280
Status quo, staying on ADO only, has lower migration costs,

399
00:20:17,280 --> 00:20:18,880
but higher opportunity costs.

400
00:20:18,880 --> 00:20:21,680
You're not capturing GitHub's developer productivity benefits.

401
00:20:21,680 --> 00:20:24,880
GitHub only has higher upfront costs, your rebuilding pipelines.

402
00:20:24,880 --> 00:20:27,080
That's half a day to two days per pipeline.

403
00:20:27,080 --> 00:20:29,880
For a 200 pipeline organization, that's substantial labor.

404
00:20:29,880 --> 00:20:33,880
But long term, you might pay less operationally because you're not running two platforms.

405
00:20:33,880 --> 00:20:36,080
Hybrid has moderate costs in both categories.

406
00:20:36,080 --> 00:20:40,080
Migration costs are lower because you're only moving the workloads that make sense.

407
00:20:40,080 --> 00:20:43,080
Ongoing costs are higher because you're paying for both platforms,

408
00:20:43,080 --> 00:20:47,280
but most organizations find the total cost is lower than forced migration,

409
00:20:47,280 --> 00:20:50,280
and the outcome is better than staying on one platform alone.

410
00:20:50,280 --> 00:20:51,680
Governance design is the last piece.

411
00:20:51,680 --> 00:20:53,680
Once you've decided where workloads go,

412
00:20:53,680 --> 00:20:55,680
design governance to support the decision,

413
00:20:55,680 --> 00:20:57,480
define which teams use which platform,

414
00:20:57,480 --> 00:20:59,680
establish clear integration patterns,

415
00:20:59,680 --> 00:21:04,280
create a central platform team that maintains templates and standards across both systems,

416
00:21:04,280 --> 00:21:06,480
build dashboards that show metrics from both platforms,

417
00:21:06,480 --> 00:21:07,880
so you're not flying blind.

418
00:21:07,880 --> 00:21:12,080
Establish a governance council that reviews decisions quarterly and adjusts as the landscape changes.

419
00:21:12,080 --> 00:21:13,680
This framework is practical.

420
00:21:13,680 --> 00:21:15,880
It's not about which platform is objectively better.

421
00:21:15,880 --> 00:21:18,080
It's about which platform fits which problem.

422
00:21:18,080 --> 00:21:19,880
Why audit requirements are changing?

423
00:21:19,880 --> 00:21:23,280
The governance standards that worked for traditional software are breaking down

424
00:21:23,280 --> 00:21:25,880
in the face of AI systems, and the difference isn't subtle.

425
00:21:25,880 --> 00:21:28,280
Traditional software governance asked about change.

426
00:21:28,280 --> 00:21:29,080
Who deployed this?

427
00:21:29,080 --> 00:21:30,480
When? What approvals happened?

428
00:21:30,480 --> 00:21:31,680
What was the change log?

429
00:21:31,680 --> 00:21:34,680
Those questions made sense because software was relatively predictable.

430
00:21:34,680 --> 00:21:38,080
You wrote code, you tested it, you deployed it.

431
00:21:38,080 --> 00:21:41,680
If something went wrong, you traced it back through your change management process.

432
00:21:41,680 --> 00:21:43,280
AI systems don't work that way.

433
00:21:43,280 --> 00:21:46,680
The behavior emerges from the intersection of data, training methodology,

434
00:21:46,680 --> 00:21:49,280
configuration choices, and runtime environment.

435
00:21:49,280 --> 00:21:52,480
The same code can produce different results depending on what data it encounters.

436
00:21:52,480 --> 00:21:55,480
The same model can behave differently when run on different hardware

437
00:21:55,480 --> 00:21:57,280
or against different input distributions.

438
00:21:57,280 --> 00:21:59,880
That fundamentally changes what auditors need to see.

439
00:21:59,880 --> 00:22:01,880
Data governance is now the starting point.

440
00:22:01,880 --> 00:22:05,480
You have to know exactly what data was used to train or fine tune the model.

441
00:22:05,480 --> 00:22:08,680
Not just the data set name, the actual data, where it came from,

442
00:22:08,680 --> 00:22:11,480
how it was collected, what processing was applied,

443
00:22:11,480 --> 00:22:14,880
what safeguards were in place to ensure it doesn't contain prohibited content

444
00:22:14,880 --> 00:22:17,280
like personal information or copyrighted material.

445
00:22:17,280 --> 00:22:20,080
When you update the model, you have to document what data changed.

446
00:22:20,080 --> 00:22:23,680
When you deploy a new version, you have to verify that the data is still compliant.

447
00:22:23,680 --> 00:22:26,880
This isn't about policy documentation, it's about maintaining a complete,

448
00:22:26,880 --> 00:22:30,880
auditable record of every data transformation from source to training to deployment.

449
00:22:30,880 --> 00:22:33,280
Training and configuration governance works the same way.

450
00:22:33,280 --> 00:22:35,680
You have to document exactly how the model was built,

451
00:22:35,680 --> 00:22:38,680
what base model did you start from, what hyper parameters did you use,

452
00:22:38,680 --> 00:22:40,480
what safety measures were applied during training,

453
00:22:40,480 --> 00:22:43,080
what alignment techniques were used to shape behavior.

454
00:22:43,080 --> 00:22:46,880
If someone asks, why does the model respond to this input the way it does?

455
00:22:46,880 --> 00:22:49,480
You have to be able to trace it back to deliberate training decisions,

456
00:22:49,480 --> 00:22:50,680
not accidents or luck.

457
00:22:50,680 --> 00:22:54,480
Evaluation and testing governance is where the evidence becomes concrete.

458
00:22:54,480 --> 00:22:58,880
Before any AI system reaches production, it has to pass systematic evaluation.

459
00:22:58,880 --> 00:23:02,280
Not just one test, multiple tests, safety testing, bias testing,

460
00:23:02,280 --> 00:23:04,280
hallucination testing, compliance testing.

461
00:23:04,280 --> 00:23:07,280
You have to document not just the results, but the methodology.

462
00:23:07,280 --> 00:23:08,480
What test cases did you use?

463
00:23:08,480 --> 00:23:10,280
How did you define pass/fail criteria?

464
00:23:10,280 --> 00:23:11,880
What was the rationale for each threshold?

465
00:23:11,880 --> 00:23:14,280
And you have to maintain that evidence, not archived somewhere,

466
00:23:14,280 --> 00:23:16,280
available for inspection, auditable.

467
00:23:16,280 --> 00:23:19,080
Deployment and monitoring governance means you have to prove

468
00:23:19,080 --> 00:23:21,880
that the system was released under approved controls.

469
00:23:21,880 --> 00:23:24,680
What version of the model is actually running in production?

470
00:23:24,680 --> 00:23:26,080
What version of the configuration?

471
00:23:26,080 --> 00:23:28,080
What version of the data pipeline feeding it?

472
00:23:28,080 --> 00:23:31,280
You have to be able to reconstruct at any point in time.

473
00:23:31,280 --> 00:23:34,080
What was deployed when it was deployed, who approved it,

474
00:23:34,080 --> 00:23:35,480
and what monitoring showed?

475
00:23:35,480 --> 00:23:40,080
Incident and remediation governance is the part most organizations underestimate.

476
00:23:40,080 --> 00:23:43,680
When something goes wrong, the model produces biased results,

477
00:23:43,680 --> 00:23:47,080
returns something it shouldn't, fails to handle in edge case correctly.

478
00:23:47,080 --> 00:23:49,680
You have to document everything, the incident,

479
00:23:49,680 --> 00:23:52,280
when it was detected, how it was investigated,

480
00:23:52,280 --> 00:23:54,080
what changes were made to fix it,

481
00:23:54,080 --> 00:23:56,680
why those specific changes addressed the root cause.

482
00:23:56,680 --> 00:23:59,480
You have to maintain that incident history and make it auditable.

483
00:23:59,480 --> 00:24:02,480
This is a comprehensive end-to-end compliance model.

484
00:24:02,480 --> 00:24:05,280
And it's completely different from we have a change control process,

485
00:24:05,280 --> 00:24:08,080
it's exactly the kind of orchestrated, documented,

486
00:24:08,080 --> 00:24:11,680
auditable workflow that Azure DevOps was architected to support pipelines

487
00:24:11,680 --> 00:24:14,880
that log every step, approvals that create an approval record,

488
00:24:14,880 --> 00:24:17,080
artifacts that maintain version history,

489
00:24:17,080 --> 00:24:20,280
integration between repositories and work items and test results

490
00:24:20,280 --> 00:24:21,880
that creates the traceability chain.

491
00:24:21,880 --> 00:24:24,680
This is why audit requirements are driving enterprise adoption

492
00:24:24,680 --> 00:24:28,080
of Azure DevOps in ways that feature comparisons never could.

493
00:24:28,080 --> 00:24:32,880
The RAC governance pattern, RAC systems, retrieval augmented generation,

494
00:24:32,880 --> 00:24:35,680
are the standard for enterprise AI in 2026.

495
00:24:35,680 --> 00:24:37,080
But they expose a hard truth.

496
00:24:37,080 --> 00:24:40,280
The governance conversation matters more than the feature conversation.

497
00:24:40,280 --> 00:24:41,880
On paper, a RAC system is simple.

498
00:24:41,880 --> 00:24:43,880
You have a retrieval layer to pull documents,

499
00:24:43,880 --> 00:24:45,480
a ranking system to score them,

500
00:24:45,480 --> 00:24:47,880
a generation layer to ground the LLM response,

501
00:24:47,880 --> 00:24:51,880
but in reality, each component is a governance failure waiting to happen.

502
00:24:51,880 --> 00:24:54,680
Take the retrieval layer, it's only as good as your knowledge base,

503
00:24:54,680 --> 00:24:56,280
you have to know what's actually in there.

504
00:24:56,280 --> 00:24:57,680
Where did the documents come from?

505
00:24:57,680 --> 00:25:01,280
Is the information current or are you serving stale data to your users?

506
00:25:01,280 --> 00:25:04,680
And one level deeper, does that knowledge base contain regulated data?

507
00:25:04,680 --> 00:25:08,680
Customer info, proprietary research, confidential emails.

508
00:25:08,680 --> 00:25:12,080
If it does, you have to ask, who is allowed to see it?

509
00:25:12,080 --> 00:25:14,680
If an unauthorized user queries the system,

510
00:25:14,680 --> 00:25:17,080
the retrieval layer must respect those boundaries.

511
00:25:17,080 --> 00:25:19,880
But here's the problem, governance isn't the one time setup.

512
00:25:19,880 --> 00:25:21,880
When documents change the knowledge base changes,

513
00:25:21,880 --> 00:25:25,080
when the knowledge base changes, the behavior of your AI changes,

514
00:25:25,080 --> 00:25:27,880
you can't just drop files into a folder and hope for the best.

515
00:25:27,880 --> 00:25:30,080
You have to maintain that logic every single day.

516
00:25:30,080 --> 00:25:31,880
When you add a document, you validate it.

517
00:25:31,880 --> 00:25:33,680
When you modify one, you re-embed it.

518
00:25:33,680 --> 00:25:36,480
When you delete one, you update the index immediately.

519
00:25:36,480 --> 00:25:38,880
The ranking layer adds even more complexity.

520
00:25:38,880 --> 00:25:42,480
You have to decide how many documents to return and which algorithm ranks them.

521
00:25:42,480 --> 00:25:46,080
You have to set a confidence threshold to decide when the system should just give up

522
00:25:46,080 --> 00:25:47,680
and fall back to the base model.

523
00:25:47,680 --> 00:25:49,080
These are deliberate choices.

524
00:25:49,080 --> 00:25:52,080
And those choices dictate how your AI behaves in the real world.

525
00:25:52,080 --> 00:25:54,480
Testing this means asking uncomfortable questions.

526
00:25:54,480 --> 00:25:56,280
Does it actually find the right info?

527
00:25:56,280 --> 00:25:58,080
Or does it miss the point in return noise?

528
00:25:58,080 --> 00:26:00,680
Does it accidentally leak a document that should have been locked down?

529
00:26:00,680 --> 00:26:01,480
You need proof.

530
00:26:01,480 --> 00:26:05,080
You have to maintain evidence that the system was tested and that it actually passed.

531
00:26:05,080 --> 00:26:06,680
Then there's the generation layer.

532
00:26:06,680 --> 00:26:08,080
This is where safety happens.

533
00:26:08,080 --> 00:26:10,680
The LLM is supposed to stay grounded in your documents,

534
00:26:10,680 --> 00:26:11,880
but LLM's hallucinate.

535
00:26:11,880 --> 00:26:12,880
They invent facts.

536
00:26:12,880 --> 00:26:15,480
They blend info in ways that are flat out misleading.

537
00:26:15,480 --> 00:26:19,080
They can expose secrets even if the retrieval layer worked perfectly.

538
00:26:19,080 --> 00:26:20,880
So you test the generation layer separately.

539
00:26:20,880 --> 00:26:22,680
Does the LLM stay inside the lines?

540
00:26:22,680 --> 00:26:25,080
Does it handle cases where the documents don't have the answer?

541
00:26:25,080 --> 00:26:26,480
You test these properties.

542
00:26:26,480 --> 00:26:28,080
And you keep the receipts.

543
00:26:28,080 --> 00:26:29,680
This is an orchestration problem.

544
00:26:29,680 --> 00:26:32,080
The retrieval layer has to talk to the generation layer.

545
00:26:32,080 --> 00:26:34,680
The knowledge base has to stay in sync with the vector store.

546
00:26:34,680 --> 00:26:39,280
You have to monitor for drift where the behavior shifts even though you didn't change a line of code.

547
00:26:39,280 --> 00:26:41,480
Azure DevOps pipelines handle this natively.

548
00:26:41,480 --> 00:26:45,480
You build a pipeline that pulls from source systems and validates the data.

549
00:26:45,480 --> 00:26:47,880
It generates embeddings and updates your store.

550
00:26:47,880 --> 00:26:52,480
It runs retrieval tests to verify the ranking and generation tests to verify the safety.

551
00:26:52,480 --> 00:26:55,080
It enforces approval gates before anything hits production.

552
00:26:55,080 --> 00:26:57,480
That's a complete rag governance life cycle.

553
00:26:57,480 --> 00:26:58,880
Every step is logged.

554
00:26:58,880 --> 00:27:00,280
Every approval is recorded.

555
00:27:00,280 --> 00:27:05,080
The evidence chain is continuous, not something you try to scramble and reconstruct after an audit fails.

556
00:27:05,080 --> 00:27:07,280
The alternative is building this yourself on GitHub.

557
00:27:07,280 --> 00:27:11,080
You use GitHub for code, another tool for evaluation, a third tool for monitoring.

558
00:27:11,080 --> 00:27:12,680
You have to glue them together.

559
00:27:12,680 --> 00:27:14,080
You have to maintain the orchestration.

560
00:27:14,080 --> 00:27:15,680
It's possible, but it's complex.

561
00:27:15,680 --> 00:27:20,080
It's error prone and it's a nightmare to audit for a regulated organization.

562
00:27:20,080 --> 00:27:22,280
Azure DevOps is the direct path.

563
00:27:22,280 --> 00:27:24,280
The 28% migration trap.

564
00:27:24,280 --> 00:27:28,880
Here's what happens when an organization decides to move everything from Azure DevOps to GitHub.

565
00:27:28,880 --> 00:27:30,080
And I mean everything.

566
00:27:30,080 --> 00:27:33,880
The repos, the pipelines, the boards, the test plans, a total cut-over.

567
00:27:33,880 --> 00:27:37,080
In the first year, they see a cost increase of 28%.

568
00:27:37,080 --> 00:27:38,280
This isn't a guess.

569
00:27:38,280 --> 00:27:43,480
Analysis of enterprise negotiations across multiple large companies shows this happens every time.

570
00:27:43,480 --> 00:27:48,480
It catches CIOs off guard because the move looked like a massive cost-saving win on the spreadsheet.

571
00:27:48,480 --> 00:27:50,280
The trap starts with license overlap.

572
00:27:50,280 --> 00:27:53,680
You can't just flip a switch and shut down Azure DevOps on day one.

573
00:27:53,680 --> 00:27:56,880
Teams are still working in ADO while others are learning GitHub.

574
00:27:56,880 --> 00:27:58,680
You run both platforms in parallel.

575
00:27:58,680 --> 00:28:01,880
GitHub Enterprise Cloud is about $231 per user.

576
00:28:01,880 --> 00:28:03,680
ADO basic is only $72.

577
00:28:03,680 --> 00:28:07,880
If you have 100 developers, you're paying over $30,000 a year during the transition

578
00:28:07,880 --> 00:28:09,680
when you used to pay 7,000.

579
00:28:09,680 --> 00:28:13,680
That overlap usually lasts 18 to 24 months, not the three months you planned for.

580
00:28:13,680 --> 00:28:15,880
But the licenses are actually the cheap part.

581
00:28:15,880 --> 00:28:18,280
The real pain starts when you rebuild your pipelines.

582
00:28:18,280 --> 00:28:21,280
As your pipelines and GitHub actions are conceptually similar,

583
00:28:21,280 --> 00:28:23,680
but the execution models are completely different.

584
00:28:23,680 --> 00:28:25,080
The error handling is different.

585
00:28:25,080 --> 00:28:26,080
The integrations are different.

586
00:28:26,080 --> 00:28:28,080
You don't just move a pipeline.

587
00:28:28,080 --> 00:28:29,480
You rewrite it from scratch.

588
00:28:29,480 --> 00:28:33,680
The industry average is about one to two days of work to rebuild and validate a single pipeline.

589
00:28:33,680 --> 00:28:34,880
That sounds fine for one app.

590
00:28:34,880 --> 00:28:37,680
But most organizations have two or three hundred pipelines.

591
00:28:37,680 --> 00:28:40,280
If you have 200 pipelines in each takes a full day,

592
00:28:40,280 --> 00:28:42,480
that's 200 days of engineering time.

593
00:28:42,480 --> 00:28:44,680
At a loaded rate of $200 an hour,

594
00:28:44,680 --> 00:28:47,680
you're looking at $320,000 in labor alone.

595
00:28:47,680 --> 00:28:50,080
And that's before you find the edge cases in production.

596
00:28:50,080 --> 00:28:53,480
Before you retrain the staff, then you hit the boards and test plans problem.

597
00:28:53,480 --> 00:28:56,680
If you rely on Azure boards for complex planning and hierarchy,

598
00:28:56,680 --> 00:28:58,280
GitHub projects isn't going to cut it.

599
00:28:58,280 --> 00:29:01,680
It's not feature equivalent.

600
00:29:01,680 --> 00:29:04,080
Most companies that leave boards end up buying Gira 2.

601
00:29:04,080 --> 00:29:06,080
Now you're paying for GitHub plus Gira.

602
00:29:06,080 --> 00:29:10,080
That's a new license, a new migration, more retraining.

603
00:29:10,080 --> 00:29:11,880
Azure Test Plans is the same story.

604
00:29:11,880 --> 00:29:14,080
It's a specialized tool for regulated environments.

605
00:29:14,080 --> 00:29:15,880
GitHub doesn't have a native version of it.

606
00:29:15,880 --> 00:29:18,680
So you either keep paying for ADO just for the test plans

607
00:29:18,680 --> 00:29:20,480
or you buy a whole new testing suite.

608
00:29:20,480 --> 00:29:22,680
Either way, your license count isn't going down.

609
00:29:22,680 --> 00:29:25,080
The operational overhead ties it all together.

610
00:29:25,080 --> 00:29:27,280
You're maintaining links between GitHub and ADO.

611
00:29:27,280 --> 00:29:28,480
You're syncing work items.

612
00:29:28,480 --> 00:29:30,480
You're managing two different identity systems.

613
00:29:30,480 --> 00:29:31,680
This is the 28 percent trap.

614
00:29:31,680 --> 00:29:32,680
It's not one big bill.

615
00:29:32,680 --> 00:29:36,680
It's five medium costs that compound until the project is underwater.

616
00:29:36,680 --> 00:29:39,880
Organizations fail here because they focus on the GitHub sticker price

617
00:29:39,880 --> 00:29:42,880
and ignore the rebuild labor and the platform overlap.

618
00:29:42,880 --> 00:29:45,480
But there is an alternative, a selective hybrid model.

619
00:29:45,480 --> 00:29:48,480
You move the repos and pipelines that actually benefit from GitHub.

620
00:29:48,480 --> 00:29:51,680
You keep boards and test plans as your DevOps where they work best.

621
00:29:51,680 --> 00:29:54,880
That approach actually leads to savings of 12 to 18 percent

622
00:29:54,880 --> 00:29:57,480
because you're only moving the pieces that make sense.

623
00:29:57,480 --> 00:30:00,880
Instead of forcing a replacement that doesn't need to happen.

624
00:30:00,880 --> 00:30:03,080
The TCO model for CIOs.

625
00:30:03,080 --> 00:30:07,480
By 2026, CIOs have stopped debating the philosophy of the cloud.

626
00:30:07,480 --> 00:30:09,680
They are modeling the reality in spreadsheets.

627
00:30:09,680 --> 00:30:12,480
When you build a detailed total cost of ownership model,

628
00:30:12,480 --> 00:30:16,080
you have to look at migration labor, license overlap and rebuild effort.

629
00:30:16,080 --> 00:30:20,880
You also have to account for integration overhead and operational costs across a five-year window.

630
00:30:20,880 --> 00:30:23,280
When you do that, something interesting emerges.

631
00:30:23,280 --> 00:30:25,480
Hybrid does not just look better on paper.

632
00:30:25,480 --> 00:30:26,680
It wins almost every time.

633
00:30:26,680 --> 00:30:31,480
Let's look at how a typical model works for a hundred-person development shop running 200 pipelines.

634
00:30:31,480 --> 00:30:32,880
You start with year one costs.

635
00:30:32,880 --> 00:30:34,480
If you choose a full migration to GitHub,

636
00:30:34,480 --> 00:30:38,480
you are paying for GitHub Enterprise at $231 per user annually.

637
00:30:38,480 --> 00:30:42,080
That is $23,100 for your hundred developers.

638
00:30:42,080 --> 00:30:45,480
But you are still running Azure DevOps in parallel during the transition.

639
00:30:45,480 --> 00:30:48,880
So you add another $7,200 for those seats.

640
00:30:48,880 --> 00:30:53,280
Copilot licenses at $20 monthly per user at $24,000 a year to the bill.

641
00:30:53,280 --> 00:30:54,480
Then you hit the labor.

642
00:30:54,480 --> 00:30:57,880
Rebuilding a pipeline takes about one day on average for 200 pipelines

643
00:30:57,880 --> 00:31:00,080
that is 200 days of engineering time.

644
00:31:00,080 --> 00:31:02,080
At a $200 loaded hourly rate,

645
00:31:02,080 --> 00:31:05,680
you are looking at roughly $320,000 just for the move.

646
00:31:05,680 --> 00:31:10,080
Training and change management for a hundred developers will cost you another 20 to $40,000.

647
00:31:10,080 --> 00:31:14,280
Finally, you have to budget 10 to $50,000 for the integration work required

648
00:31:14,280 --> 00:31:16,280
to keep your systems talking to each other.

649
00:31:16,280 --> 00:31:23,280
Your year one total for a full GitHub migration runs between $405,000 and $465,000.

650
00:31:23,280 --> 00:31:26,680
The midpoint estimate is roughly $440,000.

651
00:31:26,680 --> 00:31:28,680
Now, look at the model for selective hybrid.

652
00:31:28,680 --> 00:31:30,880
You move the repositories that actually make sense,

653
00:31:30,880 --> 00:31:34,080
like new cloud native projects, AI teams or innovation initiatives.

654
00:31:34,080 --> 00:31:36,080
You keep boards and test plans in Azure DevOps

655
00:31:36,080 --> 00:31:38,680
because your compliance processes are already built around them.

656
00:31:38,680 --> 00:31:42,280
Instead of 200 pipelines, you are only rebuilding 100.

657
00:31:42,280 --> 00:31:44,680
GitHub and co-pilot licenses stay the same.

658
00:31:44,680 --> 00:31:47,880
And ADO licenses remain at $7,200.

659
00:31:47,880 --> 00:31:49,480
The big shift is in the labor costs.

660
00:31:49,480 --> 00:31:52,480
Your pipeline rebuild is now 100 days instead of 200,

661
00:31:52,480 --> 00:31:57,280
which drops that cost from $320,000 down to $160,000.

662
00:31:57,280 --> 00:32:01,080
Training is lighter because you aren't forcing people onto a new board's experience,

663
00:32:01,080 --> 00:32:03,280
so you only spend 10 to 20,000 there.

664
00:32:03,280 --> 00:32:06,280
Integration work is bounded because you aren't trying to replicate

665
00:32:06,280 --> 00:32:08,880
every single ADO capability inside GitHub.

666
00:32:08,880 --> 00:32:14,880
Your year one total for selective hybrid comes to roughly $210,000 to $270,000.

667
00:32:14,880 --> 00:32:17,080
The midpoint is $240,000,

668
00:32:17,080 --> 00:32:20,280
that is a $200,000 difference in the first year alone.

669
00:32:20,280 --> 00:32:22,680
Year two, three, year five look a bit different.

670
00:32:22,680 --> 00:32:26,880
With a full GitHub migration, your ongoing costs are about $280,000

671
00:32:26,880 --> 00:32:29,680
annually for licenses, co-pilot and maintenance.

672
00:32:29,680 --> 00:32:32,080
With selective hybrid, you are paying for both platforms,

673
00:32:32,080 --> 00:32:35,880
so your ongoing costs are closer to $310,000 a year.

674
00:32:35,880 --> 00:32:38,480
That is $30,000 higher every year.

675
00:32:38,480 --> 00:32:39,880
But here is where the math works.

676
00:32:39,880 --> 00:32:44,280
Your $200,000 savings in year one means you break even on those higher ongoing costs

677
00:32:44,280 --> 00:32:45,680
by the middle of year two.

678
00:32:45,680 --> 00:32:49,680
After that point, the hybrid model starts to compound its financial advantage.

679
00:32:49,680 --> 00:32:55,480
The five year total cost of ownership for a full GitHub migration is roughly $1.9 million.

680
00:32:55,480 --> 00:32:58,280
Selective hybrid costs roughly $1.49 million,

681
00:32:58,280 --> 00:33:02,080
that gives the hybrid approach of $410,000 advantage over five years.

682
00:33:02,080 --> 00:33:05,080
This analysis does not even factor in productivity benefits,

683
00:33:05,080 --> 00:33:06,480
though those are very real.

684
00:33:06,480 --> 00:33:09,480
Organizations that move to GitHub see measurable gains from co-pilot

685
00:33:09,480 --> 00:33:14,080
and a better developer experience, which usually leads to a 5 to 10% efficiency jump.

686
00:33:14,080 --> 00:33:19,480
Organizations that keep boards see compliance benefits that reduce audit friction and regulatory risk.

687
00:33:19,480 --> 00:33:26,480
A conservative estimate for that productivity value is $750,000 to $1.5 million annually for a hundred developers.

688
00:33:26,480 --> 00:33:28,480
That value exists no matter which path you choose,

689
00:33:28,480 --> 00:33:30,480
so it does not change the comparison between the two.

690
00:33:30,480 --> 00:33:32,480
What actually changes is the risk.

691
00:33:32,480 --> 00:33:36,080
A full migration concentrates all your risk into one big execution.

692
00:33:36,080 --> 00:33:39,480
Hybrid spreads that risk across time and different types of workloads.

693
00:33:39,480 --> 00:33:44,480
Full migration forces every single person to learn new governance models at the same time.

694
00:33:44,480 --> 00:33:47,480
Hybrid lets adoption happen at different speeds for different teams.

695
00:33:47,480 --> 00:33:50,480
This is the analysis driving CIO decisions in 2026.

696
00:33:50,480 --> 00:33:53,080
It is not about being a fan of one tool or the other.

697
00:33:53,080 --> 00:33:54,480
It is purely financial.

698
00:33:54,480 --> 00:33:58,480
Selective hybrid delivers better economics, lower risk and the same outcomes.

699
00:33:58,480 --> 00:34:00,880
How organizations actually migrate?

700
00:34:00,880 --> 00:34:04,080
The way organizations actually migrate looks nothing like the playbooks.

701
00:34:04,080 --> 00:34:06,880
The playbooks assume you make a strategic decision in the first quarter,

702
00:34:06,880 --> 00:34:10,680
plan through the second execute in the third and stabilize by the end of the year.

703
00:34:10,680 --> 00:34:13,280
It looks clean, sequential and predictable.

704
00:34:13,280 --> 00:34:15,080
But that is not what happens in the real world.

705
00:34:15,080 --> 00:34:16,480
The real process is iterative.

706
00:34:16,480 --> 00:34:18,880
An organization identifies a low-risk project,

707
00:34:18,880 --> 00:34:21,480
usually something new that isn't heavily regulated.

708
00:34:21,480 --> 00:34:25,480
They pick an experienced team that won't fall apart if the migration hits the snag.

709
00:34:25,480 --> 00:34:29,480
They move that one project to GitHub and run it in production for three to six months.

710
00:34:29,480 --> 00:34:32,680
They document every single thing that broke and everything that worked.

711
00:34:32,680 --> 00:34:35,480
Then they take those lessons and move the next batch of projects.

712
00:34:35,480 --> 00:34:37,080
They rinse and repeat this cycle.

713
00:34:37,080 --> 00:34:39,280
By the time they have moved five projects successfully,

714
00:34:39,280 --> 00:34:40,680
they start to feel confident.

715
00:34:40,680 --> 00:34:42,280
By the time they have moved 15,

716
00:34:42,280 --> 00:34:44,680
they finally understand their actual costs and risks.

717
00:34:44,680 --> 00:34:47,280
They aren't looking at theoretical numbers from a playbook anymore.

718
00:34:47,280 --> 00:34:49,880
This approach is slower than a big coordinated migration,

719
00:34:49,880 --> 00:34:51,280
but the risk is much lower.

720
00:34:51,280 --> 00:34:55,080
It allows organizations to adjust their strategy as they learn.

721
00:34:55,080 --> 00:34:58,880
The first project teaches you what you didn't know you didn't know.

722
00:34:58,880 --> 00:35:02,080
The fifth project tests, whether that first success was just a fluke.

723
00:35:02,080 --> 00:35:06,680
By the fifteenth project, you actually understand the mechanics of what works for your specific culture.

724
00:35:06,680 --> 00:35:07,880
During this iterative process,

725
00:35:07,880 --> 00:35:09,880
running systems in parallel is unavoidable.

726
00:35:09,880 --> 00:35:12,480
The same code lives in both Azure Reepers and GitHub

727
00:35:12,480 --> 00:35:15,680
and the same pipelines run in both actions and as your pipelines.

728
00:35:15,680 --> 00:35:19,480
You might even track the same work items in both Azure boards and GitHub issues

729
00:35:19,480 --> 00:35:21,080
until a team fully commits.

730
00:35:21,080 --> 00:35:24,880
It is inefficient to maintain duplicate data and test two systems at once,

731
00:35:24,880 --> 00:35:25,880
but it is safe.

732
00:35:25,880 --> 00:35:30,280
Teams can learn the new platform without the pressure of a bet the business deadline.

733
00:35:30,280 --> 00:35:33,880
Parallel running buys you the time to discover the problems you didn't plan for.

734
00:35:33,880 --> 00:35:36,080
Most organizations never actually move everything.

735
00:35:36,080 --> 00:35:40,480
They discover early on that some things make sense to move while others are better left alone.

736
00:35:40,480 --> 00:35:44,280
They move repositories that are new or less connected to legacy infrastructure.

737
00:35:44,280 --> 00:35:47,480
They move pipelines for applications built on cloud native patents,

738
00:35:47,480 --> 00:35:51,280
but they keep Azure boards if their compliance processes are wrapped tightly around it.

739
00:35:51,280 --> 00:35:55,280
They keep Azure test plans if their formal QA depends on that specific tool.

740
00:35:55,280 --> 00:35:58,080
They keep pipelines if they have built complex release orchestration

741
00:35:58,080 --> 00:35:59,680
that is tied to enterprise governance.

742
00:35:59,680 --> 00:36:02,280
The selective retention is just being pragmatic.

743
00:36:02,280 --> 00:36:06,280
It lets you capture the benefits of GitHub without blowing up the governance infrastructure

744
00:36:06,280 --> 00:36:07,680
that depends on ADO.

745
00:36:07,680 --> 00:36:12,480
The integration challenge starts to show up once you are actually running a hybrid setup.

746
00:36:12,480 --> 00:36:15,680
Work items created in GitHub have to link back to Azure boards.

747
00:36:15,680 --> 00:36:18,280
Commits push to GitHub must be traceable in ADO.

748
00:36:18,280 --> 00:36:22,480
Your identity and access management systems have to stay perfectly synchronized.

749
00:36:22,480 --> 00:36:27,280
Service connections and authentication tokens have to work across both platforms without failing.

750
00:36:27,280 --> 00:36:31,680
This requires custom automation and a lot of discipline in how teams name and link things.

751
00:36:31,680 --> 00:36:35,080
You have to plan your access management carefully so people can work in both systems

752
00:36:35,080 --> 00:36:37,480
without getting confused or creating security gaps.

753
00:36:37,480 --> 00:36:40,680
Most organizations underestimate this part of the job.

754
00:36:40,680 --> 00:36:43,280
They think integration is just a small bit of overhead.

755
00:36:43,280 --> 00:36:48,280
Then they discover that keeping two massive systems in sync is much harder than they expected.

756
00:36:48,280 --> 00:36:50,280
Team dynamics make everything more complicated.

757
00:36:50,280 --> 00:36:53,080
Some teams love GitHub and will move as fast as you let them.

758
00:36:53,080 --> 00:36:56,280
Other teams are comfortable with ADO and will resist the change.

759
00:36:56,280 --> 00:36:58,280
Some teams are split right down the middle.

760
00:36:58,280 --> 00:37:01,880
Managing these people dynamics is just as important as the technical migration.

761
00:37:01,880 --> 00:37:04,480
Organizations that treat this as a change management problem,

762
00:37:04,480 --> 00:37:07,480
rather than just a tech problem, are the ones that succeed.

763
00:37:07,480 --> 00:37:10,680
Organizations that assume everyone will just naturally adopt the new platform

764
00:37:10,680 --> 00:37:11,680
are the ones that struggle.

765
00:37:11,680 --> 00:37:15,680
By the time organizations have real experience with this, they all report the same lessons.

766
00:37:15,680 --> 00:37:19,080
Full migration always takes longer and costs more than the initial estimate.

767
00:37:19,080 --> 00:37:22,680
Selective hybrid is a more pragmatic choice than forcing a full move.

768
00:37:22,680 --> 00:37:26,480
Integration between the two platforms is harder than it looks on a slide deck.

769
00:37:26,480 --> 00:37:30,480
Team adoption moves faster when you give people a choice instead of a mandate.

770
00:37:30,480 --> 00:37:33,280
You have to redesign your governance, not just migrated.

771
00:37:33,280 --> 00:37:37,680
The benefits of GitHub like the AI features and the developer experience are very real.

772
00:37:37,680 --> 00:37:40,680
But they take time to actually realize the compliance infrastructure

773
00:37:40,680 --> 00:37:44,080
you spend years building in ADO does not automatically move over to GitHub.

774
00:37:44,080 --> 00:37:47,280
You have to rebuild it from scratch and that rebuilding process is exactly

775
00:37:47,280 --> 00:37:49,280
where most organizations start to stumble.

776
00:37:49,280 --> 00:37:52,280
The hybrid operating model.

777
00:37:52,280 --> 00:37:57,280
The organization succeeding with hybrid stacks in 2026 aren't just running two platforms.

778
00:37:57,280 --> 00:37:59,680
They've designed an operating model around the split.

779
00:37:59,680 --> 00:38:02,880
Most organizations miss this. They start hybrid without architecture.

780
00:38:02,880 --> 00:38:05,480
And that's where it breaks. It starts with platform allocation.

781
00:38:05,480 --> 00:38:08,080
This sounds obvious, but most organizations get it wrong.

782
00:38:08,080 --> 00:38:09,880
You don't split by team randomly.

783
00:38:09,880 --> 00:38:12,480
You create clear criteria for what lives where.

784
00:38:12,480 --> 00:38:17,080
GitHub owns the code, repositories, pull requests, CICD through GitHub actions,

785
00:38:17,080 --> 00:38:21,880
security scanning like code, QL and Dependerbot and AI assisted development where Copilot lives.

786
00:38:21,880 --> 00:38:23,880
Azure DevOps owns the structure.

787
00:38:23,880 --> 00:38:28,280
The board system for portfolio and program planning tests plans for formal QA and evidence.

788
00:38:28,280 --> 00:38:32,080
Pipelines for complex release orchestration where approval gates are critical.

789
00:38:32,080 --> 00:38:35,880
And artifacts for version dependencies that regulatory processes depend on.

790
00:38:35,880 --> 00:38:38,280
The integration points must be defined explicitly.

791
00:38:38,280 --> 00:38:41,880
Work items sync between platforms, commits link back to board items.

792
00:38:41,880 --> 00:38:45,280
Pipelines trigger across systems, dashboards aggregate metrics from both.

793
00:38:45,280 --> 00:38:46,480
But here's the problem.

794
00:38:46,480 --> 00:38:50,280
This allocation only works if you build governance architecture around it.

795
00:38:50,280 --> 00:38:52,480
A central platform team defines the standards.

796
00:38:52,480 --> 00:38:55,880
They maintain templates in both systems, but they aren't gatekeepers.

797
00:38:55,880 --> 00:38:58,480
Domain teams, product, infrastructure, security,

798
00:38:58,480 --> 00:39:00,080
operate within those standards.

799
00:39:00,080 --> 00:39:02,480
They choose the platform that fits their workload.

800
00:39:02,480 --> 00:39:04,180
A governance council meets quarterly.

801
00:39:04,180 --> 00:39:06,480
They review decisions. They resolve conflicts.

802
00:39:06,480 --> 00:39:09,280
They adjust standards as experience accumulates.

803
00:39:09,280 --> 00:39:14,080
This council includes engineering leadership, security, compliance, and the platform team.

804
00:39:14,080 --> 00:39:16,480
Without them, hybrid devolves into chaos.

805
00:39:16,480 --> 00:39:18,380
Every team makes independent decisions.

806
00:39:18,380 --> 00:39:19,880
You end up with no consistency.

807
00:39:19,880 --> 00:39:22,280
Identity and access management becomes critical.

808
00:39:22,280 --> 00:39:23,880
Now you have two platforms to manage.

809
00:39:23,880 --> 00:39:26,680
You need a single source of truth, enter ID or Azure ID.

810
00:39:26,680 --> 00:39:29,280
You synchronize groups and roles across both systems.

811
00:39:29,280 --> 00:39:33,480
A developer should have one identity that works in both GitHub and Azure DevOps.

812
00:39:33,480 --> 00:39:36,180
Permissions are defined in one place and reflect in both.

813
00:39:36,180 --> 00:39:39,680
If someone changes roles, their access changes everywhere simultaneously.

814
00:39:39,680 --> 00:39:43,280
You run regular access reviews across both platforms, not separately.

815
00:39:43,280 --> 00:39:44,880
You establish clear permission models.

816
00:39:44,880 --> 00:39:47,480
It must be obvious who can do what in each platform.

817
00:39:47,480 --> 00:39:49,380
The synchronization isn't automatic.

818
00:39:49,380 --> 00:39:52,580
It requires deliberate architecture and ongoing maintenance.

819
00:39:52,580 --> 00:39:55,380
Integration automation is where most organizations struggle.

820
00:39:55,380 --> 00:39:56,880
They underestimate the complexity.

821
00:39:56,880 --> 00:39:59,880
Work items created in GitHub have to appear in Azure boards.

822
00:39:59,880 --> 00:40:02,880
Commits pushed to GitHub need to link back to ADO work items.

823
00:40:02,880 --> 00:40:05,280
Pipelines in one system trigger work in another.

824
00:40:05,280 --> 00:40:07,680
There are third-party tools that handle some of this.

825
00:40:07,680 --> 00:40:10,980
Services that sync work items between GitHub and ADO exist.

826
00:40:10,980 --> 00:40:13,480
But there's always custom automation required.

827
00:40:13,480 --> 00:40:15,680
You're building bridges and bridges need maintenance.

828
00:40:15,680 --> 00:40:18,480
Metrics and measurement must span both platforms.

829
00:40:18,480 --> 00:40:21,480
You measure door or metrics across both GitHub and Azure DevOps.

830
00:40:21,480 --> 00:40:22,580
Lead time for changes.

831
00:40:22,580 --> 00:40:23,780
Deployment frequency.

832
00:40:23,780 --> 00:40:24,780
Change failure rate.

833
00:40:24,780 --> 00:40:26,380
Mean time to recovery.

834
00:40:26,380 --> 00:40:28,280
You measure developer satisfaction.

835
00:40:28,280 --> 00:40:32,280
You measure compliance metrics like audit trail completeness and approval gate compliance.

836
00:40:32,280 --> 00:40:35,080
And you measure cost per outcome, not just cost per user.

837
00:40:35,080 --> 00:40:37,580
These metrics tell you if your allocation is working.

838
00:40:37,580 --> 00:40:40,780
If one platform consistently underperforms, you adjust.

839
00:40:40,780 --> 00:40:42,780
Change management is subtle but essential.

840
00:40:42,780 --> 00:40:45,880
You communicate clearly about which workloads go where and why.

841
00:40:45,880 --> 00:40:48,080
You provide training for teams on both platforms.

842
00:40:48,080 --> 00:40:50,880
You identify champions in each team who help adoption.

843
00:40:50,880 --> 00:40:53,680
You run retrospectives monthly at first then quarterly.

844
00:40:53,680 --> 00:40:55,980
You surface what's working and what's breaking.

845
00:40:55,980 --> 00:40:58,880
That feedback loop is how you know if the model works in practice.

846
00:40:58,880 --> 00:41:00,980
The platform team is the backbone of hybrid.

847
00:41:00,980 --> 00:41:03,280
They maintain reusable templates in both systems.

848
00:41:03,280 --> 00:41:04,480
They manage integrations.

849
00:41:04,480 --> 00:41:06,080
They provide guidance to teams.

850
00:41:06,080 --> 00:41:07,680
They respond when integration breaks.

851
00:41:07,680 --> 00:41:10,280
They monitor whether governance is actually being followed.

852
00:41:10,280 --> 00:41:11,780
They measure adoption metrics.

853
00:41:11,780 --> 00:41:15,480
This role didn't exist in pure ADO or pure GitHub organizations.

854
00:41:15,480 --> 00:41:18,880
It emerges because hybrid complexity requires dedicated ownership.

855
00:41:18,880 --> 00:41:20,880
Without a platform team hybrid fails.

856
00:41:20,880 --> 00:41:22,480
A transition timeline is realistic.

857
00:41:22,480 --> 00:41:24,680
Months one through three are designed and pilot.

858
00:41:24,680 --> 00:41:28,680
Months four through six expand to multiple teams and refine based on what breaks.

859
00:41:28,680 --> 00:41:30,680
Months seven through twelve are full rollout.

860
00:41:30,680 --> 00:41:32,180
Your two is optimization.

861
00:41:32,180 --> 00:41:35,480
This takes time because integration issues surface slowly.

862
00:41:35,480 --> 00:41:37,880
You need that time to build confidence before scaling.

863
00:41:37,880 --> 00:41:39,980
What's coming in 2027 and beyond.

864
00:41:39,980 --> 00:41:41,480
The trajectory is becoming clear.

865
00:41:41,480 --> 00:41:43,680
By 2026 the narrative has shifted.

866
00:41:43,680 --> 00:41:45,880
It's no longer about which platform wins.

867
00:41:45,880 --> 00:41:48,280
It's about how do these platforms work together.

868
00:41:48,280 --> 00:41:50,280
That shift points to what's happening next.

869
00:41:50,280 --> 00:41:53,880
Microsoft will keep tightening the integration between GitHub and Azure DevOps.

870
00:41:53,880 --> 00:41:55,580
Not because one platform is failing,

871
00:41:55,580 --> 00:41:59,080
but because the market has spoken organizations want both.

872
00:41:59,080 --> 00:42:01,880
The investment will go into making them work together more seamlessly.

873
00:42:01,880 --> 00:42:04,280
You'll see deeper work item synchronization.

874
00:42:04,280 --> 00:42:08,680
Real-time sync where a status change in GitHub reflects in ADO within seconds.

875
00:42:08,680 --> 00:42:12,680
Better pipeline orchestration where events in one system trigger workflows in the other.

876
00:42:12,680 --> 00:42:16,280
Unified dashboards will show metrics from both platforms without switching contacts.

877
00:42:16,280 --> 00:42:19,280
Identity and access management will feel like a single system.

878
00:42:19,280 --> 00:42:20,580
Even though it's technically two,

879
00:42:20,580 --> 00:42:22,880
this convergence isn't going to make hybrid perfect,

880
00:42:22,880 --> 00:42:24,780
but it will make it less painful to operate.

881
00:42:24,780 --> 00:42:28,280
AI governance is where the next wave of investment actually matters.

882
00:42:28,280 --> 00:42:31,980
Organizations are moving LLM systems from pilots into production.

883
00:42:31,980 --> 00:42:33,480
Governance requirements are tightening.

884
00:42:33,480 --> 00:42:36,880
The EU AI Act enforcement is real and it's expensive to get wrong.

885
00:42:36,880 --> 00:42:41,180
Both platforms will respond by building AI governance as a first class feature.

886
00:42:41,180 --> 00:42:42,380
Not an afterthought.

887
00:42:42,980 --> 00:42:45,680
Expect native support for AI evaluation pipelines,

888
00:42:45,680 --> 00:42:46,980
not just custom scripts,

889
00:42:46,980 --> 00:42:51,180
but a system to version prompts run safety evaluations and enforce approval gates.

890
00:42:51,180 --> 00:42:54,180
Better audit trails are coming specifically designed for AI,

891
00:42:54,180 --> 00:42:55,680
not general purpose logging,

892
00:42:55,680 --> 00:42:59,780
but trails that capture the lineage of data, training decisions and evaluations.

893
00:42:59,780 --> 00:43:04,680
Integrated safety checks and compliance gates will automatically block unsafe configurations.

894
00:43:04,680 --> 00:43:07,280
Eventually we'll see AI powered governance itself.

895
00:43:07,280 --> 00:43:10,080
Machine learning models will watch your deployment pipelines.

896
00:43:10,080 --> 00:43:12,880
They will flag potential compliance issues before they happen.

897
00:43:12,880 --> 00:43:14,980
Azure DevOps will likely move faster here.

898
00:43:14,980 --> 00:43:16,280
That's where governance lives,

899
00:43:16,280 --> 00:43:20,580
but GitHub will catch up because it's the platform where innovation teams are building AI.

900
00:43:20,580 --> 00:43:22,180
LMOPs will become its own category.

901
00:43:22,180 --> 00:43:24,080
It's not MLOPS, it's not traditional DevOps.

902
00:43:24,080 --> 00:43:25,280
It's something different.

903
00:43:25,280 --> 00:43:28,180
You'll see purpose-built LLMOPs platforms emerge.

904
00:43:28,180 --> 00:43:32,080
They will specialize in managing the unique challenges of LLM applications.

905
00:43:32,080 --> 00:43:35,780
Prompt versioning, evaluation, orchestration, model routing, safety monitoring.

906
00:43:35,780 --> 00:43:38,980
These platforms will integrate with both GitHub and Azure DevOps.

907
00:43:38,980 --> 00:43:40,280
They won't replace them.

908
00:43:40,280 --> 00:43:42,780
They'll plug into your existing pipeline architecture.

909
00:43:42,780 --> 00:43:48,380
They add the AI-specific layer that general purpose platforms can't provide natively.

910
00:43:48,380 --> 00:43:51,980
The platform team role will become table stakes in large organizations.

911
00:43:51,980 --> 00:43:52,980
Right now it's emerging.

912
00:43:52,980 --> 00:43:54,780
In 2027 it will be standard.

913
00:43:54,780 --> 00:43:58,580
You'll have dedicated platform engineering teams in most Fortune 500 companies.

914
00:43:58,580 --> 00:44:00,880
Their job is to maintain the internal developer platform.

915
00:44:00,880 --> 00:44:03,280
They abstract away the complexity of hybrid models.

916
00:44:03,280 --> 00:44:04,880
They build reusable templates.

917
00:44:04,880 --> 00:44:05,980
They manage integrations.

918
00:44:05,980 --> 00:44:07,180
They provide governance.

919
00:44:07,180 --> 00:44:12,180
These teams will treat their internal platform like a product with users, with support, with roadmaps.

920
00:44:12,180 --> 00:44:14,380
Regulations will keep tightening.

921
00:44:14,380 --> 00:44:16,880
The EU AI Act is just the first domino.

922
00:44:16,880 --> 00:44:18,980
Other countries are building their own frameworks.

923
00:44:18,980 --> 00:44:20,880
International harmonization is coming.

924
00:44:20,880 --> 00:44:25,880
Every new regulation will require tighter audit trails, better evidence logging, more formalized governance.

925
00:44:25,880 --> 00:44:29,880
And every regulation will push enterprises toward platforms designed for governance.

926
00:44:29,880 --> 00:44:31,680
That's Azure DevOps territory.

927
00:44:31,680 --> 00:44:34,180
The developer experience frontier will stay on GitHub.

928
00:44:34,180 --> 00:44:35,980
Copilot will get more sophisticated.

929
00:44:35,980 --> 00:44:37,980
Agente workflows will become more powerful.

930
00:44:37,980 --> 00:44:39,680
Repository intelligence will deepen.

931
00:44:39,680 --> 00:44:41,980
But GitHub won't try to become a governance platform.

932
00:44:41,980 --> 00:44:43,880
It will stay developer focused.

933
00:44:43,880 --> 00:44:45,480
Organizations will accept that trade-off.

934
00:44:45,480 --> 00:44:47,980
You'll see consolidation in the broader tooling ecosystems.

935
00:44:47,980 --> 00:44:49,280
Some platforms will disappear.

936
00:44:49,280 --> 00:44:50,180
Some will be acquired.

937
00:44:50,180 --> 00:44:52,880
Most organizations will standardize on a core stack.

938
00:44:52,880 --> 00:44:55,280
GitHub plus Azure DevOps plus specialized tools.

939
00:44:55,280 --> 00:44:57,980
They will stop trying to mix eight different platforms.

940
00:44:57,980 --> 00:45:00,480
The era of infinite point solutions is ending.

941
00:45:00,480 --> 00:45:02,780
By 2027 hybrid isn't an interim state.

942
00:45:02,780 --> 00:45:04,280
It's the permanent architecture.

943
00:45:04,280 --> 00:45:07,280
Organizations will stop treating it as a migration destination.

944
00:45:07,280 --> 00:45:09,380
They will start treating it as the intended design.

945
00:45:09,380 --> 00:45:12,180
The question won't be, when do we get to one platform?

946
00:45:12,180 --> 00:45:15,680
It will be, how do we make this architecture work better?

947
00:45:15,680 --> 00:45:17,580
How CIOs should think about this?

948
00:45:17,580 --> 00:45:20,880
The fundamental mistake CIOs make is treating this as a platform choice.

949
00:45:20,880 --> 00:45:21,680
It's not.

950
00:45:21,680 --> 00:45:25,580
It's a strategic decision about how your organization actually delivers software.

951
00:45:25,580 --> 00:45:27,280
The platform follows the strategy.

952
00:45:27,280 --> 00:45:28,380
Not the other way around.

953
00:45:28,380 --> 00:45:31,080
Start by asking what you're actually trying to optimize for.

954
00:45:31,080 --> 00:45:34,280
Every organization says they want both speed and compliance.

955
00:45:34,280 --> 00:45:37,280
But when you're forced to choose which one wins.

956
00:45:37,280 --> 00:45:41,080
If your answer is we need both equally, you're not thinking clearly.

957
00:45:41,080 --> 00:45:44,480
That's exactly the kind of indecision that leads to terrible outcomes.

958
00:45:44,480 --> 00:45:48,180
The organizations that succeed have clarity on their optimization vector.

959
00:45:48,180 --> 00:45:50,780
Are you optimizing for developer, velocity and innovation?

960
00:45:50,780 --> 00:45:52,780
Then your strategy has GitHub at the center.

961
00:45:52,780 --> 00:45:54,180
That doesn't mean you ignore governance.

962
00:45:54,180 --> 00:45:57,280
It means governance exists to unblock shipping, not slow it down.

963
00:45:57,280 --> 00:46:00,480
And you accept that some traditional controls need to shift.

964
00:46:00,480 --> 00:46:03,380
Formal change advisory boards and multi-stage release approvals

965
00:46:03,380 --> 00:46:05,880
move toward automated lightweight enforcement.

966
00:46:05,880 --> 00:46:08,880
Are you optimizing for compliance and regulatory risk reduction?

967
00:46:08,880 --> 00:46:11,880
Then Azure DevOps is structurally aligned with that priority.

968
00:46:11,880 --> 00:46:14,380
You're not choosing ADO because the interface is nice.

969
00:46:14,380 --> 00:46:17,480
You're choosing it because traceability and audit capability

970
00:46:17,480 --> 00:46:19,380
are built into how the product works.

971
00:46:19,380 --> 00:46:23,080
You accept that development will feel slower because governance gates are real.

972
00:46:23,080 --> 00:46:26,480
You manage the speed problem through education and better process design.

973
00:46:26,480 --> 00:46:27,880
Not by removing the gates.

974
00:46:27,880 --> 00:46:30,780
Most large organizations aren't optimizing for one thing.

975
00:46:30,780 --> 00:46:33,980
They're managing a portfolio where different workloads have different pressures.

976
00:46:33,980 --> 00:46:35,280
That's the real insight.

977
00:46:35,280 --> 00:46:36,680
The choice isn't binary.

978
00:46:36,680 --> 00:46:39,480
The choices which workloads optimize for which outcomes.

979
00:46:39,480 --> 00:46:42,280
And then platform selection flows from that classification.

980
00:46:42,280 --> 00:46:45,080
This framework changes how you think about the decision.

981
00:46:45,080 --> 00:46:47,680
You're not debating which platform is objectively better.

982
00:46:47,680 --> 00:46:50,680
You're defining the decision criteria that matter for each class of work.

983
00:46:50,680 --> 00:46:52,480
Then choosing the platform that fits,

984
00:46:52,480 --> 00:46:54,080
take governance as an example.

985
00:46:54,080 --> 00:46:56,680
In the abstract, most C.O's agree it's important.

986
00:46:56,680 --> 00:47:00,480
But what does governance actually mean for a customer facing AI system

987
00:47:00,480 --> 00:47:02,280
versus an internal tooling project?

988
00:47:02,280 --> 00:47:03,280
For the AI system,

989
00:47:03,280 --> 00:47:05,680
you need audit trails that prove you tested for buyers,

990
00:47:05,680 --> 00:47:08,280
ran safety evaluations and enforced approvals.

991
00:47:08,280 --> 00:47:09,480
For the internal tool,

992
00:47:09,480 --> 00:47:13,280
you probably need a simpler approval workflow and less rigorous evidence logging.

993
00:47:13,280 --> 00:47:15,680
Same concept, different implementation.

994
00:47:15,680 --> 00:47:18,880
This is where a platform team becomes essential.

995
00:47:18,880 --> 00:47:23,280
Because the team has to translate the strategic priorities into actual platform policies.

996
00:47:23,280 --> 00:47:26,680
If you've decided that certain workloads need formal governance,

997
00:47:26,680 --> 00:47:29,880
the platform team make sure that governance is enforced consistently.

998
00:47:29,880 --> 00:47:31,480
They don't debate whether governance is good.

999
00:47:31,480 --> 00:47:33,880
They implement the governance your strategy demands.

1000
00:47:33,880 --> 00:47:36,880
Measurement matters here in a way that surprises most C.O's.

1001
00:47:36,880 --> 00:47:38,280
You can't manage what you don't measure.

1002
00:47:38,280 --> 00:47:39,480
If you're running hybrid,

1003
00:47:39,480 --> 00:47:41,680
you need metrics that span both platforms.

1004
00:47:41,680 --> 00:47:44,880
Not how many developers are on GitHub versus ADO.

1005
00:47:44,880 --> 00:47:48,280
But what's the actual cost per delivered feature across both platforms?

1006
00:47:48,280 --> 00:47:49,880
What's the compliance gap we're carrying?

1007
00:47:49,880 --> 00:47:51,680
What's the developer satisfaction difference

1008
00:47:51,680 --> 00:47:54,480
between teams using GitHub and teams using ADO?

1009
00:47:54,480 --> 00:47:56,280
These metrics drive adjustment.

1010
00:47:56,280 --> 00:47:58,280
The measurement creates feedback loops.

1011
00:47:58,280 --> 00:48:02,280
You discover that your classification of which workload goes where was wrong.

1012
00:48:02,280 --> 00:48:06,280
A system you thought was low risk turned out to need more governance than you assumed.

1013
00:48:06,280 --> 00:48:09,680
A team you thought needed structure actually works better with autonomy.

1014
00:48:09,680 --> 00:48:11,880
The metrics tell you where your assumptions broke.

1015
00:48:11,880 --> 00:48:13,280
And then you adjust.

1016
00:48:13,280 --> 00:48:15,480
This iterative approach,

1017
00:48:15,480 --> 00:48:17,680
Classify, allocate, measure, adjust,

1018
00:48:17,680 --> 00:48:21,080
is how organizations actually navigate hybrid successfully.

1019
00:48:21,080 --> 00:48:23,280
Not through perfect initial planning,

1020
00:48:23,280 --> 00:48:24,680
but through structured learning.

1021
00:48:24,680 --> 00:48:26,680
You make a decision, you measure the outcome,

1022
00:48:26,680 --> 00:48:29,680
you adjust and over time the allocation becomes more accurate.

1023
00:48:29,680 --> 00:48:34,480
The role of the CIO in 2026 isn't to make a perfect platform choice upfront.

1024
00:48:34,480 --> 00:48:37,480
It's to establish a decision framework that lets the organization

1025
00:48:37,480 --> 00:48:39,880
make better platform choices iteratively

1026
00:48:39,880 --> 00:48:41,280
as the landscape changes

1027
00:48:41,280 --> 00:48:44,280
and as you learn more about your actual workloads and constraints.

1028
00:48:44,280 --> 00:48:46,480
The strategic clarity.

1029
00:48:46,480 --> 00:48:48,680
Here's what you need to understand as we close this out.

1030
00:48:48,680 --> 00:48:52,080
The entire premise of this conversation has been built on a false binary.

1031
00:48:52,080 --> 00:48:54,080
The industry narrative says GitHub one.

1032
00:48:54,080 --> 00:48:57,680
Your operational reality says Azure DevOps is where the actual governance happens.

1033
00:48:57,680 --> 00:49:00,880
Both statements are true and that truth is the actual insight.

1034
00:49:00,880 --> 00:49:05,880
In 2026, the question should we use Azure DevOps or GitHub is the wrong question.

1035
00:49:05,880 --> 00:49:08,680
It's like asking whether you should use TCP or HTTP,

1036
00:49:08,680 --> 00:49:11,080
there are different layers solving different problems.

1037
00:49:11,080 --> 00:49:12,080
The right question is,

1038
00:49:12,080 --> 00:49:14,680
what does my organization actually need to accomplish

1039
00:49:14,680 --> 00:49:17,880
and which platform lets us accomplish it most efficiently?

1040
00:49:17,880 --> 00:49:20,280
For some organizations that answer is GitHub first.

1041
00:49:20,280 --> 00:49:23,080
The organization is cloud native, the team is experienced,

1042
00:49:23,080 --> 00:49:24,600
regulatory exposure is minimal,

1043
00:49:24,600 --> 00:49:26,280
velocity is the competitive advantage.

1044
00:49:26,280 --> 00:49:29,080
In that context, you move to GitHub and you don't look back.

1045
00:49:29,080 --> 00:49:31,080
You're not sacrificing anything that matters.

1046
00:49:31,080 --> 00:49:34,680
For some organizations, Azure DevOps is genuinely the right answer.

1047
00:49:34,680 --> 00:49:38,080
The workloads are regulated, compliance isn't a secondary concern.

1048
00:49:38,080 --> 00:49:39,480
It's the primary constraint.

1049
00:49:39,480 --> 00:49:42,480
The systems are deeply integrated with legacy infrastructure.

1050
00:49:42,480 --> 00:49:45,080
In that context, staying on ADO isn't a conservative choice.

1051
00:49:45,080 --> 00:49:46,480
It's the pragmatic choice.

1052
00:49:46,480 --> 00:49:48,080
But for most large organizations,

1053
00:49:48,080 --> 00:49:50,880
and this is the critical insight nobody in the press talks about,

1054
00:49:50,880 --> 00:49:52,680
the answer is neither, it's both.

1055
00:49:52,680 --> 00:49:54,280
You build a hybrid architecture,

1056
00:49:54,280 --> 00:49:57,080
you allocate workloads based on their actual characteristics,

1057
00:49:57,080 --> 00:50:00,080
and you design governance that makes both platforms work together.

1058
00:50:00,080 --> 00:50:01,880
This hybrid approach isn't a compromise.

1059
00:50:01,880 --> 00:50:04,280
It's not, we couldn't decide, so we're running both.

1060
00:50:04,280 --> 00:50:08,080
It's a deliberate structural decision that acknowledges a reality.

1061
00:50:08,080 --> 00:50:12,080
One platform cannot simultaneously optimize for developer velocity

1062
00:50:12,080 --> 00:50:13,480
and compliance rigor.

1063
00:50:13,480 --> 00:50:15,280
GitHub leans into velocity.

1064
00:50:15,280 --> 00:50:17,080
Azure DevOps leans into compliance.

1065
00:50:17,080 --> 00:50:18,680
You need the velocity for innovation.

1066
00:50:18,680 --> 00:50:20,680
You need the compliance for risk management.

1067
00:50:20,680 --> 00:50:23,480
So you use both in the roles each was designed for.

1068
00:50:23,480 --> 00:50:25,080
The breakthrough here is this.

1069
00:50:25,080 --> 00:50:27,080
Organizations that accept this premise upfront,

1070
00:50:27,080 --> 00:50:28,880
that hybrid is the intended architecture,

1071
00:50:28,880 --> 00:50:31,680
not a temporary state, make better decisions faster.

1072
00:50:31,680 --> 00:50:34,080
They don't waste energy debating which platform is better.

1073
00:50:34,080 --> 00:50:35,480
They classify their workloads.

1074
00:50:35,480 --> 00:50:36,480
They allocate them.

1075
00:50:36,480 --> 00:50:37,680
They build integrations.

1076
00:50:37,680 --> 00:50:39,680
They measure outcomes and they move forward.

1077
00:50:39,680 --> 00:50:41,680
The organizations that are struggling are the ones

1078
00:50:41,680 --> 00:50:43,680
still trying to find the one true platform.

1079
00:50:43,680 --> 00:50:45,080
They believe there's a right answer.

1080
00:50:45,080 --> 00:50:46,080
They haven't found yet.

1081
00:50:46,080 --> 00:50:47,880
They keep reading about GitHub's advantages

1082
00:50:47,880 --> 00:50:49,480
and wondering if they're making a mistake

1083
00:50:49,480 --> 00:50:50,680
staying on ADO.

1084
00:50:50,680 --> 00:50:53,080
They explore migration and get spooked by the cost.

1085
00:50:53,080 --> 00:50:56,080
They're stuck in indecision because the binary framework broke

1086
00:50:56,080 --> 00:50:57,880
and they don't have a better framework yet.

1087
00:50:57,880 --> 00:50:58,880
You now do.

1088
00:50:58,880 --> 00:51:00,080
Here's how to use it.

1089
00:51:00,080 --> 00:51:01,680
Monday morning framework.

1090
00:51:01,680 --> 00:51:03,680
The first step is an honest classification

1091
00:51:03,680 --> 00:51:05,080
of what you actually own.

1092
00:51:05,080 --> 00:51:06,280
Not what you want to own.

1093
00:51:06,280 --> 00:51:07,680
Not what you think you should own.

1094
00:51:07,680 --> 00:51:09,080
What you actually own right now.

1095
00:51:09,080 --> 00:51:10,480
This inventory takes work.

1096
00:51:10,480 --> 00:51:11,880
And you need to know the details.

1097
00:51:11,880 --> 00:51:13,280
What repositories do you have?

1098
00:51:13,280 --> 00:51:14,080
Where do they live?

1099
00:51:14,080 --> 00:51:15,880
What do your pipelines actually do?

1100
00:51:15,880 --> 00:51:18,280
How deep is the integration with your legacy systems?

1101
00:51:18,280 --> 00:51:20,680
Which teams are locked into Azure boards or test plans?

1102
00:51:20,680 --> 00:51:23,280
Where is your governance actually enforced today?

1103
00:51:23,280 --> 00:51:25,480
You can't make a good decision without those answers.

1104
00:51:25,480 --> 00:51:28,080
But most organizations can't answer them from memory.

1105
00:51:28,080 --> 00:51:29,080
You have to count.

1106
00:51:29,080 --> 00:51:30,080
You have to look.

1107
00:51:30,080 --> 00:51:32,080
You have to understand exactly what you're carrying.

1108
00:51:32,080 --> 00:51:33,680
That inventory is your baseline.

1109
00:51:33,680 --> 00:51:35,680
From there, the framework gets mechanical.

1110
00:51:35,680 --> 00:51:38,480
For every major workload, you have to ask a few questions.

1111
00:51:38,480 --> 00:51:40,080
Is this new or legacy?

1112
00:51:40,080 --> 00:51:42,480
New workloads usually mean GitHub makes sense.

1113
00:51:42,480 --> 00:51:45,280
Legacy workloads mean Azure DevOps is the safer bet.

1114
00:51:45,280 --> 00:51:48,080
Unless you want to rebuild your governance from scratch.

1115
00:51:48,080 --> 00:51:49,080
Is this regulated?

1116
00:51:49,080 --> 00:51:51,680
High regulatory exposure points you toward Azure DevOps.

1117
00:51:51,680 --> 00:51:54,080
Low exposure means GitHub is probably fine.

1118
00:51:54,080 --> 00:51:55,280
If it's somewhere in the middle,

1119
00:51:55,280 --> 00:51:57,080
you need to think through the answer carefully.

1120
00:51:57,080 --> 00:51:58,880
Does the system talk to other systems?

1121
00:51:58,880 --> 00:52:00,680
Heavy integration with old infrastructure

1122
00:52:00,680 --> 00:52:01,880
suggests you stay with ADO.

1123
00:52:01,880 --> 00:52:03,680
You're already using those capabilities.

1124
00:52:03,680 --> 00:52:05,880
Lighter integration gives you more freedom to choose.

1125
00:52:05,880 --> 00:52:07,280
What is your primary constraint?

1126
00:52:07,280 --> 00:52:09,280
If you need velocity, GitHub helps.

1127
00:52:09,280 --> 00:52:11,480
If you need compliance, ADO was designed for it.

1128
00:52:11,480 --> 00:52:13,680
If you are honestly constrained by both.

1129
00:52:13,680 --> 00:52:14,880
Hybrid is the only answer.

1130
00:52:14,880 --> 00:52:16,280
What does the team look like?

1131
00:52:16,280 --> 00:52:18,880
Experience teams can usually operate in either environment.

1132
00:52:18,880 --> 00:52:22,680
Teams new to DevOps benefit from the structure ADO provides.

1133
00:52:22,680 --> 00:52:25,680
Cloud native teams usually want the lighter touch of GitHub.

1134
00:52:25,680 --> 00:52:27,080
These inputs aren't secrets.

1135
00:52:27,080 --> 00:52:29,080
Every CIO already has an opinion on them.

1136
00:52:29,080 --> 00:52:31,080
The framework just makes those opinions explicit

1137
00:52:31,080 --> 00:52:32,680
once you classify the workloads.

1138
00:52:32,680 --> 00:52:33,880
Allocation is easy.

1139
00:52:33,880 --> 00:52:36,680
GitHub for speed, Azure DevOps for compliance.

1140
00:52:36,680 --> 00:52:38,280
Hybrid for when you need both.

1141
00:52:38,280 --> 00:52:40,280
That allocation then determines everything else.

1142
00:52:40,280 --> 00:52:42,880
It sets your standards, it defines your integrations.

1143
00:52:42,880 --> 00:52:44,880
It builds your governance model.

1144
00:52:44,880 --> 00:52:46,880
The governance redesign.

1145
00:52:46,880 --> 00:52:48,680
Here's where most organizations stumble.

1146
00:52:48,680 --> 00:52:49,880
They get the allocation right.

1147
00:52:49,880 --> 00:52:51,480
They start moving the workloads.

1148
00:52:51,480 --> 00:52:54,080
And then they realize their governance model doesn't port over.

1149
00:52:54,080 --> 00:52:56,680
Azure boards has a specific way of organizing work.

1150
00:52:56,680 --> 00:52:58,280
Epic's roll-up into features.

1151
00:52:58,280 --> 00:52:59,480
Features roll-up into stories.

1152
00:52:59,480 --> 00:53:01,080
Stories roll-up into tasks.

1153
00:53:01,080 --> 00:53:01,880
There is hierarchy.

1154
00:53:01,880 --> 00:53:03,080
There is queryability.

1155
00:53:03,080 --> 00:53:05,280
There are custom fields and complex workflows.

1156
00:53:05,280 --> 00:53:07,880
You've probably spent years tuning how those boards look.

1157
00:53:07,880 --> 00:53:09,480
GitHub doesn't work that way.

1158
00:53:09,480 --> 00:53:11,280
GitHub has repositories and issues.

1159
00:53:11,280 --> 00:53:12,880
Issues have labels and milestones.

1160
00:53:12,880 --> 00:53:13,680
That's it.

1161
00:53:13,680 --> 00:53:14,880
There is no native hierarchy.

1162
00:53:14,880 --> 00:53:16,480
There is no Epic to task roll-up.

1163
00:53:16,480 --> 00:53:19,280
If you try to force your Azure boards model into GitHub,

1164
00:53:19,280 --> 00:53:20,680
you'll spend a year fighting the tool.

1165
00:53:20,680 --> 00:53:22,080
So the governance has to change.

1166
00:53:22,080 --> 00:53:23,680
Not just the tech, the structure.

1167
00:53:23,680 --> 00:53:26,080
For GitHub workloads, governance becomes lighter.

1168
00:53:26,080 --> 00:53:28,080
High-level planning stays in Azure boards.

1169
00:53:28,080 --> 00:53:29,480
That's your portfolio layer.

1170
00:53:29,480 --> 00:53:31,880
But the tactical work moves to GitHub issues.

1171
00:53:31,880 --> 00:53:34,080
Epic's become milestone groupings.

1172
00:53:34,080 --> 00:53:35,880
Features become GitHub projects.

1173
00:53:35,880 --> 00:53:36,880
Stories become issues.

1174
00:53:36,880 --> 00:53:38,280
The workflow is less formal.

1175
00:53:38,280 --> 00:53:39,680
And the gates are less rigid.

1176
00:53:39,680 --> 00:53:41,280
You are optimizing for speed.

1177
00:53:41,280 --> 00:53:44,280
For Azure DevOps workloads, governance stays formal.

1178
00:53:44,280 --> 00:53:45,480
The hierarchy remains.

1179
00:53:45,480 --> 00:53:46,680
The test plans stay.

1180
00:53:46,680 --> 00:53:49,480
The former release gates stay because in these environments.

1181
00:53:49,480 --> 00:53:51,080
Compliance isn't negotiable.

1182
00:53:51,080 --> 00:53:52,280
For hybrid workloads.

1183
00:53:52,280 --> 00:53:54,280
You keep the portfolio structure in boards.

1184
00:53:54,280 --> 00:53:56,480
That is your source of truth for business outcomes.

1185
00:53:56,480 --> 00:53:58,280
Individual features might live in GitHub.

1186
00:53:58,280 --> 00:54:01,080
But their relationship to the big picture flows through boards.

1187
00:54:01,080 --> 00:54:02,880
This is the redesign most people missed.

1188
00:54:02,880 --> 00:54:04,480
They assume governance is portable.

1189
00:54:04,480 --> 00:54:05,080
It's not.

1190
00:54:05,080 --> 00:54:06,280
Governance is structural.

1191
00:54:06,280 --> 00:54:08,280
It flows from the platform architecture.

1192
00:54:08,280 --> 00:54:11,080
When you change the platform, the governance changes with it.

1193
00:54:11,080 --> 00:54:14,080
The organizations that win treat this as a deliberate shift.

1194
00:54:14,080 --> 00:54:15,480
The governance council meets.

1195
00:54:15,480 --> 00:54:17,680
They map the old model against the new one.

1196
00:54:17,680 --> 00:54:19,080
They document the changes.

1197
00:54:19,080 --> 00:54:20,080
They train the teams.

1198
00:54:20,080 --> 00:54:21,080
And then they enforce it.

1199
00:54:21,080 --> 00:54:22,280
Governance doesn't go away.

1200
00:54:22,280 --> 00:54:23,880
It just becomes platform-appropriating.

1201
00:54:23,880 --> 00:54:26,080
You aren't trying to make GitHub work like Azure DevOps.

1202
00:54:26,080 --> 00:54:28,680
You're designing governance that works with the platform.

1203
00:54:28,680 --> 00:54:29,680
Not against it.

1204
00:54:29,680 --> 00:54:30,880
The integration pattern.

1205
00:54:30,880 --> 00:54:33,680
There is a specific moment in every hybrid journey

1206
00:54:33,680 --> 00:54:34,680
where the reality hits.

1207
00:54:34,680 --> 00:54:38,080
Organizations realize that integration is much harder than they expected.

1208
00:54:38,080 --> 00:54:39,880
You create a work item in GitHub.

1209
00:54:39,880 --> 00:54:41,280
It doesn't show up in Azure boards.

1210
00:54:41,280 --> 00:54:42,080
You push a commit.

1211
00:54:42,080 --> 00:54:43,280
It doesn't link back to ADO.

1212
00:54:43,280 --> 00:54:45,280
Changes in one system never reach the other.

1213
00:54:45,280 --> 00:54:46,880
Nothing happens automatically.

1214
00:54:46,880 --> 00:54:48,480
You have to build the connection yourself.

1215
00:54:48,480 --> 00:54:50,480
And building that connection takes real effort.

1216
00:54:50,480 --> 00:54:53,080
You can find third-party tools to handle parts of this.

1217
00:54:53,080 --> 00:54:55,080
There are services to sync work items and tools

1218
00:54:55,080 --> 00:54:56,480
to track commits across repositories.

1219
00:54:56,480 --> 00:54:58,280
But you will always run into custom work.

1220
00:54:58,280 --> 00:55:00,280
Every organization has slightly different needs.

1221
00:55:00,280 --> 00:55:02,480
The teams that actually win with hybrid

1222
00:55:02,480 --> 00:55:04,480
don't treat integration as a side effect.

1223
00:55:04,480 --> 00:55:06,880
They treat it as a deliberate architecture problem.

1224
00:55:06,880 --> 00:55:07,880
They build patterns.

1225
00:55:07,880 --> 00:55:10,280
They set naming conventions so linking actually works.

1226
00:55:10,280 --> 00:55:12,680
They build the automation that keeps everything in sync.

1227
00:55:12,680 --> 00:55:14,680
This is what that pattern looks like in practice.

1228
00:55:14,680 --> 00:55:16,480
A developer opens an issue in GitHub.

1229
00:55:16,480 --> 00:55:18,280
They tag that issue with a specific pattern

1230
00:55:18,280 --> 00:55:21,680
like org project 001 to make it discoverable.

1231
00:55:21,680 --> 00:55:23,880
That naming convention allows your automation

1232
00:55:23,880 --> 00:55:27,080
to find the issue and link it to the right Azure boards item.

1233
00:55:27,080 --> 00:55:28,880
You have to build that automation on purpose.

1234
00:55:28,880 --> 00:55:30,880
It isn't a one-off fix for a single team.

1235
00:55:30,880 --> 00:55:34,280
It is a standard that applies to every repository and every person.

1236
00:55:34,280 --> 00:55:37,080
If your integration isn't a standard, it fragments.

1237
00:55:37,080 --> 00:55:38,880
Teams start doing things their own way.

1238
00:55:38,880 --> 00:55:39,680
The links fail.

1239
00:55:39,680 --> 00:55:41,880
And that is exactly where the hybrid model breaks.

1240
00:55:41,880 --> 00:55:43,680
The same logic applies to your pipelines.

1241
00:55:43,680 --> 00:55:45,480
You might run GitHub actions for fast testing

1242
00:55:45,480 --> 00:55:47,480
and Azure pipelines for formal releases.

1243
00:55:47,480 --> 00:55:48,880
Those systems have to talk.

1244
00:55:48,880 --> 00:55:51,680
GitHub actions must be able to trigger Azure pipelines.

1245
00:55:51,680 --> 00:55:53,680
Azure pipelines must be able to pull outputs

1246
00:55:53,680 --> 00:55:55,480
from GitHub and use them as inputs.

1247
00:55:55,480 --> 00:55:56,480
None of that is automatic.

1248
00:55:56,480 --> 00:55:57,480
It is deliberate work.

1249
00:55:57,480 --> 00:56:00,280
High performing organizations usually set up a platform team

1250
00:56:00,280 --> 00:56:01,280
to own this layer.

1251
00:56:01,280 --> 00:56:03,280
This team is separate from your product teams.

1252
00:56:03,280 --> 00:56:06,280
Their entire job is to build and maintain the integrations

1253
00:56:06,280 --> 00:56:07,480
that hold the system together.

1254
00:56:07,480 --> 00:56:08,680
They create the templates.

1255
00:56:08,680 --> 00:56:10,280
They embed the naming conventions.

1256
00:56:10,280 --> 00:56:11,480
They build the automation.

1257
00:56:11,480 --> 00:56:14,080
And when a link breaks, they are the ones who fix it.

1258
00:56:14,080 --> 00:56:15,680
This is not a small or optional role.

1259
00:56:15,680 --> 00:56:18,880
In a large organization, this team might be five people or more.

1260
00:56:18,880 --> 00:56:21,080
They are the only reason the hybrid model doesn't collapse

1261
00:56:21,080 --> 00:56:23,080
under its own weight.

1262
00:56:23,080 --> 00:56:24,280
The measurement regime.

1263
00:56:24,280 --> 00:56:26,280
You cannot manage what you do not measure.

1264
00:56:26,280 --> 00:56:28,280
Hybrid setups add layers of complexity

1265
00:56:28,280 --> 00:56:29,880
and you need data to navigate them.

1266
00:56:29,880 --> 00:56:32,480
Your standard DevOps metrics have to span both platforms.

1267
00:56:32,480 --> 00:56:34,480
You need to see door metrics, cycle time

1268
00:56:34,480 --> 00:56:36,480
and deployment frequency in one place.

1269
00:56:36,480 --> 00:56:39,680
You cannot look at GitHub and Azure DevOps as two separate islands.

1270
00:56:39,680 --> 00:56:40,880
You need a unified view.

1271
00:56:40,880 --> 00:56:42,280
But this is harder than it sounds.

1272
00:56:42,280 --> 00:56:45,080
The two platforms do not report data in the same way.

1273
00:56:45,080 --> 00:56:47,080
GitHub lacks native test metrics

1274
00:56:47,080 --> 00:56:49,680
while Azure DevOps lacks native security metrics.

1275
00:56:49,680 --> 00:56:50,680
To see the full picture,

1276
00:56:50,680 --> 00:56:52,080
you have to build your own dashboards

1277
00:56:52,080 --> 00:56:53,680
to bring that data together.

1278
00:56:53,680 --> 00:56:55,280
The real challenge isn't technical.

1279
00:56:55,280 --> 00:56:56,080
It's strategic.

1280
00:56:56,080 --> 00:56:58,880
You have to measure if your original decisions were actually right.

1281
00:56:58,880 --> 00:57:01,880
Are the workloads you move to GitHub actually moving faster?

1282
00:57:01,880 --> 00:57:05,080
Are the teams on Azure DevOps actually maintaining better compliance?

1283
00:57:05,080 --> 00:57:07,880
Is the hybrid model delivering the balance you expected?

1284
00:57:07,880 --> 00:57:10,280
If a GitHub project is failing its compliance checks,

1285
00:57:10,280 --> 00:57:12,280
you need to know that immediately.

1286
00:57:12,280 --> 00:57:14,880
It might mean you put the wrong workload in the wrong place.

1287
00:57:14,880 --> 00:57:16,880
Or maybe the team just needs more structure.

1288
00:57:16,880 --> 00:57:18,880
Either way, the data tells you there is a problem.

1289
00:57:18,880 --> 00:57:20,680
If an Azure DevOps project is crawling

1290
00:57:20,680 --> 00:57:21,880
because of governance overhead,

1291
00:57:21,880 --> 00:57:24,080
the data tells you if that trade-off is worth it.

1292
00:57:24,080 --> 00:57:25,680
Maybe the slowness is acceptable.

1293
00:57:25,680 --> 00:57:26,480
Maybe it isn't.

1294
00:57:26,480 --> 00:57:28,480
But you need the numbers to make that call.

1295
00:57:28,480 --> 00:57:30,080
The best setups I have seen.

1296
00:57:30,080 --> 00:57:31,280
Use a monthly review.

1297
00:57:31,280 --> 00:57:33,480
The platform team pulls metrics from both systems

1298
00:57:33,480 --> 00:57:35,080
and compares them to the baseline.

1299
00:57:35,080 --> 00:57:36,080
They look for anomalies.

1300
00:57:36,080 --> 00:57:37,280
They investigate the gaps.

1301
00:57:37,280 --> 00:57:39,480
Then they make recommendations on where to move workloads

1302
00:57:39,480 --> 00:57:41,080
or how to change the process.

1303
00:57:41,080 --> 00:57:43,680
This review is how the hybrid model actually learns.

1304
00:57:43,680 --> 00:57:45,080
You stop guessing about what works.

1305
00:57:45,080 --> 00:57:46,080
You measure it.

1306
00:57:46,080 --> 00:57:48,080
And then you adjust based on the evidence.

1307
00:57:48,080 --> 00:57:49,080
The three-year outlook.

1308
00:57:49,080 --> 00:57:51,080
I want to share what I'm confident will happen

1309
00:57:51,080 --> 00:57:52,080
over the next three years.

1310
00:57:52,080 --> 00:57:53,480
The trajectory is clear.

1311
00:57:53,480 --> 00:57:56,280
Organizations that haven't made a platform decision yet

1312
00:57:56,280 --> 00:57:57,480
will finally make one.

1313
00:57:57,480 --> 00:57:59,680
You won't be able to avoid the question forever.

1314
00:57:59,680 --> 00:58:01,880
At some point you have to commit to an architecture.

1315
00:58:01,880 --> 00:58:04,480
Most of those organizations will adopt the hybrid model.

1316
00:58:04,480 --> 00:58:05,880
Not because it's perfect,

1317
00:58:05,880 --> 00:58:08,880
but because it's the least bad option given their constraints.

1318
00:58:08,880 --> 00:58:11,480
They'll keep Azure DevOps for governance-heavy workloads,

1319
00:58:11,480 --> 00:58:13,480
move to GitHub for innovation workloads,

1320
00:58:13,480 --> 00:58:15,280
and build the integration between them.

1321
00:58:15,280 --> 00:58:17,680
The organizations that go all in on one platform,

1322
00:58:17,680 --> 00:58:20,080
either pure GitHub or staying on pure ADO,

1323
00:58:20,080 --> 00:58:22,080
will represent the extremes.

1324
00:58:22,080 --> 00:58:24,880
GitHub only will be early stage cloud-native organizations

1325
00:58:24,880 --> 00:58:26,280
with low regulatory burden.

1326
00:58:26,280 --> 00:58:29,080
ADO only will be legacy-heavy organizations

1327
00:58:29,080 --> 00:58:30,480
in highly regulated industries

1328
00:58:30,480 --> 00:58:32,480
that can't afford to fragment their governance.

1329
00:58:32,480 --> 00:58:34,680
The middle, which is most of the Fortune 500,

1330
00:58:34,680 --> 00:58:37,080
will be hybrid.compliance requirements will get tighter.

1331
00:58:37,080 --> 00:58:39,480
The EU AI Act is just the opening move.

1332
00:58:39,480 --> 00:58:40,680
Other countries will follow.

1333
00:58:40,680 --> 00:58:42,480
International harmonization is coming.

1334
00:58:42,480 --> 00:58:44,280
And every regulation that gets added

1335
00:58:44,280 --> 00:58:45,880
will make governance more important,

1336
00:58:45,880 --> 00:58:47,680
which makes Azure DevOps more valuable

1337
00:58:47,680 --> 00:58:49,280
for the workloads that require it.

1338
00:58:49,280 --> 00:58:51,680
Meanwhile, AI capabilities will keep advancing.

1339
00:58:51,680 --> 00:58:54,880
GitHub's competitive advantage will be in AI-assisted development.

1340
00:58:54,880 --> 00:58:56,480
Organizations will want that advantage

1341
00:58:56,480 --> 00:58:57,880
for their innovation workloads,

1342
00:58:57,880 --> 00:58:59,480
so they'll use GitHub for those.

1343
00:58:59,480 --> 00:59:01,480
And they'll use Azure DevOps for the workloads

1344
00:59:01,480 --> 00:59:03,680
where compliance matters more than velocity.

1345
00:59:03,680 --> 00:59:05,680
The integration between GitHub and Azure DevOps

1346
00:59:05,680 --> 00:59:08,880
will improve, not to the point where they feel like one platform,

1347
00:59:08,880 --> 00:59:10,480
but to the point where a hybrid setup

1348
00:59:10,480 --> 00:59:12,480
feels like a deliberate architectural choice,

1349
00:59:12,480 --> 00:59:13,480
not a messy compromise.

1350
00:59:13,480 --> 00:59:15,080
Platform teams will become standard.

1351
00:59:15,080 --> 00:59:17,080
Right now, they're emerging.

1352
00:59:17,080 --> 00:59:18,880
In three years, most large organizations

1353
00:59:18,880 --> 00:59:20,480
will have a dedicated platform team

1354
00:59:20,480 --> 00:59:22,080
responsible for managing their GitHub

1355
00:59:22,080 --> 00:59:23,880
and Azure DevOps footprint,

1356
00:59:23,880 --> 00:59:26,880
and the integration between them.

1357
00:59:26,880 --> 00:59:28,280
The implementation roadmap.

1358
00:59:28,280 --> 00:59:30,880
If you've decided hybrid is right for your organization,

1359
00:59:30,880 --> 00:59:31,880
and you're probably correct

1360
00:59:31,880 --> 00:59:33,880
if you're Fortune 500 or close to it,

1361
00:59:33,880 --> 00:59:35,080
here's the roadmap.

1362
00:59:35,080 --> 00:59:36,680
Phase one, the audit.

1363
00:59:36,680 --> 00:59:38,680
This happens in months one through three.

1364
00:59:38,680 --> 00:59:40,480
Do the honest inventory I mentioned earlier,

1365
00:59:40,480 --> 00:59:42,680
count your repositories, count your pipelines,

1366
00:59:42,680 --> 00:59:44,680
understand your boards and test plans usage,

1367
00:59:44,680 --> 00:59:46,080
measure your current governance,

1368
00:59:46,080 --> 00:59:48,680
understand your regulatory requirements by workload.

1369
00:59:48,680 --> 00:59:50,480
This phase is boring.

1370
00:59:50,480 --> 00:59:53,080
It's also essential because you can't make good decisions

1371
00:59:53,080 --> 00:59:55,080
without accurate data.

1372
00:59:55,080 --> 00:59:57,080
Phase two, the classification.

1373
00:59:57,080 --> 00:59:59,080
This happens in months two through four.

1374
00:59:59,080 --> 01:00:01,280
Classify workloads using the decision framework,

1375
01:00:01,280 --> 01:00:02,880
not all at once.

1376
01:00:02,880 --> 01:00:05,080
Start with the major application families.

1377
01:00:05,080 --> 01:00:07,080
Understand which characteristics matter most.

1378
01:00:07,080 --> 01:00:08,480
Document your reasoning.

1379
01:00:08,480 --> 01:00:09,880
Don't try to be perfect.

1380
01:00:09,880 --> 01:00:10,880
You'll be wrong about some.

1381
01:00:10,880 --> 01:00:11,680
That's okay.

1382
01:00:11,680 --> 01:00:13,280
You'll learn as you go.

1383
01:00:13,280 --> 01:00:14,880
Phase three, the pilot.

1384
01:00:14,880 --> 01:00:16,680
This happens in months four through eight.

1385
01:00:16,680 --> 01:00:18,880
Pick one low-risk Greenfield project.

1386
01:00:18,880 --> 01:00:20,880
Move it to GitHub following your integration pattern

1387
01:00:20,880 --> 01:00:22,080
and governance model.

1388
01:00:22,080 --> 01:00:24,080
Run it for three to six months in production.

1389
01:00:24,080 --> 01:00:25,680
Document everything that broke.

1390
01:00:25,680 --> 01:00:27,680
Document what worked better than expected.

1391
01:00:27,680 --> 01:00:29,680
Document the integration issues you hit.

1392
01:00:29,680 --> 01:00:31,080
And the team dynamics.

1393
01:00:31,080 --> 01:00:34,880
This pilot teaches you more than all the planning in the world.

1394
01:00:34,880 --> 01:00:36,080
Phase four, the scale.

1395
01:00:36,080 --> 01:00:38,280
This happens in months eight through eighteen.

1396
01:00:38,280 --> 01:00:40,280
Based on the pilot, refine your patterns.

1397
01:00:40,280 --> 01:00:42,080
Then start rolling out to other workloads.

1398
01:00:42,080 --> 01:00:43,280
Don't move everything at once.

1399
01:00:43,280 --> 01:00:44,080
Move in cohorts.

1400
01:00:44,080 --> 01:00:45,680
Let each cohort teach you something.

1401
01:00:45,680 --> 01:00:47,880
Keep Azure DevOps and GitHub running in parallel

1402
01:00:47,880 --> 01:00:48,680
during this phase.

1403
01:00:48,680 --> 01:00:50,880
The duplication is expensive.

1404
01:00:50,880 --> 01:00:53,480
It's also necessary for safety.

1405
01:00:53,480 --> 01:00:55,480
Phase five, the stabilization.

1406
01:00:55,480 --> 01:00:57,880
This happens in months eighteen through twenty four.

1407
01:00:57,880 --> 01:01:00,080
By this point, you've moved significant workloads.

1408
01:01:00,080 --> 01:01:01,480
You've built integration patterns.

1409
01:01:01,480 --> 01:01:03,480
You've solved most of the integration problems.

1410
01:01:03,480 --> 01:01:04,480
Now you optimize.

1411
01:01:04,480 --> 01:01:06,680
This is where you actually decommission Azure DevOps

1412
01:01:06,680 --> 01:01:08,480
for the workloads that have fully moved.

1413
01:01:08,480 --> 01:01:10,080
You keep it for the workloads that needed.

1414
01:01:10,080 --> 01:01:12,880
You might reduce your ADO footprint by 30 to 40%.

1415
01:01:12,880 --> 01:01:17,280
But you're unlikely to get to zero if you're regulated at all.

1416
01:01:17,280 --> 01:01:19,480
Phase six, the continuous improvement.

1417
01:01:19,480 --> 01:01:21,080
This is year two and beyond.

1418
01:01:21,080 --> 01:01:23,080
You're now running hybrid.

1419
01:01:23,080 --> 01:01:24,680
The platform team takes over.

1420
01:01:24,680 --> 01:01:25,880
The monthly reviews start.

1421
01:01:25,880 --> 01:01:27,680
The measurement regime operates.

1422
01:01:27,680 --> 01:01:29,480
You adjust allocations based on evidence.

1423
01:01:29,480 --> 01:01:31,080
This is the operational mode.

1424
01:01:31,080 --> 01:01:31,880
It's not dramatic.

1425
01:01:31,880 --> 01:01:33,480
It's not about big migrations.

1426
01:01:33,480 --> 01:01:36,080
It's about managing a complex platform portfolio

1427
01:01:36,080 --> 01:01:37,280
and optimizing outcomes.

1428
01:01:37,280 --> 01:01:38,680
This roadmap takes two years.

1429
01:01:38,680 --> 01:01:39,680
It's not fast.

1430
01:01:39,680 --> 01:01:42,080
But it's a realistic timeline for a large organization

1431
01:01:42,080 --> 01:01:44,880
to move significant workloads without breaking production

1432
01:01:44,880 --> 01:01:46,280
without losing compliance.

1433
01:01:46,280 --> 01:01:49,080
And without triggering a twenty eight percent cost speak.

1434
01:01:49,080 --> 01:01:51,080
The real conversation you should be having.

1435
01:01:51,080 --> 01:01:53,680
If a CIO asked me about this tomorrow.

1436
01:01:53,680 --> 01:01:54,880
Here's what I would tell them.

1437
01:01:54,880 --> 01:01:56,080
You aren't going to pick one.

1438
01:01:56,080 --> 01:01:57,480
You probably know that already.

1439
01:01:57,480 --> 01:01:59,280
Even if you haven't admitted it yet.

1440
01:01:59,280 --> 01:02:00,480
The economics don't work.

1441
01:02:00,480 --> 01:02:01,680
The compliance doesn't work.

1442
01:02:01,680 --> 01:02:03,280
The innovation requirements don't work.

1443
01:02:03,280 --> 01:02:05,480
So stop planning as if you're going to pick a winner.

1444
01:02:05,480 --> 01:02:07,680
Instead plan how you'll operate both.

1445
01:02:07,680 --> 01:02:09,680
Design governance that works in two places.

1446
01:02:09,680 --> 01:02:11,480
Build the integration that connects them.

1447
01:02:11,480 --> 01:02:14,080
Set up a platform team to manage that complexity.

1448
01:02:14,080 --> 01:02:17,680
Then measure the outcomes to see if your allocation is actually right.

1449
01:02:17,680 --> 01:02:18,480
It sounds boring.

1450
01:02:18,480 --> 01:02:19,480
But boring isn't wrong.

1451
01:02:19,480 --> 01:02:21,280
The organization is moving the fastest.

1452
01:02:21,280 --> 01:02:23,880
Other ones accepting this complexity instead of fighting it.

1453
01:02:23,880 --> 01:02:25,880
They aren't looking for the one true platform.

1454
01:02:25,880 --> 01:02:27,480
They aren't debating which one is better.

1455
01:02:27,480 --> 01:02:29,880
They're answering the actual strategic question.

1456
01:02:29,880 --> 01:02:32,080
Which workloads live where and how do we govern them?

1457
01:02:32,080 --> 01:02:33,080
That's a different conversation.

1458
01:02:33,080 --> 01:02:33,880
It's practical.

1459
01:02:33,880 --> 01:02:35,680
It's less exciting for the industry narrative.

1460
01:02:35,680 --> 01:02:37,480
But it's the only conversation that matters.

1461
01:02:37,480 --> 01:02:40,480
You're going to use both GitHub for your innovation agenda.

1462
01:02:40,480 --> 01:02:42,280
Azure DevOps for your compliance agenda.

1463
01:02:42,280 --> 01:02:43,880
And integration to make them talk.

1464
01:02:43,880 --> 01:02:45,480
The question isn't whether you'll do it.

1465
01:02:45,480 --> 01:02:46,880
The question is how well you'll do it.

1466
01:02:46,880 --> 01:02:48,680
That's where the advantage actually lies.