Desktop Support to Cloud Engineer Is Shorter Than You Think

If you are in desktop support and trying to get into cloud, you are probably making one of two specific mistakes right now, and both of them add years.

The first is that you are aiming about three roles too high, so every job you apply for is one you cannot reasonably get yet, and the rejections start to feel like a verdict on whether you belong here at all.

The second is that you are avoiding the scripting, because it feels like the part you are bad at. Scripting is not the obstacle in this transition. It is the entire bridge.

Desktop support to cloud engineer is genuinely one of the shortest routes into this industry. Most people just take the long way round.

The first mistake is aiming too high

Let me start with the aiming problem, because it wastes the most time.

Somebody in desktop support decides they want to work in cloud, and the role they picture is cloud engineer or cloud architect. So they study for that, they apply for that, and they get rejected for that, over and over. Eventually they conclude that the transition does not work.

But look at what actually happened there. They tried to jump three rungs at once. The rejections were not telling them they do not belong in cloud. The rejections were telling them they skipped the rung directly above the one they are standing on.

And here's the thing. There is almost always a role in between, and it is usually sitting inside the organisation you already work for. It might be called cloud support, or identity administrator, or junior systems administrator with an Azure component. Whatever your company calls the team that handles Intune, or Entra, or the virtual desktop environment.

Those roles are much easier to reach from desktop support, because they overlap enormously with what you already do every day. And this is the part that matters most: once you have one, you are applying for the cloud engineer role from inside the cloud world instead of from outside it. That is a completely different application.

I would rather you take the intermediate role in nine months than spend two years applying for the one after it.

Pro tip: Before you apply anywhere external, find out who owns Intune, Entra and conditional access at your current employer. That team is your target, and you already have a working relationship with them from the tickets you have escalated.

Your current experience counts for more than you think

Now let me push back on something you probably believe, which is that your desktop support experience does not count for much.

It counts for a lot, and I want to be specific about why.

You have been on the receiving end of every identity problem there is. Password resets, multi-factor authentication that will not work on somebody's new phone, conditional access policies that locked out the wrong group, licences that did not apply. Identity is the primary security boundary in cloud, and you have years of practical exposure to how it fails for real people. That is not theory you read in a study guide.

You have also done device management, which is now a cloud service. If you have touched Intune, you have already worked in Azure. A surprising number of people in your position do not realise that counts, and it does.

And there is something less obvious that I think matters more than the technical overlap. You know how to work a ticket. You know how to gather information from a person who is frustrated and does not have the vocabulary to describe what is wrong. You know how to escalate properly, and you know what a good handover looks like.

Cloud teams run on tickets, on-call rotations and change requests. I have watched brilliant technical people struggle badly in operations roles because nobody ever taught them that discipline, and you learned it under pressure.

So the gap between you and a cloud support role is much narrower than it feels from where you are standing.

The second mistake is deferring the scripting

Now let me talk about the scripting, because this is the one I really want to change your mind on.

Almost everybody in desktop support has a slightly uncomfortable relationship with PowerShell. You use it when a knowledge base article tells you to. You paste in the command, it works, and you move on. But you do not feel like you write it, and so you quietly file scripting under "things I am not good at."

What happens next is that people push it to later. They will do certifications first, then a course, then maybe scripting once the other things are done. It becomes the thing at the end of the list that never quite arrives.

Here is why that is backwards. Scripting is not one of the skills in this transition. It is the thing that converts your existing experience into cloud experience.

Think about what you already do manually, repeatedly, every week. You onboard a user. You set up a device. You check group membership. You pull a report on who has not enrolled in multi-factor authentication. Each of those is a task you understand completely and could describe in your sleep.

The moment you automate one of them, you have done something a cloud engineer does. The task did not change. The way you did it changed, and that is the whole distinction.

Why doing it at your real job beats studying in the abstract

And here is what makes this so much better than learning in a vacuum.

When you learn PowerShell against a real task at your real job, you are not doing an exercise. You are solving a problem you personally have, in an environment you understand, with data you can verify. If the script is wrong, you will know immediately, because you already know what the right answer looks like.

That is a far better learning environment than any lab I could build for you, and I say that as someone who builds labs for a living. I have written more about that gap in why cloud labs don't prepare you for real cloud work.

It also gives you something to talk about. In an interview, "I automated our user onboarding, it used to take about twenty minutes per person and now it takes about two" is a real answer with a real number behind it. Compare that to "I am studying for AZ-104." One of those describes something you did. The other describes something you are planning.

And the honest truth is that this is what the job is. A cloud engineer is largely someone who does infrastructure work through code instead of through a console. You already have the infrastructure half. The scripting is what carries you across to the other one. That is why I keep calling it the bridge rather than a skill on the list.

Gotcha: Do not pick your hardest task to automate first. Pick your most repetitive one. The value is in proving to yourself that you can do it, and a task you run forty times a month gives you forty chances to notice what the script gets wrong.

The route, in order

Here is the whole thing in one picture. The dashed line is the jump most people attempt. The steps underneath it are the route that actually works.

So let me give you the actual route.

Automate one thing at your current job. Pick just one, and make it the most repetitive task you own. Write the script and then actually use it. That is step one, and most people skip it entirely.

Get the fundamentals certification if you do not have it. It is cheap, it is quick, and it gives you the vocabulary you need to talk to cloud teams. I would not spend longer than a few weeks on it.

Apply for the intermediate role, and strongly prefer the one inside your current organisation. They already know you and you already know their environment. That is an advantage no external candidate has.

Then go for the associate certification and the cloud engineer title, once you are in that role and the day job is already teaching you. If you want the longer version of what to study and in what order, I mapped it out in how to learn Azure in 2027.

And keep alternating. Automate something, then study something. Automate something else, then study something else. Keep shipping and studying in turns rather than doing all of one and then all of the other.

Where to practise the automation piece

If your current job does not give you anything safe to automate against, or you want to try the moves before you run them on a production tenant, these are the three I would start with. They are the same tasks I have been describing, on an environment that is provisioned for you.

• Microsoft Entra ID: Create Users, Groups and Assign Roles is Beginner level and takes about 40 minutes. This is the onboarding task.
• Creating and Running Scripts in Azure Automation Account Service is Beginner level and takes about 60 minutes. This is where a script stops being something you run by hand.
• Configure Conditional Access Policies and MFA in Microsoft Entra ID is Intermediate level and takes about 50 minutes. You have troubleshot the far end of these for years, so building one is the other half of that picture.

What to take away

Do not aim three roles too high. Take the rung above you, and look inside your own company for it first.

Your identity and device experience counts for much more than you think it does, and so does the ticket discipline nobody ever formally taught you.

And scripting is not the obstacle. It is the thing that turns the job you have into the job you want.

The route is shorter than it looks from where you are standing. Most of the length people experience is self-inflicted.

If you want to know what the other side actually tests for when you get there, I wrote about what Azure hiring managers test instead of certifications.

Now go pick the one task you would automate first. Choosing the right one makes a real difference.