Moving to the Cloud: Workload Migration

Techniques and Approaches

Joydipto Banerjee
IBM
Kolkata, India
joydipto.b@in.ibm.com

Abstract— The paper presents an important aspect of cloud
computing technology, namely migrating enterprise level
workloads to a cloud environment, without re-architecting or re-
engineering the existing applications. How readily an application
can be lifted and shifted onto a cloud platform depends on factors
like nature of the application, the type of cloud etc. In this
respect, the paper explores the methodology of migrations along
with the challenges and issues that usually acts as a barrier for
organizations trying to pursue this goal. An effort is also made to
see how the cloud migration framework maps to the cloud
Computing Reference Architecture model. Finally, a set of
migration patterns which span the continuum from legacy IT
environment to the cloud are included as a common framework
for aligning the various migration approaches developed in
support of using cloud as a delivery paradigm.
I. INTRODUCTION
Although much has been discussed about the benefits of
cloud computing and the implementation details, there still
exists some gap when it comes to giving a direction on how to
migrate an organization’s workloads to cloud environment. The
skills and technology to assess the options, costs and benefits
of different clouds intelligently, then make a selection and
execute the move may be scant or non-existent. The paper does
not delve into how to cloud-orient the existing applications
such as componentizing the solution so that individually
scalable components can be distributed to separate nodes
allowing independent auto-scaling. Instead, the focus is more
on how to move the existing applications to cloud with
minimum effort.
Organizations can typically be categorized into two broad
groups – one that have not considered moving to cloud and the
other one that have already moved to cloud. The first group
may be looking to transform their IT organization but may not
have considered migration to cloud as part of the
modernization journey, although they may very well be aware
of the benefits that cloud brings. On the other hand there are
organizations that have already adopted cloud but still need
help to move their existing applications to the new
environment.
II. CLOUD MIGRATION FRAMEWORK
Migrating workloads into cloud models is inherently an
“application centric” activity where each image/instance in the
cloud typically runs a single application workload. As such,
moving workloads to “cloud environments” need to follow a
multi-step process to get those applications running correctly in
the targeted cloud environment. First, the targeted applications
need to be identified and “segregated” from the other
applications running on that same server. Then an image of that
application, its underlying Operating System and infrastructure
management agents need to be created and added to the cloud
catalog. Finally, the image needs to be instantiated in the cloud
environment and verified to run with acceptable Quality of
Service (QoS) characteristics. The technical considerations for
a migration can be summarized as:
• Software compatibility
• Reference architecture
• Workload characteristics
• Platform dependencies
Across all of the migration patterns there are some common
themes. These themes are described here in the context of the
five phases/steps of moving workload to the cloud and form a
high level reference model. Figure 1 illustrates the phases.
Initial Implementing
Planning and
Screening the Migration
Design
and Analysis
Final Testing Tuning the
and Go-live Target
Fig. 1. The Five step methodology to Cloud Migration
A. Initial Screening and Analysis
This involves collecting key data on existing workloads,
applications and their dependencies, analyzing these data and
determining probable migration candidates. Major activities for
this phase are:
• Server Inventory Verification – Gathering information
on machine and OS type, collection of hardware and
software characteristics, establishing a baseline.
• Server Affinity Analysis - Capturing server application
dependency information to establish any undefined

978-1-4673-2371-0/12/$31.00 ©2012 IEEE

 systems, constraints, complexity and establishing the
