---
title: "Infrastructure-as-Code: The Methodical Approach"
description: "How organisations methodically manage the transition to Infrastructure-as-Code: the organisational decisions, the upskilling question, and the step-by-step build of an IaC culture."
sidebar:
order: 2
label: "Infrastructure-as-Code"
source_url: "https://framework.stackit.cloud/adoption/adapting-operating-models/iac/"
source_file: "docs/adoption/adapting-operating-models/iac.mdx"
---
## What Infrastructure-as-Code means — and why it is a leadership decision
Infrastructure-as-Code is the practice of describing infrastructure — servers, networks, databases, security rules — in writing, rather than configuring it through manual clicks in a console. What sounds technical is, in its effect, a leadership decision: the organisation decides that infrastructure changes must be documented, traceable, and reviewable — like any other significant decision.
This decision has profound organisational consequences. Infrastructure documentation no longer becomes outdated, because the system always matches what has been written. New environments — a second location, an additional test environment, disaster recovery — are not the product of days of configuration work, but of repeating existing code. Errors are caught before they occur, because changes are made explicit and can be reviewed.
## The decisions that come before the first line of code
Before the first infrastructure description file is written, three organisational questions must be answered. They determine whether IaC becomes a stable operating model or a well-intentioned approach that isn't followed in practice.
**Who writes and maintains the infrastructure descriptions?** The two extreme answers are both problematic. If only the Platform Team writes code, a bottleneck emerges: teams must wait for infrastructure instead of working independently. If every team acts fully autonomously without common standards, an incompatible tangle of approaches emerges. The methodically correct path lies in the middle: the Platform Team sets standards and provides reusable building blocks. Teams work autonomously within those boundaries.
**How are changes to production environments approved?** An infrastructure change in production made by one person, without review, without a record — that is the same risk as clicking manually in the console, only harder to undo. The sensible requirement is that production environment changes always run through an approved automated process, never directly by hand.
**Where is the system state stored?** IaC tools manage state: what is currently deployed? This state is critical to the functioning of the entire approach. It must be stored securely, centrally, and accessibly for the team — never on one person's laptop, never in a publicly accessible system.
## The upskilling question: who learns what?
Infrastructure-as-Code changes the requirements for people who manage infrastructure. This is not primarily a technical challenge — it is a learning curve that requires time, practice, and a fault-tolerant learning environment.
Systems administrators who have managed infrastructure through configuration interfaces for
years must develop a different mental model: instead of "I click Create," they think "I describe
the desired state." This shift is learnable, but it takes time and must not be underestimated.
The infrastructure knowledge stays — and is the biggest advantage. Someone who understands how
networks, security groups, and databases work learns the new description form quickly. Technical
knowledge doesn't need to be rebuilt, only the method of applying it.
Sandbox access for experimentation without consequences, pair work with more experienced
colleagues, no punishment for mistakes in test environments. Someone who makes mistakes while
learning, learns. Someone who makes mistakes and is criticised for them stops learning.
The Platform Team is not a control body in this phase — it is an enabler. It provides learning
materials, answers questions, reviews code alongside teams — not to evaluate, but to teach.
## Building IaC maturity incrementally
The transition to Infrastructure-as-Code is not a project with a start date and a sign-off. It is a maturity curve that unfolds over months and years. What matters is knowing the current position and taking the next sensible step — not trying to immediately reach the highest maturity level.
The first stage is the simplest: new resources are described as code, existing resources remain manual for now. This is incomplete, but a genuine start. Every new piece of infrastructure that emerges as code is a resource the team fully understands, has documented, and can restore.
The second stage brings all production resources under code control and introduces a central state store. Manual changes to production environments become the exception that must be documented.
The third stage connects IaC with automated quality and compliance checks. Changes are not only reviewed, but automatically evaluated against security and governance requirements before being executed.
## Why IaC is not an end in itself
Infrastructure-as-Code is not the goal — it is the means. The goal is a cloud environment that is traceable, secure, reproducible, and auditable. IaC is the most efficient path to get there.
Organisations that introduce IaC typically report three effects after six to twelve months: new environments emerge in hours, not days; infrastructure incidents are resolved faster because the path back to the baseline state is known; and audit requests are handled more efficiently because the documentation of state is created automatically.
These effects are more motivating than any abstract reference to best practices.
1. **Define the starting point:** Which part of the infrastructure to begin with? New resources in a non-critical environment are the lowest-risk entry point. Existing complex production infrastructure is not a good starting point.
2. **Provide standards and building blocks:** The Platform Team develops reusable descriptions for common infrastructure components. These building blocks are the lever that allows teams to start quickly without having to reinvent every step.
3. **Accompany the upskilling:** Teams receive learning time, sandbox access, and support. This step is frequently underestimated — and is the most common reason why IaC introductions stall.
4. **Complete and evaluate the pilot:** What worked? What was harder than expected? What needs to be adjusted? This evaluation is the foundation for the broader rollout.
5. **Expand incrementally:** Based on pilot experience, bring in further teams until all production resources are under code control.