From IT Support to Cloud Engineer: How to Make the Move

What you already have

Most IT support professionals underestimate how much of their existing knowledge applies. Here is what a typical IT support background typically gives you:

Troubleshooting instincts

IT support is fundamentally a debugging role. You take a symptom, investigate systematically, isolate the cause, and fix it. That is exactly what cloud engineers do when a service is down or a deployment fails. This instinct is not obvious to someone who has never done it — you have been developing it for years.

Comfort with operating systems

Even primarily Windows-focused IT support roles usually involve some Linux exposure — servers, appliances, containers. If you have spent any time with Linux, you have a foundation. If not, your existing comfort with operating systems makes picking it up faster.

Networking basics

DNS issues, DHCP, IP conflicts, VPN problems — IT support deals with these constantly. You probably already understand what an IP address is, how DNS works, what a firewall is, and why something cannot connect. This is a meaningful head start. Many self-learners find networking the hardest part of transitioning to cloud; you have a base.

User access and permissions

Active Directory, group policies, permission management — you understand access control in a real organisational context. Cloud IAM is a more sophisticated version of the same concept. Your existing mental model transfers.

Working under pressure with real consequences

IT support, especially in production environments, involves working with real impact — a user who cannot work, a system that is down, a deadline that is missed. Cloud engineering has higher-stakes incidents, but the mental composure and communication patterns you have developed will serve you.

What you need to add

Being realistic about the gaps means you can close them efficiently.

Cloud platform knowledge

AWS, GCP, or Azure — the managed services, the networking constructs (VPCs, security groups, subnets), IAM as it works in a cloud context, storage, compute. This is the core new domain. Plan 6–10 weeks of focused study.

Infrastructure as code

You probably managed infrastructure by clicking in a console or running manual commands. Professional cloud engineering means writing Terraform (or similar) to define infrastructure as code. This is a meaningful skill shift — it requires learning a new tool and a new way of thinking about infrastructure management. Plan 4–6 weeks.

Containers

Docker and Kubernetes are central to modern cloud engineering. Docker is approachable — a few weeks of focused study and you can write Dockerfiles and deploy containers. Kubernetes is more complex; entry-level understanding (pods, deployments, services, kubectl) is achievable in 4–6 weeks. Deep Kubernetes administration is a separate specialism.

CI/CD pipelines

Understanding how code goes from a pull request to a deployed environment automatically. GitHub Actions is the most approachable starting point. Plan 3–4 weeks to get comfortable writing workflows.

Python or Bash scripting

You may already know some Bash from command-line work. If not, basic scripting is worth learning early — automation is core to the cloud engineering workflow. Python is the preferred scripting language for most cloud work. You do not need to be a software developer, but you need to be able to write and modify scripts.

A practical path from IT support to cloud engineer

Step 1: Use your current role (ongoing, now)

Before you do anything else, look for cloud exposure in your current role. Is your organisation using AWS, Azure, or GCP for anything? If so, get involved — even peripherally. Help with cloud tickets, ask to shadow the team that manages cloud resources, volunteer for a project that has a cloud component.

Commercial exposure — even minor — is worth a lot in interviews. “I helped our team migrate our file server to Azure Blob Storage” is a real thing you can talk about. “I completed the AWS Solutions Architect course” is weaker.

Step 2: Linux and scripting (if needed) (3–5 weeks)

If your Linux skills are thin, invest here first. Set up an Ubuntu VM at home. Navigate the terminal without the GUI. Write small Bash scripts. Get comfortable with systemctl, SSH, and log reading. If you already have solid Linux skills, skip this or treat it as a quick refresh.

Step 3: Cloud fundamentals + first certification (8–10 weeks)

Pick one platform. AWS has the most job market coverage; Azure is most common in enterprise environments that are heavy on Microsoft. Work through the free tier hands-on. Get your introductory certification: AWS Cloud Practitioner, GCP Cloud Digital Leader, or Azure AZ-900.

These exams are deliberately broad. They test that you understand the landscape, not that you can implement it. They are the right starting point.

Step 4: Terraform (4–6 weeks)

Learn to provision cloud resources with Terraform instead of clicking through the console. Build the same things you built in step 3 — but with code this time. Write a Terraform configuration that creates a VPC, a VM, and a firewall rule. Understand plan vs apply, and how state works.

Step 5: Containers and CI/CD (6–8 weeks)

Docker first: understand what a container is, build an image, run it, push it to a registry. Then Kubernetes basics: deploy a simple application to a local cluster with minikube. Then GitHub Actions: write a pipeline that builds and deploys something automatically.

Step 6: Associate certification + portfolio (8–10 weeks)

Work toward an associate-level certification: AWS Solutions Architect – Associate, GCP Associate Cloud Engineer, or Azure AZ-104. Alongside this, build or polish two to three GitHub projects that demonstrate real infrastructure work. These projects are your proof of capability.

Typical timeline from IT support

At 10–15 hours per week alongside a full-time job:

• Months 1–4: Foundations, cloud fundamentals, first certification
• Months 4–8: Terraform, containers, CI/CD, building projects
• Months 8–12: Associate certification prep, portfolio work, starting to apply
• Months 12–15: Active job search, interview prep, refining weak areas from rejection feedback

This is 12–15 months to a reasonable first offer for most people. Some move faster — especially if they have stronger Linux and networking than average IT support roles require. Some take longer, particularly if studying hours are inconsistent.

How to frame your IT support background in interviews

The story you tell matters. “I worked in IT support and decided to learn cloud” is weaker than a narrative that connects your experience to the role.

A better framing: “In IT support, I developed strong troubleshooting skills and saw how much of our infrastructure was moving to cloud. I wanted to work at the infrastructure level rather than the end-user level, so I spent the last year learning cloud engineering — here is what I built.” Then talk about specific projects and what you learned.

Explicitly name the relevant experience:

• “I am comfortable working through ambiguous problems — in support you often have no guide for the specific issue in front of you."
• "I have experience with access management — it was a big part of my support work, and IAM in cloud is a more powerful version of the same idea."
• "I have worked with real consequences for mistakes — a misconfigured system in support affects users immediately, and I am comfortable with that pressure.”

Mistakes IT support people often make in this transition

• Skipping infrastructure as code. Some IT support people are used to managing infrastructure by hand — clicking, running commands, making changes directly. Cloud engineering at any scale requires IaC. Skipping Terraform because “I can do it in the console” leaves a critical gap.
• Underselling networking skills. Your networking knowledge is often ahead of self-learners who came from other routes. Talk about it specifically in interviews.
• Not building portfolio projects. The IT support background is strong, but employers at cloud engineering roles want to see that you can build infrastructure code, not just manage existing systems.
• Waiting to have every skill before applying. Apply when you have the core foundation and portfolio work — you will not feel fully ready, but neither does anyone else at the junior level.