Azure Migration: From Cloud First to Cloud Now

Suggested audience for this article

I see two obvious candidates ...

Any organization with "legacy"

Almost all organizations I have worked with have legacy workloads, that are complex or even impossible to migrate to another platform, including another Hypervisor.

My recommendation is to consider Cloud Now as an option at the next HW refresh and at least validate the TCO before buying new HW.

Hosters

It is a fact that the Hoster market in Europe is significant with typically smaller (SMB) customers (SMB) running 10-100 VMs or other services.

Hosters are highly optimized, matured over many years and they really know their business, almost like an ART.

They are very VMware experienced and with a very high focus on cost.

With "Cloud Now", they can utilize their existing (VMware) skills and processes and at the same time open on new business areas, like security, modernization, PaaS, SaaS and with AI!

A reflection: "I (may) have misled a whole generation"

Edward Yourdon, known as the "father" of Structured Analysis from the 1970s and author of "Structured COBOL," later emerged as a pioneer in Object-Oriented Analysis during the 1990s. It is rumored that he once remarked, "I have misled a whole generation."

Reflecting on my numerous articles on Cloud Migrations (and Cloud First) over the past decade, I feel similarly. Like Ed Yourdon, I have reconsidered my stance—or perhaps gained more wisdom.

The Short Version

Over the past decade, I have engaged in Cloud discussions with hundreds of organizations, almost all of which adopted a "Cloud First" strategy. In practice, this meant Cloud was "considered" first for new workloads, while existing over time might be migrated if assessments deemed it appropriate.

My advice has always been to begin with a Cloud Assessment and then decide whether to migrate, modernize, or retire workloads based on that analysis.

However, today I advocate for a "Cloud Now" approach, recommending the immediate "relocation" of as many workloads as possible to the Cloud to quickly recap immediate Cloud benefits. The assessment can be done later, if necessary.

Cloud Now - The Relocate Option

A few facts on the on-premises estate today ...

• Most organizations - and almost all Hosters - are using VMware as Hypervisor in their On-premises estate and have invested intensively in optimizing internal processes.
• HW and SW cost is optimized by "intelligent overcommitting" their physical cores on HW.
• Workloads are "relocated" every time HW is refreshed, using standard VMware tools, without any impact on users, with no downtime, no IP changes, no user test needed and as a result business owners are typically not even asked or informed, except for the most mission critical workloads.

As AVS (Azure VMWare Solution) is running the same VMware platform, that people know and love, it is as simple to "relocate" - do a "Hypervisor Lift & Shift" - to Cloud as it is to migrate to new HW.

AVS = Azure VMware Solution

In other words, you can reuse existing experience, processes and people and have the same benefits as mentioned above.

The Assessment Trap

I have always recommended to start any Cloud Transformation with a "5R" Assessment to decide which workloads to Retire, Rehost, Replace etc. - see more details on 5R below.

I still believe an assessment is a very valuable exercise and that it will have a positive ROI, primarily driven by the fact that many workloads/servers (50% or more) can be decommissioned/shut down because they are not used or have very limited business value.

However, my experience is that very few organizations make it beyond a limited assessment - and very few - if any - workloads made it to the Cloud.

Reality is that even in mature organizations even many business critical "legacy" workloads are so old and complex that very few people, if any, have the insights to make an informed decision based on an(y) assessment. We see many workloads where the developers or even source code are "gone".

The business owners - if known - will typically not even engage and will by default say NO to any change - the good, old "If it works, don't touch it".

If it works, Don't touch it!

The business owner will always say NO if the migration has any risk, like an IP change, or if downtime or user acceptance test is required.

And to be fair, it is understandable as the change will in most cases not have a positive impact on the app. Best case is "Status Quo", so why take any risk?

The Legacy Apps

Based on lots of experience, these are facts the "legacy" workloads ...

