The last several posts in this series have zeroed in on specific structural and technical pitfalls to avoid when getting started with Azure. In this post, let’s zoom out a bit and consider a mistake that’s more conceptual than it is technical—namely, that switching from an on-premises environment to the cloud will not exactly replicate functions.

This can be a tough one for IT professionals to grapple with. Many companies have worked hard to establish functions in their private clouds, and of course that experience is their starting point as they plan for the public cloud. But it’s important to understand that the public cloud simply functions differently.

For example, consider network segmentation. One of the biggest benefits of moving to the cloud is security gains arising from micro-network segmentation—that is, resource groups talking to other resource groups only when they need to. That’s in contrast with traditional corporate environments, which are characterized by a high degree of interconnectedness among resources and the resulting vulnerability to lateral movement of threats.

And even if you wanted to segment a traditional corporate network to achieve some of those security benefits, you are likely to struggle to accomplish it. For example, say you wanted to create a micro-network that segments off an application so it can’t talk to others. To do so in a CorpNet setting means close coordination across separate, segregated IT teams—network, Windows, application and so on. That’s a daunting task to pull off for one application; for many resources, it’s essentially impossible. (For more on the problems of team segmentation, Mistake #9 – Not Retaining or Restructuring Existing Employees.)

All that changes as you take that application to the cloud. When you deploy an application in Azure, you establish and enforce rules that allow it to touch only those resources needed to fulfill its purpose. Because this “vertical network” model is fundamentally different, it’s no surprise that not all the functions you are familiar with from an on-premises environment will be replicated exactly as you shift.

So, make sure you’re adjusting your conceptions to fit a whole new paradigm. Here are a few key ideas to help you make that conceptual leap:

• Do not assume current tools needs to move to the cloud. Switching between environments is a prime time to reexamine operationalization. Monitoring, backup, and patching all change when migrating. Use public cloud services where applicable, rather than moving existing on-premises tools to accomplish the same tasks. And when you do migrate a tool, take only the needed components.

• Do not assume the CorpNet needs to be the “hub.” The cloud will be the new source of the distributed network—this is a fundamental repositioning of “where” the hub of the business is! Secured application traffic no longer needs to ride on the CorpNet. More broadly, start thinking of the CorpNet as just be another branch in a constellation of segmented networks. Eventually, desktop computers won’t even by joined to the CorpNet; in the Modern Desktop model, they will instead join a guest network, authenticate in the cloud, and be managed from the cloud.

• Realize that new apps just aren’t getting built on Windows virtual machines. “Serverless” applications run from Azure, so while your current focus may be on bringing legacy resources to the cloud, keep in mind that your future apps won’t even need migration because they’ll have been built for the cloud in the first place.

These brief examples, among many others, underline the key point: embrace your journey to Azure as a completely new paradigm, rather than trying to duplicate the one you already know.