appropriate migration move groups.
• Measuring Server Utilization - Capturing server
utilization metrics to determine source to target
mappings.
Various methods like manual and automated data collection
tools, conducting requirement workshops with stakeholders etc.
are employed to get the data for analysis. Some of the
important questions that are usually raised at this stage are:
• Will the workload run in the target cloud environment,
for example, compatible infrastructure, middleware
and operating system image?
• Will the target cloud environment satisfy performance,
availability and other non-functional requirements
(NFRs)?
• Will the target cloud environment comply with
applicable security, privacy and regulatory
requirements?
• Will benefits be realized from migration, for example,
lower ongoing operating costs, or increased flexibility
and responsiveness?
The outcome of this phase is generally identification of
workloads(e.g., Web Serving, Web applications, Business
Intelligence and Data Warehouse, ERP and SCM, Analytics)
suitable to be hosted in a given cloud environment, the costs
involved and the migration impact. The same is usually
provided in the form of ‘Application Report’.
B. Planning and Design
Once the inventory of targeted applications has been
identified and prioritized, the logical design of the applications
in cloud needs to be accomplished.This step involves detailed
planning and design of the target environment(memory,
processor, disk storage etc.) as per the given requirement. It
includes taking key architectural decisions and hardware sizing
after studying the software stacks and patterns of utilization.
The rationalization criteria considered during design and
planning activities are: Application Criticality, Availability /
Downtime Tolerance, Migration Complexity, Application
Scheduling Factors, Application to Application Interfaces,
Business Constraints. Key work-products from this phase are:
• Detailed design of the target infrastructure
• A technical solution document identifying the set of
remedial actions that are required to minimize the
implementation risk in the subsequent steps
• A migration plan that identifies sequence with which
applications/workloads are to be moved.
The target environment is chosen such that it minimizes the
amount of remediation/adjustment that needs to be done to the
application stack in order to improve the likelihood of success
of operation after movement. Once approval for movement has
been granted, a more detailed plan is developed including pre
and post migration activities, duration of any planned outage
window and interlock with any dependency owners (eg. Testers
for acceptance testing).
C. Implementing the Migration
This step is where the workloads are moved to the cloud
platform using the most appropriate technique. It involves the
following multi-step process:
1) Prepare the target – At this stage, it is important that we
have a clear vision of the target cloud environment. Depending
on wheather the landing zone is a private cloud, public cloud
or a hybrid cloud, the target infrastructure preparation is
tailored accordingly. The level of preparation also depends on
the actual migration scenario adopted(details in the next
section). However the common requirement is usually
building a virtual machine instance from one of the available
images in the target cloud catalog.
2) Migrate - Migrating/creating images from existing
workloads, or reinstalling the software stack of the existing
workload on the target cloud platform. There are essentially
three scenarios for implementing the actual migration:
a) Like for like migration:
It is the easiest and the most cost-effective way to move
workloads from the non-cloud environment to the cloud
environment. It usualy takes place for like-for-like
environment, i.e those migrations involving Physical-to-
Virtual or Virtual-to-Virtual movements with the same
OS in the source and target. In this technique all of the
applications running in physical servers (or in a virtual
machine) are packaged up into an image and added to the
cloud catalog and instantiated into a virtual machine on
the cloud platform. Technologies such as VMWare
Converter and Platespin are used to perform the migration
from the customer’s source environment to the target
cloud environment. This approach will migrate the
operating system, middleware, application and any
customization, to the target environment in an as-is form.
Due to same nature of OS and software in both the source
and target, the amount of remediation or porting required
in this type of migration is almost negligible.
The benefits of this approach are:
• It is applicable for a variety of existing workloads,
even business-critical and those requiring regulatory
compliance
• Requires minimum outage window during migration
• Minimizes the risk of application failure after
standardization and on-boarding
• It is mostly an automated process and thus has low and
predictable costs
However the drawback is that this approach minimizes
the amount of standardization that is achieved and
therefore some of the agility benefits of the cloud
environment are obviated. Furthermore, some cloud
platforms do not support the ability to import images due
to technical limitations, issues with license management
and bandwidth limitations that make it difficult to move
 large software images over a network from the as-is