• The majority will never be "modernized", they will just run until they eventually die, typically when replaced by something new, like a SaaS or new "home-made" solution.
• They will live much (much!) longer that anyone expects today, like 5-10 years. Just look at the many apps still running on Windows/SQL 2008 - or even 2003.
• They are often tightly (and undocumented) integrated with other workloads and even a simple IP change for a legacy app may cause significant and complex changes in firewall settings across the estate - and high risk for errors.
• They represent a significant security risk and even though Cloud in no way is the "silver bullet" to fix this, Cloud will offer lots of opportunities for better protection, resilience, redundancy and even offer extended support for older versions of Windows Server and SQL Server.

The Compelling Event: HW refresh

Every Cloud transformation starts with a business case and as Cloud will add cost, it will typically require a compelling event with potential cost savings to make the business case positive.

The most obvious compelling event is at the time of a HW refresh, but it could also be a decision to shut down existing data center(s) or similar.

Reality is that the most "Cloud First" ready organizations fully understand the obvious Cloud benefits like elasticity, security, sustainability, evergreen, automation (IaC), SecDevOps etc. but consider these "soft" benefits and will only start a Cloud journey if the business case is positive, based on "hard" savings vs the Cloud transformation and operational cost.

The AVS Business Case

Note that a business case with AVS is very different than for a transformation to Azure Native ("Rehost") as it is more similar to buying new HW.

AVS vs new HW - It is all about the TCO per "core"!

The business case - or TCO comparison - includes many VMware elements like overcommitment as well as unlimited virtualization of Windows Server and SQL Server and even SPLA (Service Provider License Agreement).

Feel free to reach out if you need help.

Candidates for Cloud Now - with AVS

I see two obvious candidates ...

Any organization with "legacy"

Almost all organizations I have worked with have legacy workloads, like described above.

My recommendation is to consider AVS as an option at the next HW (or SW) refresh and validate the business case.

Hosters

It is a fact that the Hoster market in Europe is significant with typically smaller (SMB) customers (SMB) running 10-100 VMs or other services.

Hosters are highly optimized, matured over many years and they really know their business, almost like an ART.

They are very VMware experienced and focused with a very high focus on cost.

With AVS, they can utilize their existing skills and processes and at the same time open on new business areas, like modernization or SaaS and with AI!

The 5R Model (or here "8R")

Gartner introduced the 5R Model already in 2010 in the article "Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?".

I have worked intensively with variations of this "5R Model" since 2015, currently with "8R"

1: Retire (aka "Shut down")

Decommissioning the application because it is no longer needed or has been replaced by another system.

2: Retain (aka "Do nothing")

Keeping the application in its current environment without making any changes. This is often done for applications that are not ready to be migrated or have specific compliance requirements.

3: Relocate (aka "Hypervisor Lift and Shift")

Moving the application to a different physical location, such as from one data center to another, without making any changes to hypervisor or its architecture or code.

Example: Moving from VMware on-premises to Azure VMware Solution (AVS)

4: Rehost (aka "Lift and Shift")

Moving the application to a new environment (and a new hypervisor) without making any changes to its architecture or code.

Example: Migrating from VMWare on-premises to Azure Native.

5: Replatform (aka "Lift and Reshape")

Moving the parts of application to a new platform, such as a different operating system or cloud provider, with minimal changes to take advantage of the new environment.

Example: Using Azure SQL PaaS instead of SQL on a VM.

6: Refactor (aka "Rearchitect")

Making changes to the application's code to improve its structure, performance, or maintainability without changing its external behavior.

Example: Modernize applications from IaaS to PaaS

7: Replace (aka "SaaSify")

Replacing the application with a new one that provides similar or improved functionality.

Example: Migrate to a SaaS application

8: Rebuild (aka "Rewrite")

Build the application from scratch to take advantage of new technologies or to address fundamental issues with the existing system.

Example: Build a new application from scratch

Final words from the Author

This was written with strong support from my Copilot "Coauthor", and significantly faster than I would have been able to do it alone, especially for a non-native speaking/writing English person like me.

However, every word, every sentence, every recommendation and every hypothesis are mine -and mine alone.

Want to hear more, have feedback/suggestions or need help?

As always, I am very interested on your feedback. Please feel free to add a comment to this article or reach out to me ([email protected]).

Last, but not least: If you are ready to migrate, have questions on AVS or need help for a business case at the time of a compelling event, you are always welcome to reach out to me.