Your Azure landing zone is deployed. Identity and network boundaries are established, policies are assigned, shared services are running, and workload teams have a governed place to build. That is a substantial milestone. It is also the point where the next question becomes practical: how will teams use this foundation to deliver and operate applications?
This roadmap focuses on platform maturity for cloud workloads generally. For the additional identity, data, model and agent controls needed by production AI, see From Cloud Landing Zones to AI Landing Zones.
A landing zone is not the destination or a one-time infrastructure project. It is the foundation for workloads and the platform capabilities that support them. If every new workload still depends on manual subscription setup, hand-built pipelines, bespoke Kubernetes clusters or reactive monitoring, the organization has a secure starting point but has not yet made delivery repeatable.
A useful progression is Landing Zone → IaC Standardization → CI/CD → Developer Self-Service → Application Platforms → Observability → AI Workloads. These steps form an iterative roadmap rather than a mandatory sequence: observability and security should begin early, and specific needs may justify moving capabilities forward or building them in parallel.
1. Turn the landing zone into a maintained baseline
First, confirm what “finished” means for your organization. A platform landing zone provides shared governance, security and services; workload or application landing zones provide the environments where teams deploy and operate their applications. Document the boundaries, ownership, support model, policy exceptions and process for creating new workload environments.
Review the foundation as a living system. Policies change, cloud services evolve, security expectations increase and new workload requirements emerge. Microsoft’s Azure landing zone guidance distinguishes the centralized platform foundation from workload landing zones, while its guidance on keeping a landing zone up to date describes ongoing updates as part of operating it.
2. Standardize IaC so environments stay consistent
Move recurring infrastructure changes into versioned Terraform or Bicep modules and deploy them through reviewed pipelines. Standardize the patterns teams repeat—network integration, identity, logging, policy assignments, application environments and cost ownership. Define how changes are tested, promoted and rolled back, and make out-of-band changes visible.
The goal is not a large library of abstractions before there are users. Start with the infrastructure requests teams repeat, then make the supported modules and inputs easy to find. Microsoft’s IaC guidance for Azure landing zones describes version control, pipeline-based deployment, reviewable changes and drift management.
3. Connect infrastructure changes to CI/CD
Workload teams need a reliable path to build, test and release application changes. Establish reusable pipeline patterns for code validation, security checks, artifact publication and deployment promotion. Integrate infrastructure changes with the same review and release discipline, while keeping privileges separated between preview and production apply operations.
A governed pipeline reduces variation and gives teams a known route to production. It should also provide actionable output: what changed, which checks passed, who approved a protected deployment and where to find release or rollback guidance. The Azure Cloud Adoption Framework recommends governed pipelines and production review gates for landing-zone IaC updates.
4. Make common cloud tasks self-service
As adoption grows, manual requests to create subscriptions, environments and standard resources become a queue. Build a controlled self-service or near-self-service process for common requests. A team should be able to select the appropriate workload pattern, supply a small set of business and technical details, and receive an environment with the right governance and ownership already attached.
Subscription vending is one example: platform automation provisions and governs a workload subscription based on an approved product line, then the application team deploys its workload. Self-service does not mean removing guardrails; it means putting the guardrails into the path so routine work does not require repeated manual coordination. See Microsoft’s subscription vending implementation guidance. The Engineering Library’s How to Build a Platform Engineering Golden Path shows how to extend this model to repeatable workload delivery.
5. Provide the right application platform
Some teams need a straightforward managed application service. Others need container hosting, a Kubernetes platform or a specialized data and AI environment. Offer supported application platforms based on workload needs, team skills, reliability requirements and operating cost—not because a particular technology is fashionable.
For Kubernetes, that includes clear ownership of the cluster lifecycle, upgrades, identity, network policy, workload isolation, observability and developer deployment experience. Platform teams can operate shared components while workload teams own their applications, provided the boundaries and responsibilities are explicit. A well-designed application platform should make the routine path easier without hiding the information teams need to troubleshoot and operate their service.
6. Add observability as an operating feedback loop
Teams need to see how applications and their dependencies behave in real conditions. Establish common instrumentation, useful logs, metrics and traces, service health signals, actionable alerts and incident paths. Start with the questions teams need to answer: is the service healthy, where is time being spent, what changed, and which users or business outcomes are affected?
Observability supports operational response as well as future investment decisions. Use the evidence to identify recurring reliability gaps, slow deployments, expensive dependencies or poor developer experience. Microsoft’s Well-Architected observability guidance recommends correlating telemetry across workload components and using it for continuous improvement.
7. Extend the platform for AI workloads
Once teams can provision environments, deliver changes and operate applications through supported paths, AI workloads can build on those capabilities. They still need workload-specific design for model access, retrieval data permissions, evaluation, agent tools, prompt and data handling, safety, telemetry and cost. The cloud foundation supplies identity, networking, policy and operations; the AI platform adds the controls around models and AI behavior.
For the AI-specific extension, read From Cloud Landing Zones to AI Landing Zones. For shared enterprise AI capabilities, see The Enterprise AI Stack Is Becoming a Platform Engineering Problem.
Choose the next investment by the bottleneck
- Maintain the baselineKeep identity, network, policy and management controls current.
- Standardize deliveryReuse IaC modules and validate changes through CI/CD.
- Enable self-serviceOffer common, governed workload patterns through a platform interface.
- Improve operationsAdd service observability, ownership and recovery practices.
- Extend for AIAdd model, data, evaluation and consumption controls when workloads need them.
Do not treat the progression as a package that every organization must implement in full. Ask where teams are currently waiting, repeating work or taking unmanaged risks:
- Environment creation takes weeks: improve workload onboarding and subscription vending.
- Infrastructure changes vary by team: standardize IaC modules, policy checks and release pipelines.
- Every application has a different deployment process: publish reusable CI/CD patterns and supported application paths.
- Teams struggle to operate services: improve instrumentation, health signals, alerting and ownership.
- AI pilots cannot meet production requirements: extend the foundation with AI data, model, evaluation and agent controls.
| Phase | Focus | Exit evidence |
|---|---|---|
| Days 1–30 | Choose one repeated workload path and record its current lead time, handoffs and failure points. | A named owner, baseline measures and an agreed target workload. |
| Days 31–60 | Build a supported path using existing identity, network, policy and IaC foundations. | A versioned workflow with validation, documentation and an operational owner. |
| Days 61–90 | Run the path with representative teams, gather feedback and address support or reliability gaps. | Measured adoption and delivery outcomes, plus a decision to expand, revise or stop. |
Start with one or two high-value paths, measure lead time, reliability, support load and adoption, and improve them with workload teams. Scale the capabilities that remove friction while maintaining governance.
This progression maps naturally to Tongtech’s services: Cloud Foundation establishes the governed base, Platform Engineering makes delivery and operations repeatable, and Enterprise AI extends those capabilities for production AI. Relevant starting points include the Azure Landing Zone Accelerator, Platform Engineering Accelerator and AI Production Accelerator.
Treat the landing zone as a service with an owner
A landing zone is not complete when the initial deployment succeeds. Assign owners for its shared services, policy baseline, network connectivity, identity integrations, monitoring and recovery procedures. Give workload teams a clear way to request changes and learn about planned updates, and publish what the platform team operates versus what each workload team must maintain. Review service health, policy exceptions, unresolved drift and onboarding friction on a regular cadence. This operating loop prevents a technically sound foundation from becoming an undocumented set of resources that no team feels responsible for evolving. Track a small set of service measures, such as provisioning lead time, failed changes, policy-exception age and support demand, then review them with workload teams. The point is to find which shared capability is creating friction or risk and improve that service deliberately. Include a named service owner, support route, service description and published change history in the catalog. These basics help application teams understand where to ask for help and what to expect when a shared capability changes.
Continue reading
References
- What is an Azure landing zone? — Microsoft Cloud Adoption Framework.
- Use Infrastructure as Code to update Azure landing zones — Microsoft Cloud Adoption Framework.
- Subscription vending implementation guidance — Microsoft Azure Architecture Center.
- Architecture strategies for designing a monitoring system — Microsoft Azure Well-Architected Framework.