environment to the cloud platform.
b) Cross platform migration:
A cross platform (e.g., Solaris to AIX, Windows to Linux)
migration is usually slow and expensive but enables more
business agility than like-for-like migration. This type of
migration is generally complex because it involves change
in hardware type (e.g, SPARC to Intel), OS type and
software versions when moving from the source to target.
It thus requires a thorough analysis of the application, its
dependencies, compatibility of the software in the target
environment etc.; code remediation, porting and test.
Moreover due to application dependencies, it may involve
multiple migration phases before all the in-scope
applications are moved over to the target and the existing
legacy servers decommissioned.
On the other hand, this type of migration has the dual
benefit of realising the enterprise’s broader IT
modernization roadmap along with adoption of cloud
technology. A hardware and/or software refresh while
moving to a cloud environment promises a better ROI for
the organization, makes the IT infrastructure much more
manageable and also makes it easier to create new
business services.
c) Application-only migration:
Recently there are new solutions like the ‘Zapp Migration
Tool’ from AppZero[2] which extracts only the in-scope
application from the source machine and enables it to run
on the target without the need of any re-installation, re-
engineering or re-deployment. Various scenarios exists by
which this kind of migration can be made possible. The
essential mechanism by which this works is decoupling
the application from its OS and encapsulating it along
with its dependencies, cofiguration / registry files,
services, runtime libraries into a ‘Virtual Application
Appliance’. The application and its dependencies thus
gets encapsulated in a virtual container, minus the source
OS. This virtual container having the application can be
copied over to the target and made to run with minimum
reconfiguration. This type of migration promises to cut
down on the overall migration duration and complexity
but it still has its limitation in terms of the type of
application handled and the choice of OS it is compatible
with currently.
3) Data Migration - Data migration from the current
environment to the target cloud environment. The tool choice
for data migration is highly dependent upon the target cloud
environment, the available ‘migration window’, network
proximity to the source platform and level of administrative
access available to the migration team. The available
application downtime or the ‘migration window’ is
particularly an important consideration since the decision to
use replication based migration tools or the traditional
database migration utilities like ‘export-import’ need to be
taken based on that timeline.
4) Standardization - Standardizing or adjusting the created
image so that it is compliant with the infrastructure
management services of the cloud environment.
5) Integration - Complete integration wherever required to
insure the connectivity from the moved-workload to
dependent application services and data in the cloud
environment.
D. Tuning the Target Environment
Once the customer’s existing instances have been migrated
to the target cloud platform, these instances have to go through
an adjustment stage to configure them to the target cloud
environment’s architecture standards. These include:
• Removal of any non-standard tools and agents
• Applying any operating system level security patches
• Conforming to the target environment security policy
or regulatory requirements
• Installation of the target cloud environment’s
management tools
As part of the migration, the IP address of the migrated
server will likely change. As such, it’s possible that the
configuration of the software running on the migrated instance
may need to be updated with the new IP address. Similarly
there may be other configuration or application specific
hardcoded changes which need to be made at this stage.
E. Final testing and go-live
This is the final phase where it is confirmed that the
migrated workload is performing as expected and the cloud
platform now becomes the production environment for the
migrated workload. The old source servers and images are
usually de-commissioned or re-purposed after a pre-defined
period of monitoring.
III. MAPPING MIGRATION TO CLOUD COMPUTING
REFERENCE ARCHITECTURE
The Cloud Computing Reference Architecture (CCRA) [1]
is intended to be used as a blueprint / guide for architecting
cloud implementations. The CCRA is structured in a modular
fashion and defines the fundamental architectural elements
constituting a cloud computing environment. Elements of
CCRA that should be considered when performing a migration
are identified below:
• Cloud Service Consumer :: Cloud Service Integration
Tools
• Cloud Service Provider :: Operational Support Services
:: Change and Configuration Management
• Cloud Service Provider :: Operational Support Services
:: Provisioning
• Cloud Service Provider :: Operational Support Services
:: IT Service Level Management
• Cloud Service Provider :: Operational Support Services
:: IT Asset and License Management
 • Cloud Service Provider :: Business Support Services ::
