Creating applications to run in cloud computing environments is a relatively straightforward task. Migrating existing applications to the cloud is a more daunting experience.

Applications written to run on secure, in-house servers, perhaps requiring multiple tiers and back-end systems, do not always move easily to a cloud scenario. According to Adiascar Cisneros, who spoke on migrating existing applications to the cloud at the recent Cloud Expo in New York City, there are multiple factors to consider when undertaking this kind of effort.

First, he said, the organization needs to decide if it will utilize a public cloud or create a private cloud. Private clouds usually make more economic sense, he said, but public clouds might be a better choice if the organization has a limited capital expense budget to buy servers, only needs less than 225 computing hours per month, and needs an application deployed quickly.

Benefits of a public cloud include high availability, elasticity and the reduction of capital expense, while private clouds offer better security and performance, the ability to perform compliance with policies and mandates, and already include “sunk costs” for hardware and employees, among other costs. Hybrid clouds, he said, offer the best of both worlds: high availability, scalability and elasticity, as well as secure storage and archiving.

So, once that decision is made, it’s time to take a look at the applications themselves. Which make sense to be run in a cloud? Transactional applications for a business? Perhaps. Your CRM and ERP systems? Maybe, maybe not. Each organization must decide how much of its proprietary data it wants to risk exposing to the cloud.

Cisneros, who works at business systems portability company Racemi, said best practices for application migration include four steps: assessment, staging, migration and optimization.

During the assessment stage, organizations must consider the business objectives, as well as the application’s architecture and design, and perform an analysis of cloud vendors. Some of the things you want to look at, he said, are the complexity of the application: Does it run on a single server or is it multi-tiered? Is the data centralized or does it reside on the server?

As for the cloud vendor, you need to check on performance and security. How much latency in the cloud is acceptable? Will the app run faster in the cloud? Is the data subject to compliance, or it is sensitive?

You will also need to consider the service itself: Is it dedicated or a shared tenant? How much control over your networking will you have? What are the hardware, hypervisor and operating system stacks? Each has idiosyncrasies and limitations.

During the staging step, the organization wants to prove the concept of the application working in the cloud, he said. Migration test pools must be created that mimic the cloud to which the application will be deployed, and any network changes must be evaluated here.

Finally, if it passes all these tests, you’re ready to migrate your application to the cloud. From there, you can look to optimize performance for the cloud experience, which is often markedly different from the desktop experience—especially if the application is being used more on devices than desktops once it’s deployed.

New apps for the cloud? Relative piece of cake. Moving existing apps to the cloud? Not so much.

David Rubinstein is editor-in-chief of SD Times.