Home / Nerdio Academy / Microsoft Azure / How to Migrate to Microsoft Azure: Strategies for MSPs

How to Migrate to Microsoft Azure: Strategies for MSPs

Vadim Vladimirskiy
Vadim VladimirskiyFounder & CEO, Nerdio
0 commentsJuly 11, 2019Articles

Pure Cloud vs. Hybrid Cloud

Should you migrate all your customer’s IT components to Azure, or only some of them?

 

Should you perform a cutover migration (where users are accessing an on-premises environment one day and all accessing the cloud the next) or should you migrate your users in groups or phases?

 

There is no single right answer. As you’ve likely guessed, it all depends on the individual customer, their IT components and applications, and your staff’s capabilities.

 

Let’s look at a possible framework of how to think about these important questions. You should have a good idea about the approach to an individual customer migration before you get started, as well as an overall strategy for how you approach Azure migrations. This helps your staff and processes standardize around your approach. It’s best to avoid running each project in an ad-hoc manner without an overarching strategy. This will not only lead to lack of standardization, management, and scalability challenges, but losing the opportunity to leverage each individual Azure migration project to benefit future ones. Without a common framework and some level of process standardization, it’s hard to capitalize on what you learn from your projects.

 

Let’s look at what this framework could look like.

 

There are two questions to consider:

  1. What should end up in Azure eventually?
  2. When should each component end up in Azure?

 

The “what” question deals with all the individual components in a customer’s IT environment that may or may not be a good fit for the cloud. Don’t worry about how or when this will happen. Just focus on the ideal-case scenario. Imagine you’ve migrated your customer to the cloud and three years from now you look at their IT environment. What’s running in the cloud? What’s still running on-premises? What is a SaaS application? What is running inside of a VM in Azure? You get the idea.

 

Most MSPs would say they would like to have as much of their customers’ IT in the cloud as possible. Any remaining on-premises components may be “cloud unfriendly”, for technical or economic reasons.

 

Let’s consider a top-level objective of “Move everything that can be moved to Azure and leave things that we must on-premises”. Here’s set of common IT stack components and where they fit in with this objective:

  • Messaging and collaboration (i.e. email, chat, document sharing) – That’s an easy one. Office 365 is where this belongs, and that’s obviously in the cloud.
  • Files (i.e. company shares) – Shared files belong in the cloud as long as performance isn’t heavily impacted. Storage is inexpensive, backup is easy, and snapshots are available.
  • Databases (i.e. SQL Server) – The cloud is the ideal platform for databases too. Not only are licensing costs typically lower, but the ability to scale out to increase performance and protect critical data (with backups and replication) are important considerations.
  • Line-of-business applications (e.g. ERP, CRM) – Any app with a browser-based end-user interface is perfect for the cloud right next to its database and file shares. Applications with a client/server architecture are a bit more of a challenge, and performance considerations come into play. An efficient application with a non-chatty client that can run over the internet while connected to its server back-end in Azure is a great fit for the cloud. An application with a chatty client cannot have its server and client components separated by the WAN and must therefore stay close to each other, from a network latency and bandwidth perspective. The decision to move client/server apps with chatty clients depends on whether end-user desktops are also being virtualized in the cloud. If yes, then these LOB apps belong in the cloud. If not, user performance issues will overshadow any benefits of moving the back-end to the cloud.
  • Active Directory – AD should definitely be in the cloud. It may be “all in the cloud” or be “extended to the cloud”. Either way, having the customer’s AD in Azure is a foundational component of moving the rest of the environment to the cloud since user and computer authentication information resides in AD.
  • End-user desktops – For an organization with SaaS-only applications (e.g. Office 365 + QuickBooks Online only), having a virtual Windows desktop in the cloud may not provide much value. However, organizations with client/server applications, data security, and compliance requirements - or large, geographically diverse user populations can benefit significantly from having virtual desktops for all users hosted in Azure and accessing data and applications over LAN speeds.
  • Backup (i.e. destination of backup copies) – Cloud is perfect for backup and DR. Storage space is inexpensive, it is physically remote from the original copy, and there is plenty of redundancy built in.
  • Security (e.g. firewall, AV, IPS, Content Filtering, encryption, etc.) – Where to house a customer’s security infrastructure depends primarily on where the data, users, and applications that this security infrastructure is protecting is housed. If email, files, database, and desktops are in the cloud, then certainly having security components protecting those systems being in the cloud as well makes perfect sense. If components are split between the cloud and on-premises (e.g. desktops local and database in the cloud) having a firewall in both places is necessary.
  • Peripherals (e.g. printers, scanners, POS systems, shipping scales) – This one is pretty much a no-brainer since none of these physical devices can be moved to the cloud.
  • Video DVRs and Door Control Systems – These are typically best left on-premises. They interface directly with physical components such as cameras and doors and separating the controller virtual machines from the devices they are controlling is not recommended.

 

