Moving Legacy Applications to the Cloud? Make Sure You Do It Right

SaaS deployments make up nearly half (49 percent) of all cloud investments, according to the latest installment of the IDG Enterprise Cloud Computing study.  But while IT departments are understandably eager to begin reaping the benefits of the cloud, some have learned that traditional “lift and shift” techniques aren’t the smartest way to move their legacy applications over.

Instead, think of an SaaS deployment as an opportunity to de-clutter your applications – just like you might decide to clean out your attic before moving across the country. Bloated or inefficient on-premise applications will still be bloated and inefficient in the cloud if you don’t take the time up front to clean them up or throw them out entirely.

So, particularly with older applications, take the opportunity to de-clutter before migrating them.  

While newer and externally facing applications are prime candidates for the cloud, most of your de-cluttering work will be performed on legacy applications. Not all those developed in a pre-cloud era will even run in the cloud. Does the cloud provider support the OS that your app was developed for? If not, it won’t work.

Even legacy applications that are supported won’t necessarily work well without a bit of tweaking to take advantage of the native features of the cloud platform you use.

Also, consider that legacy applications were created to run on a single server – not in the vast server farm that is the cloud. Those applications need to be able to work in the cloud’s clustering scenario; if one node gets taken out of the picture, and the app fails over to another physical or virtual resource, you don’t want the app to break.

Noah Slater, a blogger for PaaS tools company Engine Yard, recommends “fooling” these applications into running in a stateless environment by freezing their local configuration. Once the state is frozen, the application can be deployed to a single server or thousands, he writes. That’s because regardless of where the app is running at a given moment, the configuration files it accesses will be the same.

While it seems a shame to expend resources cleaning up old application code, you might create more work at the other end if you find out the software you just migrated requires further integration efforts. In other words, the cost of broken or degraded applications might be greater than the cost of tuning the apps in the first place.