What do you really get when you perform a lift and shift to Azure?

“Lift and shift or rehosting” can sound a little like moving resources from point A to point B, meaning you will move everything the good stuff and the bad stuff and you will end up with an environment that is almost identical to what you had. But rehosting your environment is so much more than that. Instead of simply moving resources around let’s let at it a little bit differently.

When rehosting your infrastructure on Microsoft Azure, you’re basically saying:

“Hey infrastructure, I’m pretty happy about the way things are going, let’s give you a better place to live - A place with a better view and where you don’t have to worry as much.. ''

Because, that’s exactly what you’ll be doing. Let’s start with the basics.

Infrastructure as a Service 
We’ve published multiple articles on the different technology stacks you can use on Microsoft Azure but when we’re doing a lift and shift we mainly focus on Infrastructure as a Service and if we dig a little deeper into Azure then we’re talking about Microsoft Compute. What we’ll be looking at specifically when doing a lift and shift is: Servers, Storage, networking and security.

But what do you get when you make the move onto Infrastructure as a Service? Well, when you think of it: probably a lot more features than you have right now either on-premise or in a traditional data center.

The comparison
The challenge here is comparing apples to apples and making sure that both pricing and functionality match your ambitions. Let’s take availability and continuity as an example.

Availability in traditional Environments
When you host your environment on-premises you probably have either a VMWare or Hyper-V Configuration with High Availability functionality enabled. Most environments we come across have a hot-standby configuration when it comes to availability and continuity. Meaning that when a virtual machine goes down unexpectedly it will restart on a different host. This requires at least multiple hosts and a high-performance storage environment. And then you just have the basic scenario, if you want to have a truly high available environment you might want to consider running a live scenario where you spread your load across multiple data centers and have enough capacity on both sides to fail-over from A to B or vice versa.

Well that sounds like a lot of work and a pretty big investment as you need good hardware, multiple data centers, expensive storage and high-performance data connectionsAnd. to be fair, not many companies have failsafe’s implemented up to that level (but we all want this 😊). Answer yourself this question: “Do I really have a representative failover scenario that I test periodically?”

In addition, you need to manage your back-ups and have a dedicated off-site solution for that. and you definitely want to keep your systems up to date. And to manage all this you have probably implemented extensive change management procedures, back-up and recovery testing plans and a detailed CMBD.

This all sounds like a lot but it is stuff you need to think about when hosting your environment on your own hardware.

IaaS on Azure
First things first: pricing in the public cloud is completely different as opposed to traditional environments. And in traditional environments we have two common scenarios:

  • Hosted on-premise where you do a large investment in hard- and software with a depreciation of 3-5 years (and probably squeeze out an extra year with extended support);
  • Hosted in a data center where you either pay a monthy or yearly fee or invest in the hardware and just pay for the rack space and networking.

Regardless of the scenario, it will be completely different when moving to the public cloud using IaaS. On Microsoft Azure you will pay a price per hour and are billed monthly. How the pricing works for IaaS and how it can benefit you: please check our article on cloud strategies:  And if you’re really sure about your resource and capacity requirements and you are still looking for that investment model then you can opt to use Reserved instances.

With IaaS on Azure a high level of availability is included. You will not always get an SLA when deploying a single virtual machine, but do you really need to? Is a true high available and live failover scenario a requirement for all your systems?

If you deploy a Virtual Machine on Microsoft Azure you can easily equip it with Azure Back-up and with a literally a few minutes of clicking through the portal you have short-term and long-term protection configured. It’s almost an out-of-the-box experience. From that moment on you have the ability to either restore a complete Virtual Machine or a single file. Let’s say your Virtual Machine breaks down and you need to redeploy it, no worries Azure Back-up has got your back. And from an availability perspective what are the chances that Azure will completely shut down and you lose access to your Virtual Machine? Pretty slim... And in the case of a data center failure Microsoft will re-provision your machine somewhere else. Sounds a lot like on-premise disaster recovery, right? Indeed, it does, but on Azure it comes with the platform.

There are a lot of different scenario’s when it comes to availability and continuity but the above example proofs the point that lifting and shifting isn’t necessarily more expensive, as long as you compare apples to apples and /or implement scenarios such as “Off and On” as described in the article “Choose your strategy”. 

What else do you get?
Back-up and recovery is just a single feature of what is available on the IaaS stack. You will get much more than that.

  • Improved security with Azure Security Center
    Azure Security Center comes in two different subscriptions. The free edition will already install the required agents on your virtual machines and run all the scans that check for best practice configurations. Any configurations (in or outside of the VM) that are considered risky will be reported and provide you with the possibility to mitigate the risks, either automatically or manually.

  • Detailed logging, monitoring and alerting
    What’s happening in your environment? By default, all actions within Microsoft Azure are logged and stored. With a few clicks you can extend this to your own Log Analytics Workspace and Azure Monitor configuration, allowing you to search for whatever happened in your environment by using the Kusto language.
    Azure Monitor and pretty much every resource in Azure supports the configuration of alerts. By configuring the thresholds that are applicable to your solutions you can notify your Ops team when unexpected behavior is detected

  • Scaling up and down
    Not having the performance you need? Scale up or down with a single click and the virtual machine will re-provision with the resources and capacity you need. There are many different virtual machine tiers, each with their own purpose and pricing.

  • Automated updates
    With Update Management, which is available for virtual machines, you can manage the updates and patches for your operating systems. You can choose to do this manually or automatically (just schedule a maintenance window). And as an added bonus you can also manage your on-premises environment with Azure Update management.

  • Change Tracking
    Configuration Management is one of those processes that everybody wants, but the implementation can be quite challenging. What do you document and how do you track changes on your configuration items? Especially with  ever-changing environments, this can be a daunting task.

    But by deploying the change tracking solution you can keep track of all the changes that occur on the virtual machine whether it’s a registry or file change, it will be logged.

To summarize: even when doing a lift and shift you are still improving your environment. You will add availability, continuity and gain access to features you probably want to implement but it’s too much of a hassle when doing it manually and on-premises.

You are in-fact providing your infrastructure with a better place to live and you can already start focusing more on publishing your solution rather than infrastructure management. Plus you now have possibility to extend your functionality to other Azure resources and maybe look at refactoring or rearchitecting parts of your solution.


  • Migrate
  • IaaS
  • Datacenter Migration

Possibly interesting as well: