Zohaib Khan
I build the pipelines and platforms that let teams ship without friction — and before I move anything, I measure it. Currently mapping a ~75-project Azure DevOps estate to GitHub for an enterprise dealer-systems 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
- 50+ — incl. CKA, CKAD, Azure DevOps Engineer Expert
- Education
- BSc Computer Science, Virtual University
- Values
- Measure first. Least privilege. Reduce toil. Honest feedback over reassurance.
Featured case study
Measuring a 75-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 entire effort lives in one project — “Ideal” (132 repos, 51 teams, 68,324 work items). Reframed the program from “migrate 75 projects” to “migrate one well.”
- 146classic Release definitions — a previously-invisible workstream, surfaced via the Release Management REST API the MCP server couldn't reach. 89 live, all hand-rebuilds.
- ~95%of build pipelines are YAML — porting mechanically. Only ~10 classic builds need rebuilding. Good news, made legible.
- 221branch policies mapped to GitHub rulesets — flagging the 36 work-item-linking policies with no native equivalent.
Effort concentration
Rebuild dependencies, counted
- 23service connections — 14 secret-based to rotate, 5 already on OIDC
- 136service hooks / webhooks to re-point
- 44self-hosted agents in one pool to re-home as 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.
Toolchain
Cloud / Azure 07
CI/CD 06
Containers 05
Languages 05
DevSecOps 04
Data / Platform 05
Certifications
⚙ To add the rest: append objects to the
certs array in this file — name, issuer, category. No build step.
Let's build the paved road.
Open to Platform & DevOps engineering conversations. The fastest way to reach me is email or LinkedIn.