Moving Legacy Apps To The Cloud

The idea that you should wait until you're ready to update a legacy application before moving it to the cloud is frankly crazy. With portfolios of hundred or thousands of apps, CIOs must take advantage of the economies of scale cloud computing delivers. Trust us, the startups gunning for your customers aren't being held back by a circa 1992 CRM system.

Don't get us wrong. The question isn't, "Can all legacy applications live in the pure and fluffy cloud?" Clearly, the answer is no. But can many legacy applications leverage at least some of the technology advances inherent in infrastructure-as-a-service? The answer to that is yes, certainly.

Note that "Can this legacy application shift to SaaS?" is a different and less interesting question that hinges on whether a given software provider can revamp its business model and provide a specific application as a service. This ain't Salesforce; it's "Can SAS provide SaaS?" One interesting finding of InformationWeek's 2013 State of Cloud Computing Survey, which asked 446 business technology pros about their cloud use, is an eight-point drop in the percentage of cloud adopters using SaaS.

It turns out that many independent software vendors aren't equipped to meet the demands of today's enterprises. Their infrastructure costs tend to be high and their response times poor because they're not running IaaS -- they're running multitenant, big-box, hosted infrastructure in one or two data centers. Because it's "as a service," they call it cloud, but it's really not. It's hosting. If the price point and features work for you, great. But our experience is that ISVs turned hosting providers tend to charge more and deliver less.

True IaaS providers deliver savings, agility and scaling benefits. So why do IT shops run so many applications on their own servers? "Part of the reason you don't see apps aggressively moving to the cloud is because of the refresh cycle," says Josh Crowe, senior VP of product development at Internap, a content delivery network and cloud hosting provider.

Informed CIO: Moving Legacy Apps to the Cloud

Our report on deciding when to move an application to the cloud is free with registration.

This report includes 16 pages of action-oriented analysis. What you'll find:

• Eight steps to move a legacy CRM system to the cloud
• A sneak peek at our 2013 State of Cloud survey data

Get This And All Our Reports

In short, IT teams have other stuff to do, and they're content to wait. But CIOs need to push back, given the benefits to be had. Here are the top five objections to moving apps to the cloud and our suggested responses.

1. Our legacy applications are too complex to move to IaaS.

Erik Sebesta, CTO of Cloud Technology Partners, a professional services firm, says he sees plenty of companies "taking legacy spaghetti and making it cloud spaghetti." We would argue that most complex applications started like those 100-foot, perfectly wrapped cords you bought six months ago at Home Depot. Over time, they all end up as spaghetti, thanks to moves, adds and changes, so set your expectations accordingly. By transitioning away from in-house infrastructure, most companies can save money, but don't insist that the deployment be elegant.

How much can they save? Sebesta says his firm helped a large telecommunications organization move off expensive legacy hardware that wasn't well utilized and recoup more than $20 million annually.

2. It won't save money because we still have to run a data center.

True, you probably won't shutter your data center. However, there are three compelling scenarios from a cost perspective that CIOs who want to take advantage of sophisticated cloud capabilities can cite.

>> A combination of private and public clouds to do cloud bursting. You keep the ability to host internally and realize savings over a 100% cloud approach, while still being able to scale up for usage spikes. If you've ever paid the bill for running an app 24/7 in Amazon Web Services, you'll appreciate this model. In fact, some n-tier architecture enterprise apps are just about ready to support cloud bursting, though customization may be needed to programmatically monitor, load and request more servers from the provider when needed. Select target applications carefully. Customer-facing apps are much more likely than internally focused systems to need elasticity.

>> Business continuity and disaster recovery. Look at your budget and you will likely see one of two things: massively expensive operational contingency contracts for disaster recovery for important systems, or capital expenditures for building out and maintaining disaster recovery hardware and associated data center assets, yours or hosted.

BC/DR fairly begs for the automation and pay-as-you-go capabilities offered by IaaS providers. You can spin up apps in the cloud for a fraction of the cost of your own infrastructure build-out or using a conventional DR -- or SaaS -- vendor. We recently spoke with a CIO who was being pitched by a SaaS vendor on its costly DR capabilities: "You just have to let us know a week before you test so that we have the people in place to handle it." Oh, yes, that's just what we want -- a vendor that demands warning before testing its premium-priced ability to handle a disaster.

>> Development and testing. This use case seems piddly compared with the resources expended for business continuity and disaster recovery, but over time, costs add up. Since there's always infinite demand for a free service (or apparently free, since most app dev costs aren't well aligned with or transparent to departmental spending), business units think nothing of building multiple test environments. We've seen more than a dozen for some enterprise apps. Think about being able to tell business units: "You can have as many test environments as you want for $20 per hour, each." All of a sudden you're not only reducing the number of test environments from "willy-nilly" to what's really needed, you're also likely saving considerable staff time, since setup will be far more automated.