Zohaib Khan
I build the pipelines and platforms that let teams ship without friction — and before I move anything, I measure it. Recently led discovery for moving a 70+ project Azure DevOps estate to GitHub at an enterprise software group.
How I work
I'm a DevOps engineer at Contour Software · Constellation Dealer Group, working across Azure DevOps, .NET and React applications, and a deep stack of legacy desktop products. My day-to-day is build pipelines, deployment architecture, DevSecOps, and least-privilege access — the unglamorous plumbing that decides whether a release is calm or chaotic.
The thing I'm known for is rigor. I don't guess at scope. When the org asked whether we could move from Azure DevOps to GitHub, I didn't write an opinion — I pulled live data through an MCP server and the Release Management REST API and produced a measured baseline down to the individual classic release definition.
I'm now transitioning toward Platform Engineering: treating internal tooling as a product, reducing toil for the teams around me, and building the paved roads that make the right thing the easy thing. Longer term, I care deeply about AI safety, interpretability, and alignment.
- Current focus
- Azure DevOps → GitHub migration · platform tooling · DevSecOps
- Stack
- Azure, GitHub Actions, Kubernetes, Docker, .NET Core, PowerShell, Bicep/ARM
- Certifications
- Kubestronaut (CKA · CKAD · CKS · KCNA · KCSA) · Azure DevOps Engineer Expert · AZ-305 · AZ-104 · ISC2 CC
- Education
- Associate degree, B.Com
- Values
- Measure first. Least privilege. Reduce toil. Honest feedback over reassurance.
Featured case study
Measuring a 70+ project estate before moving a single repo
You cannot plan, price, or sequence a migration you haven't measured.
So I built the measured baseline — live data, not assumptions — that every downstream phasing and cost decision now derives from.
What I found
- ~85%of the effort sits in one project. Reframed the program from “migrate 70+ projects” to “migrate one well.”
- 100+classic Release definitions — a previously invisible workstream, surfaced via the Release Management REST API that the MCP server couldn't reach. Every live one is a hand-rebuild.
- ~95%of build pipelines are YAML and port mechanically. Only a handful of classic builds need rebuilding. Good news, made legible.
- 200+branch policies mapped to GitHub rulesets — flagging the work-item-linking policies with no native equivalent.
Effort concentration
Rebuild dependencies, counted
- →Service connections inventoried and planned onto OIDC federation
- 100+service hooks / webhooks to re-point
- →Self-hosted agent pools mapped to GitHub runners
Snyk SAST in CI/CD
Integrated DevSecOps static analysis across multiple pipelines — policy files, org-slug config, token scoping — in collaboration with the security team.
@claude ADO bot
Designed a phased architecture (Azure Function → MCP → Logic Apps) for a PR & work-item bot with async Service Bus processing and App Insights logging.
Release-date stamping
PowerShell pipeline stamping release dates onto ADO work items via WIQL — extended to cover both Defect and Bug types on request.