The rationale to move towards cost effective private cloud to reduce cost and improve the flexibility to dynamically use the hardware resources and elastically define the infrastructure architecture are defined in the earlier post.   Applications running in the current environment must be migrated to new private cloud to realize the benefit. To illustrate the thought process, the source platform is assumed as a stand-alone HP-UX and AIX platform and target platform is virtualized Intel processor based chassis managed by VmWare ESX cloud operating system.

Migration steps are given..

1. Check the applications in the landscape uses COTS (Commercial Off The Shelf) product). Verify from the vendor, the COTS product is supported in the VmWare environment.  If COTS are not supported in the VmWare environment, understand the vendor’s product road map and see if there is any VmWare support in the horizon. Explore ASP model for COTS model.  If it is not feasible, then follow the exception process. (An organization should define an exception process to deviate from private cloud)
2. Study the technology stack of current application landscape. Verify the technology stack can run in the new host operating system (Linux or Windows).  For instance, if an organization runs the application server BEA WebLogic in HP-UX, in this step, verify if BEA web logic can run in Linux or windows.  There are some technology (like Oracle DB) does not support or perform in VmWare cloud operating system. When a technology is not supported, it is an opportunity to consider that technology for migration to a comparable technology with lower cost and risk and higher or equal benefits.
3. Even when a current commercial technology stack (like IBM WebSphere, IBM DB2) runs in VmWare platform, still perform a risk assessment of running the native technology stack instead of migration of existing technology stack to private cloud. For example, perform a risk assessment comparing IBM Websphere and native application server JBoss.  The net benefits between these technologies may be equal, in most case, there is a significant license cost differences between these technologies.
4. Study the migration cost from current technology stack to new technology stack in the cloud. For instance, study how the current technology stack (application server, database server) are currently being used. Look for any proprietary module used by applications in the landscape. For instance, IBM provided CICS transaction gateway jar files in older version of websphere. The applications in the landscape may be still using it. Watch for it. CTG jar files are not part of J2EE specification when IBM bundled with their product. Later, Java connectors for CICS are made available. If there are applications in the landscape using more proprietary modules/tools, then migration of application from websphere to JBoss will be a significant effort.  Total cost of migration must be taken in to consideration. It is a not a best practices to run any vendor proprietary technologies in the mission critical application in the landscape.
5. Repeat step 2,3,4 for all elements in the technology stack. (like database, security access management, data ware house, back office systems and etc)