Service Offering Management
• Cloud Service Provider :: Business Support Services ::
Metering
• Cloud Service Creator :: Service Creation Tools
Of course there may be other functional components of CCRA
that would also be required for a migration activity. However,
the above identified components are the primary ones that are
almost always required for a successful migration.
IV. WORKLOAD STANDARDIZATION FOR CLOUD
MIGRATION
Standardization is one of the key features of cloud
computing and moving workloads to the cloud involves
standardization and in some cases, consolidation of the source
workload(s). The figure 2 illustrates the concept.
Non Cloud landscape Cloud
Fig. 2. Migration to cloud can result in Consolidation
The non-cloud environment is usually composed of many
different types of source systems, which can be categorized
into the following types when considering moving onto a cloud
environment:
• Infrastructure as a Service (IaaS) - virtualized
hardware, operating system and system management
tools.
• Platform as a Service (PaaS) - messaging, application
and database, middleware management tools
• Software as a Service (SaaS) - business application
The workload characteristics, along with the source and
target cloud environments, determine the workload migration
complexity and cost. Workloads can be constituted into:
A. Simple workloads – single application with no
dependencies. E.g., HTTP servers, Groupware, small
Databases.
B. Complex workloads – single application with many
dependencies, or a group of applications that must move at
the same time or extensive version upgrades included in
transformation. E.g, Partitioned Databases, Disaster
Recovery requirement, Korn or Shell based applications.
C. Very complex workloads – Third party or custom developed
application with significant customization. E.g., C, C++
applications.
V. COMMON MIGRATION CONSIDERATIONS
A. Issues and Challenges
Some of the potential issues and challenges that
organizations may face while considering to migrate workloads
to cloud are as follows:
1) Identifying the correct workload: This is a major
challenge and involves evaluating the existing workloads on a
number of parameters. A formal fit-for-purpose workshop to
identify and categorize the workloads along with their target
environment often helps in most cases. The various parameters
taken into consideration are:
• Technical - security and privacy, ownership, level of
customization, integration, virtualization,
infrastructure, access to technical resources, etc
• Operational – this involves factors like deployment
flexibility, speed to implement, agility, migration ease,
IT utilization, etc
• Multi-tenancy – this involves issues dealing with
sharing business applications with partners, scalability
across multiple locations, globalization, etc
• Cost of Ownership/ Return on Investment
2) Security and Privacy: Data security and privacy remains
one of the primary barriers to migrating workloads to cloud.
Understandably, sensitive data requires protection and loss of
control is not acceptable. Moreover there is usually a
requirement to comply with many regulations that require data
governance. Enterprises are thus reluctant to give up their
control over sensitive data to service providers.
Most of the risks have to do with the accessibility, use
and control of data and the danger of having unauthorized
access to confidential, proprietary information. A generic
model for data security might not be adequate for this purpose.
For example, consumers who primarily use collaboration tools
and email systems would focus on access and policy controls,
while clients thinking of moving their healthcare applications
on cloud are more concerned with data isolation and
encryption.
3) Quality of Service: This is one of the major factors that
comes into play when organizations think about moving to
cloud. Current standards of Service Level Agreements(SLAs),
prevalent in the industry might not be strong enough to
gurantee uninterupted availability of running production
applications on cloud. In most cases, enterprises get
compensated for the amount of time the service was down but
that does not cover the business loss that cloud consumers
might suffer. Without proper service quality guarantee
enterprises may not be ready to host their business critical
infrastructure in the cloud.
 4) Cost Savings Potential: Enterprises need to first get a
