I described in my previous two blogpost the stepped approach to evolve towards cloud. In the first post I described on how to make the inventory of workloads in your organization. In the second post I described (a) how to prioritize the workloads to determine the best candidates for cloud and (b) how to determine the destination of the workloads in the cloud. Let me now take you through the next two steps.

4. Determine the migration path

Migration of a workload from a traditional IT delivery model into a cloud delivery model can be done in several ways. To do so, we determine the migration path for each workload individually. Each workload can migrate through one of the following four paths:

(a) A first path is to start with the externalization of the traditional IT platform towards an Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) environment. This will primarily makes costs more transparent, utilization more variable, free skills to enable focus on supporting the business, and shift from a capital spending model to an operational spending model. Later on the workloads can be moved to a higher level of virtualization, towards Software as a Service (SaaS) or even up to Business as a Service (BaaS). This migration path might be easiest, but is tending to be slow before you move to a higher level of virtualization.

(b) A second path is to start with an internal private cloud, typically a path that will be used by very large organization and also applicable to manage constrained workloads (see step 1). This path consolidates workloads across the organization, leading to an internal standardization. It enables the increase of the level of virtualization and prepares to provide internally a service as a Business (BaaS). If the level of Business as a Service (BaaS) can be achieved then you created an internal service center. Once workloads are moved on private cloud, they are standardized and can be benchmarked with comparable services available from third parties.

(c) A third path is to move an application directly to a Software as a Service version of the already used application. This path is only applicable when (a) the application installed in a traditional IT environment is available as a service and (b) the workload is not constrained (see step 1).

(d) A fourth path is to replace the currently used application to an alternative application that meets the business needs.

The graph depicted below retakes the two axes from the previous step 3 and illustrates the four paths towards cloud. The first path (a) is depicted on the lower right hand side, the second path (b) is depicted on the left hand side, the third (c) and fourth (d) paths are depicted in the middle.

The choice for the migration path must be based on multiple criteria, such as: availability of a service in the cloud, flexibility in scaling and choice of service, cost level and cost transparency, impact on the organization (skills, allocation, and budget), maintenance contracts in place, infrastructure lifetime, etc.

The latter two migration paths are faster, these paths are commonly used to start moving ‘commodity like’ applications to a cloud service, which is frequently triggered by a license renewal of the software or by an upgrade to a new major version of the software.

The outcome of this step is table of workloads, with for each workload a strategy on how the workload will evolve over time towards the cloud (if applicable).

5. Validate ability to exploit cloud storage

The current storage environments must be analyzed in the same way as done during the analysis of workloads. Let us take a look at ephemeral storage, persistent storage, and object storage.

The ephemeral storage needs are directly related to the application and must be covered together with the evolution of the application; given this strong dependency we will not further elaborate on ephemeral storage needs.

The persistent storage covers the need to retain application data beyond the life of the compute infrastructure. Persistent storage needs is frequently used by a certain workload, or is used among multiple workloads. Persistent storage is available as a cloud service, being private, hybrid, or public. The analysis must be made as done for the workloads.

The object storage covers the need to store large amounts of data, with high availability, but limited performance. The object storage is used for example for backup, archives (e.g. document retention storage), global data distribution, or geo-replication for disaster protection. Also object storage is available as a cloud service and must be analyzed as done for the workloads.

The outcome of this step is table of storage needs, with for each need a strategy on how this will evolve over time towards the cloud (if applicable).

In my next blogs I will further elaborate on the next steps towards cloud. Come back soon!