pressmaster - Fotolia
Like so many things in IT, there's no one-size-fits-all approach to migrating applications to the cloud. In fact, an organization chooses its application migration path based on a range of factors -- everything from an application's age, to whether it was developed externally or in-house, will shape how it moves to and performs in the cloud.
When migrating an application to the public cloud, most IT organizations choose either the "lifting-and-shifting" approach or they re-architect the app. And while both approaches have their advantages, organizations should choose carefully when crafting a cloud migration strategy.
As its name suggests, the lift-and-shift migration takes an on-premises application and replicates that application to the cloud without modifying its architecture or design.
Meanwhile, the re-architecting approach, also known as application refactoring, involves making changes to how an application performs before moving it to the cloud. These changes can include revising source code, rewriting application APIs and interfaces, and de-coupling or coupling data. Other changes, such as designing an app to dynamically scale resources using native cloud APIs or making its database calls object-oriented, are specifically intended to maximize the value of cloud.
"You are breaking the application down to its functional components and redesigning it specifically for a cloud platform," said David Linthicum, senior vice president at Cloud Technology Partners, a Boston-based consulting firm.
The lift-and-shift model can vary drastically from the re-architecting approach in terms of time and up-front costs. While lift and shift can be accomplished in as little as a week, Linthicum said, the re-architecting process can take months -- in some cases even longer -- depending on the application and whether the work is done in-house or by a third party.
Lift-and-shift costs tend to start at roughly $10,000 per app, Linthicum said. But that number can grow significantly based on the type of application and the number of external dependencies -- i.e., on databases -- that it has. However, if organizations migrate a large number of apps at once, that $10,000 cost can also be reduced by as much as half.
"[The cost] goes down exponentially if you do maybe a hundred [apps] at a time or a thousand at a time, and we're seeing those out there," Linthicum said.
The re-architecting process changes based on the application and who's performing it, so it's difficult to gauge exactly how much that would cost an organization.
Linthicum estimated $100,000 per app would be on the lower-end for refactoring costs. Still, that doesn't necessarily mean lift-and-shift is the more cost-effective option in the long run.
Where lift-and-shift falls short
When a legacy application is migrated onto an infrastructure as a service platform with little or no modification, it can't take full advantage of one of cloud's biggest benefits: cost-efficiency through autoscaling. In the cloud, compute resources automatically scale up or down based on application demand. But most legacy apps weren't specifically designed to capitalize on that native cloud feature. So when those applications move to the cloud, they consume more storage and compute resources than they actually need, which can lead to a hefty bill.
"The idea with cloud is I can gain value and cost reduction by matching the peaks of my load to how much infrastructure I'm using," said Robert Green, principal consultant at Enfinitum Inc., a San Antonio-based consulting firm. The issue with lift-and-shift, he said, is that on-premises applications are built to adhere to peak loads. And when those apps move to the cloud, they continue to operate that way -- even if demand or usage is low.
"So, the times when I'm not at peak, which could be 80% of the day, I'm overpaying," he said.
Because of this inefficiency, lifting and shifting applications to the cloud, in some cases, can ultimately cost an organization more than re-architecting the software up-front, Green said. And sometimes, lift-and-shift is even more expensive than leaving the app on existing in-house infrastructures.
"Imagine keeping your lights on all day and all night," he said. "It's going to be more expensive than going around the house every night and turning everything off. With lift-and-shift, everything is on, all the time, 24-by-7, no matter what."
When Jonathan Feldman, CIO for the city of Asheville, N.C., started to work on a new information portal application for Asheville residents, he chose to architect that application from scratch to take advantage of autoscaling.
"The salient point is that without API control of the cloud fabric from within the source code of the application, it's not really cloud," Feldman said. "It's rip and lift, because you can't scale up and out."
Others agreed lift-and-shift doesn't always yield the cost savings one would expect in the cloud.
"We had an analytics product that was very hungry to crunch all this data and it came to a point where it was actually representing more than a fourth of all our costs in AWS, yet it was three servers out of three hundred," said Alex Witherspoon, senior DevOps and software engineer at FlightStats, a Portland, Ore.-based company providing global flight data. "And it had none of that cost [when it was] hosted privately."
Kristin Knapp is site editor for SearchCloudComputing. Contact her at firstname.lastname@example.org or follow @kknapp86 on Twitter.