It is tough to make an argument any longer that the future of computing is anywhere other than in the public cloud. With Microsoft recently posting a 38.4 Billion (with a B) run rate for its commercial cloud services in Q3 2019, it would seem like everyone is moving workloads in some fashion to the public cloud. If your business has not yet embarked on some sort of cloud migration, the truth of the matter is that you’ve now passed late adopter and have achieved laggard status.

That said, even though millions of businesses have now made the leap, moving their business’ critical apps and data to one of the major cloud providers, it has not been without some bumps in the road (or dare we say, turbulence). Cloud migrations, particularly when we move beyond productivity workloads such as email and messaging to on-premise server and application workloads, are still not as cut and dry as they may initially appear. One of the biggest mistakes we often see involve businesses that assume that moving their servers and applications to the cloud is a simple “lift and shift” exercise comprised of copying any existing virtual and physical server workloads from their environment. While this approach may accomplish the task at hand, it will more often than not result in oversizing, overspending, poor performance, reduced availability, insecure configurations and in the worst-case, application failure and data loss.

In this series of blog posts, you’ll get a run through some of the major points of consideration you need to understand before beginning any datacenter modernization project which includes moving server and application workloads to a public cloud provider such as Microsoft Azure.

1. What are your applications and how are they architected?

The first step to ensure a successful migration is to understand your applications and your data. Beyond just understanding what the applications are and how many copies you have, it is also very important to understand how they are architected.

Client-Server, WebApp, ClickToRun?

Many business applications, particularly financial or accounting applications are run in a client-server architecture, where the core data and “backend” application and database live on a server, while a client or “front-end” application is installed on a user PCs. This type of architecture assumes strong network connectivity between the front-end and the back-end. Even though the quality of internet connectivity has grown exponentially in the last number of years, moving one of these types of application servers from your local office to the cloud will often cause unbearable performance issues for your end-users requiring them to wait 5-10 seconds for screens to update when before it was instantaneous.

Remote Application Delivery

One way to mitigate the performance impacts noted above is to move your end-user devices close to where your applications servers now reside – in the cloud. This can be accomplished through the use of remote or virtual desktop services, where a Windows installation effectively lives in the same cloud environment as your server workload and is accessed by your users on their local PC through a terminal shell. If set up properly these environments should act and function the same for your users as if they were running the application directly on their local PC. In the best case, they leverage a pre-configured service such as the Azure Virtual Desktop, which removes all of the complexity around setting up and maintaining this type of environment on your own.

File Shares and File Servers

Often overlooked during cloud migration planning exercises are office file servers or file shares. While a lift and shift migration will function in most cases, many users will often experience performance issues similar to those described with a client-server application, particularly if the files being stored or accessed are large. In most cases, businesses engaged in a datacenter modernization exercise have already moved their productivity workloads over to a cloud provider such as Microsoft’s Office 365. In these instances, they often already own technologies such as SharePoint and OneDrive which can be used to modernize how they work, interact and collaborate with their co-workers. Migrating your file server to these services can remove the requirement to have a file server at all, saving your business money while enabling your business to modernize.

Alternately in cases where SharePoint may not be the best fit, services such as Azure Files may again save you money and reduce the requirement for ongoing operational management.

Dependencies, Dependencies, Dependencies!

Beyond understanding your applications and your data, the one item that often causes cloud migrations to fail is dependencies – specifically unknown dependencies between different pieces of your environment. For example, moving your file server to SharePoint will break any applications that may have hardcoded file paths pointing to existing drive letter shares. Similarly, if you have Excel spreadsheets that link to other spreadsheets or sources of data using similar file path methods these will break as well.

Moving applications to a remote desktop environment may solve client-server performance issues, but if the application is licensed using local hardware identifiers such as network MAC addresses, it won’t function without some additional effort – or potentially at all.

Using tools such as Azure Migrate can help automate the discovery and assessment process for your applications and data including inter-server dependencies.

Join us next week as we dive into Step 2 of 6 Key Steps to A Successful Microsoft Azure Migration: How to ensure accurate sizing.