Table of Contents
The shift to the cloud isn’t just a technology or platform shift, it’s a whole new mindset.
“We migrated 200 servers to Azure in six months. The technical migration was a success. Yet twelve months later, teams were still operating like it was 2010, costs were spiralling, and we hadn’t delivered any of the promised agility. The technology worked. The people hadn’t changed.”
This is the story of almost every cloud transformation that fails to deliver value. We focus on the what and the how, but forget the who. Moving to Azure as your datacenter isn’t a technical project, it’s an organisational transformation.
In the last couple of posts in the Using Azure as a Data Center series I’ve illustrated how Azure provides a platform that simplifies infrastructure through software. However, getting full benefit of the cloud means operating in a different way. Infrastructure as code is a major shift in how we maximise our investment in the cloud, but doing so brings complexities and challenges of its own – primarily in the need to up-skill teams.
The identity crisis: Who am I in the cloud?
The shift from managing physical hardware to managing code brings the question, what is my role in the cloud?
The good news is that your skills are just as relevant in the cloud as they are on-premises. You still have to know how to manage servers, how to configure firewall rules, how to plan routing etc, but what changes is the approach you take to manage these resources.
There is no physical infrastructure, and traditional servers often get migrated to platform services instead. Firewalls aren’t really firewalls, they are virtual appliances.
The traditional IT identity
- Network Engineers: Rack switches, configure VLANs, cable management
- Server Engineers: Rack servers, install OS, patch hardware
- Storage Engineers: Manage SAN arrays, allocate LUNs, worry about IOPS
- Security Teams: Physical access controls, firewall appliances, security zones
- DBAs: Install SQL on bare metal, tune for specific hardware
The existential question:
“If Azure handles the hardware, the racking, the cabling, the power, the cooling… what do I actually do?”
The new cloud identity
- Platform Engineers: Build and maintain landing zones, design subscription strategies
- Infrastructure Developers: Write Terraform/Bicep, maintain IaC repositories
- Policy Engineers: Write Azure Policy as code, design governance frameworks
- Cloud Security Engineers: Implement Defender for Cloud, write security policies, design zero-trust architectures
- Data Platform Engineers: Design Azure SQL strategies, implement HA/DR patterns in the cloud
The mindset shift is simple:
From “I manage things” to “I design systems and write code that manages things.”
Traditional vs Azure: The mental shift
| Traditional Datacenter | Azure Datacenter | Mental Shift Required |
|---|---|---|
| Physical rack location matters | Region matters, but racks don’t exist to you | Geography vs. physical placement |
| Cable management, port assignments | Virtual networks, software-defined networking | Infrastructure as API calls |
| Hardware specifications and procurement | VM SKU selection from catalog | From purchase orders to instant provisioning |
| Quarterly patching windows | Continuous updates, auto-patching | From scheduled downtime to always-on |
| Backup to tape, off-site rotation | Geo-redundant storage, Azure Backup | From physical media to service APIs |
| Firewall appliances, port configs | Network Security Groups, Azure Firewall policies | From boxes to code |
| Physical security badges and escorts | RBAC, Azure AD, Privileged Identity Management | From doors to identities |
The skillset evolution: What teams actually need to learn
Core new skills for all infrastructure teams:
1. Version Control (Git)
- Why: Infrastructure is now code, code lives in repositories
- The barrier: “I’m not a developer, why do I need Git?”
- The reality: Pull requests ARE your change approval process
- Starting point: Basic branching, commits, pull requests
2. Infrastructure as Code
- Why: Manual provisioning doesn’t scale, creates drift
- The barrier: Learning a new language (HCL, Bicep, YAML)
- The reality: Writing Terraform is easier than remembering 50 CLI commands
- Starting point: Deploy one simple resource, iterate from there
3. CI/CD Pipelines
- Why: Automation is how infrastructure gets deployed now
- The barrier: “We have change control boards for that”
- The reality: Pipelines ARE the change control (with better audit trails)
- Starting point: Azure DevOps or GitHub Actions basics
4. Policy as Code
- Why: Manual governance doesn’t work at cloud scale
- The barrier: Understanding JSON policy definitions
- The reality: Policies prevent problems before they happen
- Starting point: Apply existing built-in policies, then customise
5. API-First Thinking
- Why: Everything in Azure is an API
- The barrier: “I use the portal, it works fine”
- The reality: Portal is for learning, automation is for production
- Starting point: Use Azure CLI/PowerShell for daily tasks
6. Observability and Monitoring
- Why: You can’t SSH to cloud infrastructure to troubleshoot
- The barrier: Overwhelming amounts of telemetry
- The reality: Proper monitoring gives better visibility than console access ever did
- Starting point: Azure Monitor basics, Log Analytics queries (KQL)
The learning curve is real
Let’s not sugarcoat the reality here. Your teams need to shift their thinking, adapt, and be prepared to learn a code-first approach. A network engineer with 15 years of Cisco experience needs 6-12 months to become proficient with Azure networking.
Server teams have to adapt too. The true benefit of the cloud is not from running hundreds of virtual machines. Server management still matters, but platform management becomes real.
The team structure evolves
Traditional teams are generally siloed. There may be one overarching Infrastructure team, split into multiple siloed domains, servers, workstations, networks, security for example. This approach doesn’t work in the cloud. Azure is too interconnected for siloed teams.
Instead we need to bring teams and roles together with a platform team and a DevSecOps team. You may still need and want to have operational teams that monitor, maintain, and manage existing solutions, and this is often where traditional skills play a fundamental part. Windows running in the cloud is the same as Windows running in an on-premises data center. However, the tooling used to monitor these solutions will often be different (think Azure Monitor, Defender for Cloud, and automated management).
The cloud platform team
This team is responsible for the architecture and governance framework of the Azure platform. They configure the underlying Landing Zone structure, create and manage centralised networking, and define and implement the governance model, including security and cost management.
They are the drivers of the Cloud Platform. They are the key team to contact when platform changes need to be made, and they are advocates of the cloud, often leading the Cloud Community within the organisation.
The engineering teams
This team brings the traditional on-premises teams together. Rather than having siloed domains of responsibility, the teams come together, work together, and implement together.
DevSecOps
Bringing Developers, Security Teams, and Operations teams under one team drives the efficient and secure delivery of new solutions. It’s very much about collaborating and bringing knowledge from these teams together. Think of these teams as being dynamic, potentially incorporating members from the Cloud Platform and Engineering teams together. Team members may change depending on the solution being delivered.
This removes the ‘throw it over the wall’ mentality. Teams own the full lifecycle of the solution. Security becomes embedded in the design and deployment.
What do teams need to learn?
All teams end up managing and maintaining code at some level. Whether this be Infrastructure as Code in the form of Terraform or Bicep, Policy as Code in the form of Azure Policy, or simply application code, dotnet or python for example.
Code becomes the fundamental underpinning of any cloud solution and deployment. Teams that are not willing to learn code will not make it in a modern cloud environment.
With code comes version control. Learning Git enables code to become version controlled. It writes your documentation and pull requests become your change control.
And with Git comes DevOps and Pipelines. All deployments should run through pipelines, whether these be Azure DevOps pipelines or GitHub Actions, pipelines make or break your deployments. They allow consistent staged rollouts with approvals along the way.
In short, teams need to learn code, DevOps principles, and Git. Without these three components the Cloud platform will soon become a management nightmare.
The change control transformation
The traditional approach to change control can bring fear to any seasoned IT infrastructure team member. Eager to deliver and deploy, they are faced with the burden of the dreaded change control process:
- Submit change request (3-5 days wait)
- CAB meeting (weekly or bi-weekly)
- Present technical details to non-technical managers
- Get approval (or get sent back for more details)
- Schedule maintenance window
- Execute change manually
- Document what you did (often weeks later)
Does the Cloud really change this?
Yes, and no…
Often changes don’t get approved by the people they need to be approved by, but if we start using IaC, along with Git for version control, and DevOps pipelines for deployment, we can streamline a lot of the approval processes:
- Create feature branch in Git
- Write/modify IaC code
- Automated tests run (syntax, security, policy compliance)
- Pull request review by peer engineers (technical review)
- Merge to main triggers deployment pipeline
- Automated deployment with rollback capability and approval steps
- Changes automatically documented in Git history
The trust problem
Leadership and Change Boards often struggle with the concept of change control. They fear that without a change board reviewing and approving the change we become vulnerable to impact.
But if we take a strategic look at this, the modern cloud model is actually much more controlled than the traditional version.
Traditional teams often have access to perform changes directly, even without the need to submit a formal change request. Sometimes they get away with making these changes, and other times it catches them out when something breaks and they have to explain why they didn’t submit a change.
With the cloud RBAC model, engineers don’t get access to make changes directly to the infrastructure or application. They have to go through the processes, using the tools that were defined during project inception. If they want to make a change to an IaC deployment, they have to go to the code, make the change, then submit it for approval before it can be deployed.
Change control becomes enforced by the platform.
The real question is: “Do you want control, or do you just want the illusion of control through process?”
The cost of not changing
What happens when technology changes but people don’t?
Scenario 1: The Portal Clickers
- Team refuses to learn IaC
- Everything deployed manually through portal
- Environments drift within weeks
- No way to replicate production
- Disaster recovery is theoretical
- Result: “Cloud is expensive and unreliable”
Scenario 2: The On-Prem Mindset
- Lift and shift VMs, then manage them like physical servers
- Manual patching, RDP/SSH access for everything
- Over-provisioned “just in case”
- No autoscaling, no managed services
- Result: “Cloud costs more than our datacenter”
Scenario 3: The Process Paralysis
- Keep traditional CAB process
- Require 2-week lead time for any change
- DevOps teams wait weeks to deploy
- Business complains about “slow IT”
- Result: “Cloud didn’t deliver the promised agility”
The pushbacks you’ll hear (and how to address them)
I often hear several pushbacks with transformation and learning new skills. It’s understandable, change is uncomfortable and it’s delving into the world of the unknown.
Here are some thoughts on the most frequent ones I hear:
1. The “I’m not a developer” resistance
Address this head-on. You don’t need to become a software developer. But you do need to write code. It’s a different kind of code, declarative, infrastructure-focused. Many infrastructure engineers find they enjoy it once they get past the initial discomfort.
2. The generational divide
Acknowledge that this is often harder for engineers with 15-20+ years in traditional infrastructure. They’ve built deep expertise that feels devalued. Validate this feeling while helping them see their infrastructure thinking is still valuable, it just needs a new expression.
3. The “cloud is just someone else’s computer” cynicism
Some engineers will be dismissive. They’re not entirely wrong, but they’re missing the point. It’s not about the physical reality, it’s about the abstraction layer and what it enables.
4. The imposter syndrome wave
New cloud engineers often feel like imposters because the field is so broad. Reassure them that specialization is okay. You don’t need to know every Azure service, you need depth in your domain and enough breadth to collaborate.
5. The “automation will replace us” fear
Be honest: Some roles will disappear. But automation creates more work than it eliminates, it just shifts the work from repetitive tasks to designing systems. The teams who embrace automation become more valuable, not less.
6. The cost of convenience
Azure makes it easy to spin up resources. Too easy. Teams need discipline. This is where policy, governance, and culture matter, technology enables, but people must still make good decisions.
7. The security mindset shift
Security must shift from “prevent access” to “assume breach.” Zero trust, least privilege, identity-based access. This is fundamentally different from firewall-based perimeter security.
Building the bridge: Practical steps to transformation
Bringing teams together and training them to support the new cloud platform takes time. I’ve broken it into 5 manageable stages to support the transformation to modern infrastructure management.
Phase 1: Awareness (Months 1-2)
- Executive workshops: Why this transformation matters (business outcomes, not tech)
- Team workshops: Honest discussion about what changes, including difficult topics
- Skills assessment: Where are we now? Where do we need to be?
- Identify champions: Find the early adopters in each team
Phase 2: Foundation Learning (Months 2-4)
- Structured training: Git, Azure fundamentals, IaC basics
- Sandbox environments: Let teams break things safely
- Pair programming: Junior cloud skills with senior infrastructure knowledge
- Community of practice: Regular knowledge sharing sessions
Phase 3: Pilot Projects (Months 4-8)
- Choose non-critical workloads: Lower stakes, real learning
- Embed cloud-native practices: IaC, pipelines, monitoring from day one
- Document lessons learned: What worked, what didn’t
- Celebrate wins publicly: Build momentum
Phase 4: Scale and Standardize (Months 8-18)
- Build platform team: Dedicated infrastructure/platform engineering
- Create reusable modules: IaC libraries, pipeline templates
- Establish new ways of working: Updated RACI, new change processes
- Continuous improvement: Retrospectives, iterate on processes
Phase 5: Continuous Evolution (Ongoing)
- Stay current: Azure changes constantly
- Experiment with new services: Innovation time, proof of concepts
- Share knowledge: Internal tech talks, external blogging/speaking
- Measure outcomes: Business value, not just technical metrics
What leaders must do
Leaders play a vital role in enabling teams to transform. Buy-in from leadership is critical, without it, failure will likely be your end path.
1. Acknowledge the difficulty
“This is hard. Your skills aren’t obsolete, but they need to evolve. We’ll invest in you.”
2. Provide time and resources
- Dedicated learning time (not “fit it in between tickets”)
- Training budget for courses, certifications, conferences
- Access to sandboxes and experimentation environments
3. Measure and reward new behaviors
- Reward IaC adoption
- Celebrate as team skills grow
- Recognise team members who help others learn
4. Remove barriers
- Challenge legacy processes that don’t fit cloud
- Support new team structures
- Push back on “we’ve always done it this way”
5. Accept short-term slowdown
Learning takes time. Teams will be slower initially and legacy processes may slip or become delayed. Budget for this. Bring in temporary support to backfill teams as they skill up.
Not everyone will make the journey
The uncomfortable truth is people don’t like change, and some don’t want to learn new skills. They are content in the traditional way of doing things. You need to acknowledge this and support those who feel like this. If there are still legacy environments running in traditional data centres they can help to continue to support those systems.
Summary
Azure as a datacenter isn’t just a technology migration, it’s a transformation of how IT teams think, work, and deliver value. The servers and network switches aren’t gone; they’re just abstracted. What remains is the need for skilled people who understand infrastructure deeply, but who express that understanding through code, automation, and cloud-native design patterns.
The teams that succeed aren’t necessarily the ones with the deepest cloud expertise on day one. They’re the ones who embrace continuous learning, who are willing to be uncomfortable for a while, and who understand that the goal isn’t to replace people with automation, it’s to free people from repetitive work so they can focus on solving genuinely interesting problems.
The cultural shift is the hardest part of the journey. It’s also the most important.
Additional Reading
The key concepts from this series are based on the Cloud Adoption and Well Architected Frameworks.
Check out the previous articles in this series