Migrating data and processes to the cloud…we talk about it all of the time. We manage the process for clients as a matter of course. It sounds simple, right? Not necessarily. A project’s relative simplicity or complexity depends (as always) on myriad factors, making one client’s cloud migration strategy different from the next. But just what are the ways a company can move applications into the cloud?
The 6 “Flavors” of Cloud Migration
TechTarget defines cloud migration as the process of moving data, applications, or other business elements from an organization’s onsite computers to the cloud—or from one cloud environment to another. As we suggested, this process is fairly straightforward for some projects while others are stunningly complex.
Back in 2011, Gartner identified five ways to migrate applications to the cloud. Amazon Web Services’ Medium puts another into the mix (to be fair, it’s “doing nothing,” but that, too, is a strategy). Let’s take a closer look, so you’re familiar with the various terms as you embark on your journey to cloud transformation.
- Rehosting (aka “Lift and Shift”)
This strategy is essentially moving your applications—as-is, with no modifications to their architecture—to a cloud infrastructure hosted on virtualized, remote hardware. Think of it as Infrastructure as a Service (IaaS), or using the cloud as a new data center. It’s not particularly scalable, but it gets you “into the cloud” rather quickly and easily.
This strategy entails running your applications on a cloud provider’s infrastructure so it can be re-architected and developed using cloud native features. Referred to as Platform as a Service (Paas), this process provides the cloud-computing advantages of cost-savings and scalability, but as explained by Gartner, the disadvantages include transitive risk, missing capabilities, and framework lock-in.
This strategy is employed when legacy applications need more extensive code modification—to be made more “cloudlike”—before they can be migrated to the cloud. This means the apps may end up being rehosted or refactored.
This strategy means you discard your legacy code and re-architect it on the cloud infrastructure (PaaS). This makes your app essentially cloud-native, but you’re subject to vendor lock-in.
- Replace or Repurchase
This strategy is most familiar to our clients who are adopting Software as a Service (SaaS) or public cloud solutions such as ERP and CRM suites. They’re replacing their existing, legacy systems with new, cloud-based software so their migrations involve shifting data and processes from on-premise locations to their vendors’ clouds.
- Retire or Retain
Sometimes it makes sense to “turn off” legacy apps that no one in your company is using. Other times it makes sense to stick with the status quo and do nothing—for now. This step begs the importance of looking at all of your applications and workloads to determine which are ready for migration to the cloud and which are not (and may never be).
It’s helpful to speak with professionals who can help you assess your existing IT environment and recommend next steps toward cloud computing. The endeavor certainly isn’t one-size-fits-all, and it pays to get outside support so you spend your resources wisely and profitably. Contact us to learn more about how we can help—and let’s get a conversation started.