As you can see, most IT components are a natural fit for the cloud. This answers the “What” question. The next thing we must deal with is the “When”.

 

The “When” question deals with the process of moving the selected IT components to the cloud. There are two primary ways to do the migration:

  • Cutover migration – In this scenario, the cloud environment is set up independently of the existing on-premises environment. All applications are installed on the appropriate servers, virtual desktops are prepped with all user configurations, a baseline of all data is copied to file and database servers, and the new environment is set up as close to production as possible. A test user group is then selected to log into the new, isolated cloud environment to confirm that all applications are working and perform well. A “go-live” date is scheduled. Users are “pointed” away from the current environment to the new cloud environment overnight or on the weekend. When employees come in the following morning, they are logging in and using the new cloud environment while the “old” environment is still available – just in case. Assuming all goes well, the old environment is decommissioned in the coming weeks. This results in the customer having switched from an existing system to a cloud-based one in a cutover fashion.
  • Phase-in migration – in this scenario, the cloud environment is preconfigured with select IT components like Hybrid Active Directory, and one or more workloads are moved to Azure. Users continue using both the existing system and the new cloud-based one at the same time for an extended period. The Azure environment might be connected to the on-premises environment via VPN and Hybrid AD with a single application server moved to Azure, for example. Users continue using their existing desktops and applications hosted locally, except for the one application that was moved to Azure. This application will be accessed via the Site-to-Site VPN tunnel using users’ existing AD credentials. Over time, additional workloads like file shares, databases, and virtual desktops can be moved one at a time from on-premises to Azure until all the desired IT components have been migrated.

 

A Cutover migration is a one-time event with lots of work that precedes it and a burst of activity immediately after the go-live. After some time, the activity level subsides as users get used to their new cloud environment and start appreciating the benefits. Cutover migrations are typically best for simple, small environments where it makes sense to do everything at once. It is challenging to do a cutover migration of a large and complex IT environment due to the risk of missing critical components, which means that the risk of user disruption is also high. On the other hand, cutover migrations can be very quick and completed within weeks, or even days.

 

A Phase-In migration is a journey. It breaks the migration process down into small, manageable steps that are executed in sequence with the opportunity to have users validate the environment, in production, every step of the way. Phase-in migrations can take a long time to complete. It’s not unusual to see these last for months, or even years. However, this is a safer approach to migrating large and complex environments. For small, simple environments, phase-in migrations are typically more work-intensive and disruptive than necessary.

 

Before an Azure migration, make a list of which IT components will be migrated to the cloud and which will stay local. Consider the migration approach that fits best - Cutover or Phase-In - and discuss it with the customer. Do they prefer to just “get it done”, or do they want to stretch it out and take the time to test everything thoroughly? Be sure to let your customer know if you disagree with their preferred approach. If they want to move a complex IT environment to the cloud over a weekend without proper testing and validation you need to be confident and advise them against such an approach. Ultimately, if things don’t go well (which is likely in this scenario), the customer may blame you for the failure.

 

You've identified your migration approach. On the next page we'll look at how Nerdio for Azure can handle Active Directory in a migration scenario.

 

By the way: if you'd like to find out any of the other many things Nerdio for Azure can do for your business, or just hear about migration from the horse's mouth, we'd love it if you got in touch.

 

CONTACT US

Pages: 1 2 3 4 5 6 7 8