A cloud migration strategy must align to business and financial goals—migration is a business decision first, and a technical decision second.
There are many migration options. The correct choice reflects the environment you are moving from and cloud solution you are moving too.
Technical characteristics limit some migration options. A legacy app with no cloud-aware capabilities isn’t a candidate for lift-and-shift—if you can’t “lift” you certainly can’t “shift.” An organization with a large private cloud VM-dominated footprint is primed to shift over to Azure VM. The end user may have no idea that a migration even happened—nirvana for corporate IT.
A cloud migration strategy flexes in the face of multiple options. Simple migration decisions are self-evident (e.g., legacy apps that have been marked “retired” but are still being used will actually—finally—disappear after a cloud migration. Win-win). It’s the gnarly ones (where there are either too many good options or nothing but bad ones) where organizations need strategy scaffolding.
We’ve outlined the different patterns for migrations we’ve observed, along with their individual advantages, and average predicted costs.
Download: 5 Steps to Prepare Your Cloud Migration
OS, CPU, Disk, Memory, Performance Utilization
~20% overall savings when you do a complete Total Cost of Ownership (TCO) comparison to running these applications in the data center.
A complete TCO delivers a five-year, forward-looking model—accounting for CapEx of hardware growth and refresh, operational overhead of real estate, hosting fees, power/cooling, headcount, and software/hardware support contracts.
Rehosting, like network discovery, is a solved problem.
There are many proven methods (some slow, some quick) for moving Windows and Linux workloads from point A (your data center) to point B (your cloud provider) using third-party tools that have competed themselves down to a reasonable commodity price point.
In general, rehosting is your most affordable option.
OS and/or Application Data
20% as you shed more operational overhead and/or licensing costs. Less application and/or operating systems maintenance overhead means lower software costs.
This sometimes can cost a bit more than rehosting as you must reload applications onto new operating systems or convert databases into new engines. There are tools out there for database migration, including AWS Database Migration Service and Oracle GoldenGate.
Open-source applications that can be replaced with an off-the-shelf cloud application in a more elastic design.
Normally based on a business case, when some SaaS company provides a superior product/service to anything you can run yourself (e.g., Salesforce, Office 365).
More features, flexibility, and stability than you have from an in-house supported solution, and significantly less overhead to operate.
The costs here are less about migration and more about the cost of changing your business to leverage the new application. As business needs vary greatly, this can be difficult to quantify.
An application that, either from a code or architecture perspective, can be changed to leverage cloud-native services and features.
Write all the code for an application in-house, and you can probably refactor it for cloud.
Use a collection of standard open source applications, and you may be able to swap for cloud-native services, such as NoSQL, Queueing, RDMS, Storage, etc.
A highly scalable and resilient application or service that quickly adopts new technologies while allowing you to continue to innovate.
Refactoring is usually done with the objective of becoming more elastic and resilient—all while delivering better economics.
Operating an elastic application in the cloud can save you upwards of 70% versus the legacy model of architecting for the high-water mark of utilization, a mark that you might only hit a few times per year.
Refactoring is the most expensive part of a cloud migration.
Customers often bring in partners who have a lot of experience in refactoring to gauge the effort level.
Refactoring also takes longer as the skill set is hard to duplicate — and if you have a lot of applications to refactor, you end up doing more in serial than in parallel.
Your business case and cloud strategy should dictate where the ROI point is, in time, on the post-refactor cost savings against the time and cost of refactoring. Having a tool to ingest this data and visualize the break-even point is key.
For customers looking for a very near-term ROI, they may not have the business tolerance for a refactor-heavy migration.
Download: 5 Steps to Stop Chaotic Cloud Spend
After you determine a migration patterns, build a financial model that mixes cloud and data centers together in a hybrid strategy.
A cloud migration starting with one workload expands to others—the migration pattern that applied to the first may not apply to the second. Agile development workloads benefit from moving to the cloud for resourcing concerns, and the exposure to innovation—without being on the hook for paying for that investment up front.
Some workloads are primed and ready to move to the cloud—often driven by the business demanding “asking” for cloud solutions. Others, like infrastructure, in the short term at least, maybe best left alone and remain on-prem.
A hybrid IT strategy acknowledges that being able to go to the cloud doesn’t you should must. At least not yet.
Born-in-the-cloud organizations don’t suffer the same issues as organizations that have deliberately invested in on-prem IT. There are clear operational and financial reasons to tread lightly with useable assets when you have built up business practices around on-prem solutions and still have a depreciation cycle to pay off.