feel of real cost savings before committing to put their
workloads on to cloud. The return on investment (ROI), Capex
versus Opex costs benefits, utilization, etc. are important
considerations for an organization before investing on cloud.
5) Network Performance / Responsiveness: Cloud
computing is inheirently network centric. This becomes all the
more important when migrating applications on to cloud
environment, since network bandwidth becomes a critical
factor. Higher bandwidth ofcourse means higher costs and
organizations need to find a balance between the two, when
considering any cloud migrations.
6) Integration Complexity: Since most business
applications are not independent and do not work in isolation,
it becomes very important to understand the integration
complexity when considering a migration. Possibilities include
integration with existing on-premise applications, other cloud
applications, up-stream/down-stream connections etc.
B. General Best Practices
• It is very important to understand and determine the
target cloud environment at the outset, since the
migration strategies and planning would be guided by
the choice of the “landing zone”.
• A thorough workload analysis must be done to
estimate migration costs, potential benefits and identify
candidates for moving to cloud. Migration must
address the needs of both existing workloads as well as
new workloads.
• It is important to understand that migration may
address an entire workload or just one or more of its
constituent parts.
• The organizational impacts of migration must be
considered, especially when it is addressing
consolidation during migration and those ancillary
effects on other systems.
VI. CLOUD MIGRATION PATTERNS
Some definite patterns emerge from the commonly found
repeatable migration scenarios that exist today. Some of these
are described below.
A. Traditional IT to Public Cloud
This pattern is focused on the movement and migration of
workloads from an existing, non-cloud style, infrastructure to
an off-premise public cloud style environment. In this scenario
there is a set catalog of target platforms which are statically
defined; therefore, the movement/migration of workloads to
cloud must take into consideration, the OS and platform stacks
supported by the cloud service provider. In addition, the
movement of workloads in this pattern will include any re-
engineering, updated integration and process updates which
may be required to maintain expected functionality and SLAs.
Choosing the right workload to migrate to the public cloud is a
vitally important process to use in determining when or how to
migrate an existing workload to this environment.
B. Private Cloud to Public Cloud
In this context a private cloud environment implies that a
client’s infrastructure has been configured in a private cloud
style, meaning it is provisioned for exclusive use by a single
organization comprising multiple consumers (e.g., business
units) and is on the client’s premises (e.g. in their data center
facility). A public cloud style infrastructure is one which is
provisioned in an off-premise and open use environment
exhibiting multi-tenant characteristics (e.g. meaning workloads
are likely on a shared physical computing, network, and storage
environment). This pattern is focused on the movement (and
potential migration) of one or more workloads from the private
to the public cloud environment. It’s important to note that not
all workloads (or workload components) need be moved to the
public cloud. It’s also important to note the public cloud
environment may be owned, managed, and operated by the
organization, a third party, or some combination of them, and it
may exist on or off premises.
C. Private Cloud to Hybrid Cloud
A hybrid cloud combines the benefits and challenges
contained in both the public and private deployment models.
Most notable among these challenges is maintaining the
integrity of application and data level integration as some or all
of the components of a workload are migrated between
environments. Thus this workload movement pattern covers
the bi-directional movement of workloads between a public
and private cloud deployment model and covers both full and
partial migration. This is an important aspect since, in the case
of partial movement, the aforementioned integration integrity
will be critical to maintain.
D. Public Cloud to Private Cloud
This is a less traditional movement and migration pattern
since there’s a lot of excitement concerning the move away
from a traditional environment to a cloud style environment
and there is a lot of exaggerated assumptions about the
guaranteed value that moving to a public model will provide.
However there are times when a workload can be developed,
built and tested in a public cloud environment (which does not
have a focus on production level workloads) and then moved
back “on premise” to a client’s internal cloud where mission
critical and/or production level applications will run.
Moreover, there are many cases where an application can be
tested with the need to expose sensitive information in a public
model, and then be brought “back on premise” to complete
testing with the data at full fidelity. In many cases, this
workload movement and migration pattern also supports a
performance testing scenario in the public venue before
moving back internally.
E. Public Cloud to Public Cloud
This is typically expected to be transparent to the user of
the cloud environment and involves a migration and movement
effort to lift and move a workload between two cloud
environments which are using the public delivery model. This
is especially evident when a client wants to move between
cloud providers, such as moving from Amazon EC2 to the IBM
cloud or vice versa. Considerations of platform, hypervisor,
integration, data formats, and lower level IaaS dependencies
must taken into account. As the cloud provider market
becomes more saturated, there will be more options for clients
to choose among the best price or capability offered by the
service providers.
F. Traditional IT to Private Cloud
This is one of the more complex movement patterns as it
requires several stages of movement and migration and may
also require several stages of re-engineering leading to a final
standardized tech stack. The primary reason for additional
complexity in this pattern is because this is usually a first time
cloud migration activity for the enterprise. Moreover,
traditional IT environments typically have a set of custom
applications in a heterogeneous technology environment with a
myriad of integrations and interconnections (at the
infrastructure, middleware, application and data layers). The
movement of this complex environment to a cloud requires the
potential re-engineering of workloads at some or all of these
layers. This is because when setting up the private cloud
infrastructure, the enterprise needs to maintain, if not improve,
the same level of security, integration and operational efficieny
that it is used to in the current traditional IT environment.
VII. CONCLUSIONS
Cloud computing promises a path to higher efficiency, agility,
quality, security, governance and standardization in the
delivery, consumption and operation of IT services, all at
reduced capital and operational expense. The potential of cloud
computing is, however, easily matched by the challenge and
effort to transform traditional IT to a cloud model. There is no
one-size-fits-all cloud, and it is up to each business to decide
how much change is tolerable and to decide how far into the
cloud to step. As with all journeys, planning goes a long way in
reaching the destination. Taking the time to understand the
different layers of cloud, to assess the suitability of applications
to different clouds and to acquire whatever skills may be
needed to execute the move may make a significant difference.
ACKNOWLEDGMENT
The author would like to thank the Business Application
Modernization department of IBM for providing the
opportunity to research and work on this subject.
REFERENCES
[1] Michael Behrendt et al., “Introduction and Architecture Overview - IBM
Cloud Computing Reference Architecture 2.0”, The Open Group, pp.
21-22, February 2011. Available:
http://www.opengroup.org/cloudcomputing/uploads/40/23840/CCRA.IB
MSubmission.02282011.doc
[2] Introduction to AppZero. Available: www.appzero.com
[3] Joydipto Banerjee, Debasis R Choudhuri and L K Swift, “Accelerate to
Green IT - A Practical Guide to Application Migration and Re-hosting”,
developerWorks, July 2012. Available:
http://www.ibm.com/developerworks/linux/library/l-greenit/index.html
[4] Joydipto Banerjee, “Real-world Journey to Your Own Private Cloud,
Part 1: Prepare the concept”, developerWorks, July 2011. Available:
http://www.ibm.com/developerworks/cloud/library/cl-
privatecloud1/index.html