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

Report Cover

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.

3. Why would we move this application outside its life cycle?

The biggest pushback will likely come from the guardians of the application life cycle. In the data center model, applications are identified, architectures defined, and hardware and software procured -- then comes the agonizing manual labor of loading and configuring, which can take a week or more. In the cloud, there's still agony in loading and configuring, but instead of grunting over individual servers, the heavy lifting is associated with building templates and scripts that will auto-build, or orchestrate, servers and apps.

Your application life cycle guardians will remember well what an effort it was to configure the servers for that legacy system. Though they may smile politely while you unveil your big cloud plans, as soon as you reveal that those plans involve destroying their servers and rebuilding them off-site using templates and scripts, the conversation is over, in their minds.

This isn't always the case, but the point is that IT leaders think, "No big deal. Just write some scripts and templates and move the app to the cloud." Application and infrastructure teams often view this quite differently and will push back that the app shouldn't be moved outside of the life cycle. Frankly, it's hard for a CIO to argue with that, especially when teams point out the amount of effort required. Yet if we wait until the end of life for applications that may hang around for a decade, we lose much of the benefit of cloud, and for what?

4. We'll end up locked into some cloud provider.

There are many ways to migrate an application to the cloud. Some involve consultants, manual processes and being melded to a cloud provider. However, there are tools to help avoid lock-in while bringing the benefits of automation.

You can follow the lead of The Associated Press, CBS Interactive, Zynga and a slew of sophisticated startups: Use a platform such as RightScale, Scalr or enStratus that abstracts complexity. These systems provide management and orchestration and are typically built around components of on-the-fly provisioning technologies, such as Puppet and Chef.

Using a platform like RightScale requires a completely different way of thinking than what enterprise app teams are accustomed to and, to be fair, while these management platforms have templates for building things like SQL Server, you won't find templates for most legacy applications. Your app team will have to build these, and, as we've said, it's just about as much effort as creating the server farm in the first place. Don't expect people to be excited about this, particularly because there are new technologies to be learned and new obstacles to overcome, such as creating a virtual private cloud or dealing with a new and borderless server architecture.

Another issue that tends to bring IT pros outside their comfort zones is when outside services require internal resources. When a customer used CliQr to deploy a .NET app into a cloud provider's infrastructure, the question of how to print on site came up. The answer was to use a CliQr feature that allows for service proxy of given services -- no VPN was needed. Creativity is required.

5. It's not broken, so why the heck risk a security breach?

To paraphrase Dilbert, do you trust a vetted cloud data center with a crackerjack security team and a CSO who used to be with the FBI more, or the programmer who's been outsourcing his job and sending his physical authentication token to China via VPN?

In shops with hundreds or thousands of apps that are working just fine -- apps that people like, that are reliable, that provide benefits to the business -- there's no compelling reason to burn it all down and rebuild it in the "cloud way." But make no mistake: Today's rich IaaS provider ecosystem means low prices and little risk of lock-in, and automation means you can quickly provision systems to meet your organization's needs.

So start now, and be pragmatic with legacy apps. If you sit back until applications run their natural life cycles, you'll be waiting a long time.

How Cloud-Based Apps Measure Up: chart

InformationWeek: Mar. 18 2003 Issue

Download a free PDF of InformationWeek magazine
(registration required)