A four-phase approach to migrating to the cloud
IT professionals the world over crave simplicity and order when migrating enterprise applications to Microsoft Azure. Just as the business and technological benefits of a successful cloud transfer are clear (agility, cost, assurance, etc.), so too are the perils of a mismanaged move (impaired scalability, loss of data, business interruption, etc.).
Azure is Microsoft's cloud computing platform used for building, deploying, and managing applications and services via a global network of Microsoft data centres. It includes an ever-growing collection of integrated services related to analytics, databases, identity, and storage management.
A four-phase approach to an Azure migration that takes into account any and all application data handling requirements, security, and compliance variables is the following:
Phase 1: Assess Cloud Readiness
There are very few tools on the market for assessing an application’s cloud readiness. It is therefore best for users themselves to measure four key attributes of an application to determine its compatibility for Azure:
The state of the technologies underpinning an application—the hardware, operation systems, application server subsystems, and actual build code (all in all, the “platform”)—will dictate how flawlessly an application can migrate.
The clash between traditional application data storage options and relatively more modern systems like NoSQL creates mismatches in IT landscapes that must be harmonized before digital assets are pushed to Azure.
Azure will benefit users insofar as they have sufficient network bandwidth to perform accordingly. Make sure to have solid service level agreements in place with providers before pulling the trigger on a cloud migration.
Security and Compliance
Though major cloud infrastructures like Azure are afforded considerable resources to outfit their data centres for optimal security, applications must nevertheless be built with effective identity management, access control, and managed security offerings to safeguard users on Azure. Consistent and continual application risk assessment is critical to operating in the public cloud.
Phase 2: Plan Azure Migration
The more thorough your application cloud readiness assessment, the more reliable your overall migration planning strategy. Experts advise charting a plan (or, rather, setting a go-to-cloud target) around three distinct options: (1) “lift and shift”; (2) application evolution; and (3) application rearchitecting.
Lift and Shift
“Lift and Shift” is the cloud migration strategy for replicating on-premise environments as closely as possible in public clouds. Examples include designing the same networking environments; uploading virtual machine images from each server; and enabling connectivity to and from the various virtual machines in a manner nearly identical to the physical environments.
There’s a good chance your application won’t need to be completely re-designed to conform to Azure. If you’re lucky, there will be many elements to applications that need only linear upgrades (e.g., Microsoft SQL to Azure SQL; Office 365 identity management to Azure Active Directory). Locate areas requiring minor configuration changes to save time and energy (while also freeing up budget…).
Designing applications as “cloud-first” is not the challenge it once was. If your applications do require re-structuring to align with Azure, the Azure Container Service and corresponding features such as the Azure App Services (a way to quickly build, deploy, and scale enterprise-grade web, mobile, and API apps for any platform) will simplify the design of integrated cloud application architectures.
Phase 3: Prepare for Cloud Transformation
An enterprise's Azure migration will doubly need a solid Proof of Concept (“POC”) and a Pilot Test to convince stakeholders of its merits. The objective of both is to expose, in clear terms, how Azure will (or won't) change the operation of the business.
A valuable POC can bring about consensus among stakeholders to eliminate any ambiguity in regards to how to launch a transformation. For example, if resources are to be shared across network connectivity (say, in the case of a hybrid application), a POC proving the connectivity between Azure regions and the home office will be valuable.
Furthermore, a Pilot Test lets users observe and interact with the new system—albeit, on a reduced scale—to locate potential hazards. Demo environments might include a single web server, a single application server, and a single database instance. Though a pilot demands more effort than a POC, it offers a much greater chance of user participation and project transparency.
Phase 4: Migrate to azure
A migration is finally undertaken during this phase. Depending on how you and your team evaluated and planned your enterprise applications, there will be a potential to utilize automation capabilities (tools, templates, and processes) to minimize efforts.
Azure’s Resource Template Technology allows you to migrate infrastructures and services in a reusable format to speedily execute migrations at will. Such automation tools can be tweaked to specification, too.
As you move workloads to Azure, keep track of all affected stakeholders and systems using Modern Enterprise Architecture Management methodologies like Tag Groups, Service Lifecycle tracking, and Fact Sheet subscriptions.
There are many moving variables to consider when plotting a migration to Azure. Knowing if your enterprise applications—and, to a greater extent, your entire organization—are compatible on the cloud will depend largely on the strength of your evaluation criteria and how thoroughly it is applied.
Consult with trusted digitalization experts, and don't blindly accept one-size-fits-all migration strategies. Use this four-phase approach as a way to temper aggressive decisions.
For more information on transitioning to the cloud, read the below White Paper, "How Enterprise Architecture Management Paves the Way Into the Cloud".