Case study Enterprise engagement

Brownfield Azure infrastructure modernization and IaC baseline

A live enterprise Azure environment, grown through years of portal and provider driven change, reconstructed into a faithful Bicep baseline, and proven by Azure What-If to introduce no unintended change at all.

Role: Technical workstream owner
Client: Global Enterprise Client
Year: 2026
Platform: Azure and Azure DevOps

Context

The environment was brownfield in the full sense: years of manual, portal driven and provider driven change layered onto each other, with the existing code no longer an authoritative description of what was actually deployed. The estate spanned 50+ resources across 25+ resource types: App Services and Functions, API Management, Event Hub, Redis, Storage, networking with Private Endpoints, Automation, and the Azure Monitor, Log Analytics and Application Insights footprint around all of it.

The objective was deliberately not to redesign any of it. It was to understand what existed, reconstruct the current state accurately, codify the manageable baseline in Bicep, and keep a hard line between recording reality and improving it.

The problem

Codifying a live environment is only safe if the codification itself changes nothing. A baseline that quietly corrects things while recording them is not a baseline, it is an unreviewed deployment. So the acceptance criterion was written down before the work started: the final composed Azure What-If for the managed baseline had to report zero unintended Create, Modify or Delete operations.

My role

I owned the technical workstream, on the Infrastructure and Security team at Dev4Side Software: the discovery, the classification, the Bicep architecture, the validation, and the design of the delivery workflow around it.

The approach

Evidence first. The reconstruction was read out of Azure Resource Manager, resource by resource, not out of documentation or memory.
Classification before code. Every resource was judged for IaC suitability and sorted: managed in the baseline, provider managed, portal managed, recovery only, or explicitly excluded, with each exception documented as a decision rather than left as a gap.
Modular Bicep for the 40+ resources that belong in the baseline, absorbing the ARM and provider normalization edge cases, the properties providers rewrite, the defaults that only appear after deployment, the locks, so the code and the platform agree on what no change means.
Convergence as the test. The baseline was iterated against Azure What-If until the composed result reported nothing unintended, turning idempotency from a claim into a property you can demonstrate.

The delivery workflow

The Azure DevOps workflow around the baseline was designed to enforce production-safe change management rather than assume it: five stages, with a person and a second opinion standing between a plan and its execution.

01Validate
02What-If
03Approval
04Deploy
05Post-deploy What-If

One immutable build artifact. The templates that were validated and reviewed are, byte for byte, the templates that deploy.
The identity that plans is not the identity that deploys. Planning and deployment run under separate identities with least-privilege permissions, so the credential that predicts a change cannot make one.
Environments promote serially, never independently, and a second What-If after deployment closes the loop by proving the environment converged on the code.
The pipeline earned its trust: 150+ offline and automated validation tests exercised it during hardening.

Key decisions

Decision 01

Baseline first, remediation later

The code records the environment as it is, imperfections included. Anything worth improving becomes a reviewed, visible diff on top of a faithful baseline, instead of a side effect smuggled into the act of writing things down.

Decision 02

Not everything belongs in code

Provider managed, portal managed and recovery only resources were kept out of the managed baseline explicitly, and the reasons were written down. A baseline that pretends to own what it cannot manage fails in the worst way: silently, at deploy time.

Decision 03

Zero What-If drift is the definition of done

The baseline was not finished when it compiled, and not finished when it deployed. It was finished when the composed What-If reported zero unintended operations, which is the strongest statement a brownfield codification can truthfully make.

Decision 04

Blast radius shapes the pipeline

Approval gates, separated plan and deploy identities, least privilege and serial promotion all exist for the same reason: a wrong plan must be caught while it is still a plan.

Scope and results

Analyzed: 50+Azure resources across 25+ resource types
Codified: 40+resources represented in the managed Bicep baseline
Unintended changes: ZeroCreate, Modify or Delete operations in the final composed What-If
Pipeline hardening: 150+offline and automated validation tests

Technology

Platform: Azure · Bicep · ARM
Delivery: Azure DevOps · PowerShell · Entra ID · Azure RBAC
Estate: App Services · Functions · API Management · Event Hub · Redis · Storage · Monitor · Log Analytics · Application Insights · Private Endpoints · Automation

Case study note. This work was delivered for an enterprise client under NDA, referred to here only as a Global Enterprise Client. Names, identifiers, internal architecture and anything that could reasonably identify the environment have been removed. The engineering, the constraints and the numbers are real, stated as sanitized ranges.