by Anthony Koochew
Founder & CEO
Anthony is an Architect with over 15 years experience helping clients realise the most value from Microsoft Azure, Office 365 and EMS. View full profile.
We are seeing more businesses with Private Cloud consider the benefits of an Azure migration. Often, the challenge behind Private Cloud is its overwhelming focus on servers, not services. In the era of Cloud, businesses that aren’t taking advantage of the services available are limiting themselves.
Whilst Private Cloud may always play a role for some organisations, the case for Public Cloud becomes undeniable as a business plans for growth and prioritises future-proofing and support for modern app development. When it comes to these two business outcomes, only the largest Public Cloud providers (“hyperscalers”) are up for the challenge with their cloud-native PaaS and DevOps capabilities. Throw in the economies of scale that Azure delivers and it will almost always be cheaper, faster and easier to run than a Private Cloud equivalent for modern workloads.
Why do businesses choose Microsoft Azure?
Once a business has realised its days in Private Cloud (usually IaaS) are numbered, the two leading reasons they will consider an Azure migration service are:
1) an existing investment in Microsoft (software and resources) and
2) the inherent ease of migration.
This is made more compelling by Microsoft’s offer of extended support for EOL Windows Server and SQL workloads. Likewise, the greatly beneficial commercial terms of Azure Hybrid Use Benefit (AHUB).
Which services in Private Cloud should I migrate to Microsoft Azure?
Whilst the possibilities seem endless in Public Cloud, many customers simply aren’t ready for the full “infrastructure as code” or IaC revolution of their environment using entirely cloud-native tooling. Most customers foray into Azure from an IaaS environment, so they undergo a mixture of rehost, refactor and replatforming as part of the Cloud rationalisation process.
Rehosting: The migration of a virtual server or appliance into Azure in a like-for-like manner, making minimal changes to the server as part of this process. An example of this would be the migration of a Server 2016 instance to Azure. Most components will stay the same, except networking and supporting services (such as backup, DR, monitoring and management). The core operating system and application environment on the server will remain unchanged.
Refactoring: The act of “rehoming” parts of an application into their Platform as a Service equivalent. A common example is the removal of a database from a SQL server and the reconfiguring of the application to point to Azure SQL as the new location for the database. Refactoring often results in a service that is cheaper to run, easier to manage and simpler to scale.
But if the advantages of refactoring are so clear, why not refactor every application? Well, not all applications can be refactored. For some, it doesn’t make commercial sense to alter the underlying system if it’s already running in a cost-efficient manner. Whilst other applications might require a specific function that isn’t available in PaaS (requiring a change to the code to support) or a vendor doesn’t offer the support for their service operating within a PaaS context.
Alternatively, some of these refactoring candidates may be better suited to their SaaS alternative, as SaaS requires even less effort to support and manage than PaaS. An example of a PaaS candidate that would be better suited to SaaS is a file server being relocated to SharePoint Online or Azure files. For many customers, they are already entitled to a significant amount of storage within SharePoint online and OneDrive for Business that are ideal for those corporate files or personal documents.
A key point for those considering Azure migrations is that a move to SharePoint Online will require a change in how people manage and access documents. This means change, and change requires time and training to execute.
Replatforming: Migrating a service, in part or total, to a Software as a Service (SaaS) alternative. Replatforming makes perfect sense as why rebuild what is already built when excellent prebuilt alternatives exist? It is often considered as it can be more cost-effective, offer a broader solution set and shift the management of base infrastructure away from internal teams.
Moreover, if a software vendor has made the strategic decision to lead with their SaaS offering (such as Microsoft 365) there simply may not be a viable on-premises alternative that isn’t a bundle of disparate solutions lacking in key features or functionality. Meaning, you may be forced to use their SaaS offering due to the lack of a viable on-premises alternative.
How do I migrate from Private Cloud to Microsoft Azure?
Phase 1
When planning an Azure migration, begin by identifying the servers or services that are going to be moved:
- services that will be removed before migration
- services that will be migrated to their SaaS alternatives
- servers that will be refactored to better leverage PaaS
- services that will be rebuilt entirely new within Azure
- servers that will be rehosted “like for like” into Azure
At this point, a great deal of time is spent identifying applications and reliant functions (such as email relay) to ensure the server will function as expected within Azure. A common function we take for granted in on-premises or Private Cloud is email relay. Email relays (port 25) are blocked in Azure and you have to use a different means (and port) of sending email out of Azure.
Phase 2
Once the servers moving into Azure (and their form) have been identified, the next logical question becomes ‘how?’. The order and sequence of a migration is largely dictated by business drivers. Drivers like the criticality of a system/s, business cycles (such as busy periods where change freezes are enacted), cutover window(s) duration, and availability of customer resources all inform the migration process.
Phase 3
Congratulations, you’re here! This is where the fun begins with Azure. I encourage a mentality of “cloud-native first”, not dissimilar to the old “virtualise first” mentality when we first introduced virtualisation into environments. Your first priority within Azure is to right-size and apply savings plans or reserved instances, optimising your spend and setting yourself up for ongoing success within Azure.
An Azure migration may seem large on the surface, but it’s really only one step on your journey into Public Cloud. Once your data is in the cloud and you have the correct mentality, you can start to leverage all the tools and platforms at your disposal that you previously only dreamed about. OpenAI models? Serverless? Security tools? Enhanced reporting? Disaster Recovery? All in the cloud and ready to be deployed when you are. The promise of Azure begins humbly but exponentially expands as you progress along your cloud journey.
Want to learn more about the process of Public Cloud adoption? Visit our Azure migration service webpage for our SOAR into Cloud framework.
