Case Study · Cloud / Azure

Establishing an Azure Landing Zone for Cloud Adoption

Context

A growing healthcare technology firm was preparing to move development, QA, and engineering workloads into Microsoft Azure. They already had a handful of subscriptions in use by IT and engineering — but no governed foundation underneath them. With multiple application teams about to begin cloud-first builds, leadership recognized the need for a single landing zone rather than letting each team provision ad hoc and accumulate technical debt.

This was 2022 — before Microsoft's Azure Landing Zone accelerator and the packaged Cloud Adoption Framework reference architectures became widely standardized in their current form. The governance patterns, subscription strategy, and Terraform automation had to be designed from foundational principles rather than adapted from a template.

Challenge

The organization needed a production-ready Azure environment that met enterprise governance, compliance, and security baselines from day one; could scale to support multiple parallel application teams without coordination overhead; eliminated the operational risk of ad hoc cloud deployments; and provided a repeatable, automated framework future engineers could extend without reinventing structure.

Approach

The engagement was structured as a hybrid project — predictive at the stage-gate level (compliance checkpoints, scope sign-offs) and agile within each delivery sprint (two-week iterations, weekly standups, backlog in Azure DevOps).

• Multi-subscription architecture. A four-subscription topology (Development, Sandbox, Dev-Production, IT-Production), each with its own access policies and resource boundaries for clean workload separation and cost allocation.
• Infrastructure-as-Code. The entire landing zone in Terraform with Azure DevOps Pipelines for CI/CD. Every component — networks, subscriptions, role assignments, policies — code-managed and peer-reviewed via pull request before any deployment touched a live environment.
• Identity and access. Identity federation between on-premises Active Directory and Azure AD, with RBAC and Conditional Access aligned to the company's security model.
• Governance. Azure Policy enforcement at the management group level — naming, tagging, allowed regions, resource types. Initial controls focused on diagnostic enforcement, with the framework designed to expand into tighter deny-mode guardrails as adoption matured.

Project Leadership

Beyond the technical delivery, I owned project coordination end-to-end — running cadence with executive leadership, the internal engineering team, and an external contractor; balancing technical work against governance requirements; and absorbing scope growth without extending the timeline. The PM work ran in parallel with my day-to-day operational responsibilities for the company's existing Azure footprint.

• Three-tier stakeholder cadence: weekly executive sponsor check-ins, monthly engineering status, monthly contractor syncs.
• Cross-functional coordination across internal IT, internal engineering, and a fractional external contractor — without a dedicated full-time PM.
• Scope absorbed, timeline held: mid-engagement identity-federation and automation additions delivered within the original window.
• Risk surfaced and triaged through documented root-cause analysis rather than ad hoc firefighting.
• Handoff designed from day one — SOPs, recorded walkthroughs, and paired sessions built throughout.

Outcome

Delivered at engagement close:

• Standardized governance across four Azure subscriptions
• 100% of foundational infrastructure under Terraform management
• Framework ready for future workload onboarding within the governed subscription boundary

Foundational infrastructure and governance moved to code — subscriptions, networks, identity federation, RBAC, security baselines, and Azure Policy all Terraform-managed and peer-reviewed. Governance was enforced at the policy layer rather than by hand, and the platform was documented thoroughly enough to be maintained independent of the original implementer.

Business Impact

• A repeatable Azure foundation any future workload could adopt without reinventing structure
• Governance codified, not improvised — security and compliance posture lives in the repository, not tribal knowledge
• Operational independence — the framework didn't depend on its original implementer
• A defensible audit trail — every infrastructure change a peer-reviewed pull request with full history

Tech & Tools

Microsoft Azure (multi-subscription) · Azure AD / identity federation · Terraform · Azure DevOps (Repos, Pipelines, Boards) · Azure Policy · Azure Monitor · RBAC / Conditional Access