SaaS deployments make up nearly half (49 percent) of all cloud investments, according to the latest installment of the IDG Enterprise Cloud Computing study. \u00a0But 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.\n\nInstead, think of an SaaS deployment as an opportunity to de-clutter your applications \u2013 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\u2019t take the time up front to clean them up or throw them out entirely.\nSo, particularly with older applications, take the opportunity to de-clutter before migrating them.\u00a0\u00a0\nWhile 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\u2019t work.\nEven legacy applications that are supported won\u2019t necessarily work well without a bit of tweaking to take advantage of the native features of the cloud platform you use.\nAlso, consider that legacy applications were created to run on a single server \u2013 not in the vast server farm that is the cloud. Those applications need to be able to work in the cloud\u2019s clustering scenario; if one node gets taken out of the picture, and the app fails over to another physical or virtual resource, you don\u2019t want the app to break.\nNoah Slater, a blogger for PaaS tools company Engine Yard, recommends \u201cfooling\u201d 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\u2019s because regardless of where the app is running at a given moment, the configuration files it accesses will be the same.\nWhile 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.