Migrating Applications To TH 207162

G00207162
Migrating Applications to the Cloud: Rehost,

Refactor, Revise, Rebuild, or Replace?
Published: 3 December 2010
Analyst(s): Richard Watson
The CIO issues a simple directive: "Move some applications to the cloud."
To do this, architects face bewildering choices. In this Decision Point,
Principal Research Analyst Richard Watson steers architects to a choice
from among five alternatives: Rehost on HIaaS, refactor using SIaaS and
PaaS, revise for HIaaS or PaaS, rebuild on PaaS, or replace with SaaS. The
decision must consider an organization's requirements, evaluation criteria,
and architecture principles. However, no alternative offers a silver bullet: All
alternatives require architects to understand application migration from
multiple perspectives and criteria, such as IT staff skills, existing
investments, and application architecture.
Table of Contents
Decision Point........................................................................................................................................ 3
Decision Context.................................................................................................................................... 3
Business Scenario............................................................................................................................ 4
Architectural Context........................................................................................................................ 5
Related Decisions.............................................................................................................................9
Evaluation Criteria.................................................................................................................................10
Requirements and Constraints........................................................................................................10
Migration Goals and Priorities................................................................................................... 10
Legacy Application Characteristics........................................................................................... 12
Modernization Requirements.................................................................................................... 13
Application Platform and Architecture Principles....................................................................... 14
Development and Operations Skills Constraints........................................................................ 15
Migration Cost Considerations..................................................................................................15
Principles........................................................................................................................................16
Alternatives...........................................................................................................................................17
This research note is restricted to the personal use of guilherme.martins@unicred.com.br.

Rehost............................................................................................................................................18
Refactor......................................................................................................................................... 20
Revise............................................................................................................................................ 22
Rebuild...........................................................................................................................................23
Replace.......................................................................................................................................... 25
Comparing Alternatives.................................................................................................................. 26
Distinguishing Products from Services............................................................................................ 27
Future Developments........................................................................................................................... 28
Progress on Portability Standards...................................................................................................28
Evolution of Cloud Business Models............................................................................................... 30
Incumbent Platform Players Will Wake Up...................................................................................... 30
Decision Tool........................................................................................................................................ 31
Pre-Decision Assumptions..............................................................................................................31
Assumption 1: Quality of Service Risks..................................................................................... 31
Assumption 2: IT Portfolio Management Frameworks............................................................... 32
Using the Decision Tools.................................................................................................................32
Decision Filters......................................................................................................................... 33
Migration Goals Assessment Tool............................................................................................. 37
Decision Justification............................................................................................................................ 38
Use Rehost.................................................................................................................................... 38
Use Refactor.................................................................................................................................. 39
Use Revise..................................................................................................................................... 39
Use Rebuild....................................................................................................................................39
Use Replace...................................................................................................................................39
Recommended Reading.......................................................................................................................40
Revision History....................................................................................................................................41
Notes................................................................................................................................................... 43
List of Tables
Table 1. Gartner Frameworks to Apply Before This Cloud Migration Decision Point.................................6
Table 2. Defining the Rehost Migration Option...................................................................................... 19
Table 3. Defining the Refactor Migration Option.................................................................................... 21
Table 4. Defining the Revise Migration Option....................................................................................... 22
Table 5. Defining the Rebuild Migration Option......................................................................................24
Table 6. Defining the Replace Migration Option.....................................................................................25
Page 2This
of 45research note is restricted to the personal use of guilherme.martins@unicred.com.br. Gartner, Inc. | G00207162
Table 7. Which Elements of the Migrated Application Change, Need to Be Updated, or Entirely Replaced
with Each Alternative?.......................................................................................................................... 27
Table 8. Distinguishing Cloud Services from Enabling Products............................................................ 28
List of Figures
Figure 1. IT Portfolio Management Programs Giving This Decision Point Context....................................5

Figure 2. Legacy Modernization Options Mapped to Cloud Migration Alternatives.................................. 7
Figure 3. Relating This Decision Point to the Steps of Gartner's IT1 Cloud Adoption Strategy Guidance
Framework............................................................................................................................................. 8
Figure 4. The Rehost, Refactor, Revise, Rebuild, and Replace Cloud Migration Alternatives Mapped to
the Four Cloud Tiers (HIaaS, SIaaS, PaaS, and SaaS) and Examples of Cloud Service Providers......... 18
Figure 5. Steps Required to Use the Cloud Migration Decision Tools.................................................... 33
Figure 6. Conditions for Filtering out the Rehost Migration Alternative................................................... 34
Figure 7. Conditions for Filtering out the Refactor and Revise Migration Alternatives............................. 35
Figure 8. Conditions for Filtering out the Rebuild Migration Alternative.................................................. 36
Figure 9. Conditions for Filtering out the Replace Migration Alternative................................................. 37
Decision Point
What is the right cloud migration strategy for my application?
Decision Context
This section enables the decision maker to understand the context of the decision within a larger
architectural scope, to relate the decision to applicable business scenarios, and to understand the
impact this decision will have outside the context of the immediate problem.
First, to narrow the scope of the decision, the context of this Decision Point includes crucial
assumptions:
■ This is not a decision of whether to migrate applications to the cloud. That decision has already
been made. This is a "how do I do it" execution decision, not a "should I do it" strategy
decision.
■ The first assumption implies that many of the security, availability, and trust issues that
accompany an externalization decision, especially using cloud computing, have been analyzed
and can be managed.
Gartner,This
Inc. |research
G00207162
note is restricted to the personal use of guilherme.martins@unicred.com.br. Page 3 of 45
■ The application already exists in some form: either custom in-house software or commercial off-
the-shelf (COTS). This is not a greenfield project. Several of the alternatives involve abandoning
existing systems, but the requirements for the application are known.
■ This application is for production use, not development or testing.
■ Finally, the organization has already assessed the application in question and has determined its
goals for the migration.
The decision in scope for this Decision Point is not solely an issue of migration but is truly one of
optimization. Another way to state the question: Which cloud platform and migration techniques
offer the chance to optimize the application's contribution to stated and implied business and IT
goals? Those business and supporting IT goals, described next, should be driving a migration
decision — not a rush to experiment with new toys.
Business Scenario
The externalization of IT is the movement of IT resources from direct enterprise control and
ownership to one or more external service providers. One motive to externalize IT is to reduce costs
while improving value delivery and transitioning from fixed to variable costs. Another motive is to
refocus efforts on core capabilities while examining alternatives for the non-core capabilities. Core
capabilities are those that provide competitive differentiation to the business. Non-core capabilities,
or context capabilities, typically have an indirect contribution or no contribution to differentiation:
1
They are commodities. Another motive is to focus efforts on activities that the organization can do
well (core functions), or at least better than capabilities that can be easily sourced elsewhere. A
fourth motive is to respond to changing business conditions more quickly and efficiently, building a
strategic, value-based partnership with the business.
As economic pressures increase, organizations have expressed overwhelming interest in cloud

computing, outsourcing, and other options that externalize IT. Ultimately, organizations that desire
to optimize business value and solution delivery will broker and integrate a mix of internally and
externally provided services. This optimization will not be easy. Most IT environments will require
significant refactoring while introducing new challenges of cross-functional and cross-supplier
integration. However, this refactoring will have the long-term benefit of clearly decoupling core and
context functions so that they can be more effectively and dynamically redistributed.
At this point, driven by the business goals and pressures described in the scenario above, the CIO
has already made a decision. Adopting cloud as a sourcing strategy is going forward and this
Decision Point is concerned with executing that strategy.
The IT1 cloud computing root document "Cloud Computing: Transforming IT" describes cloud
benefits, concerns, and risks in more detail. The guidance document "Building a Solid Cloud
Adoption Strategy: Success by Design" describes a guidance framework for cloud adoption based
on those benefits and risks. The IT1 Perspective document "Moving Out: The Externalization of IT"
discusses motivations and options for the externalization of IT.
Page 4This
Architectural Context
Choosing the optimal application migration option is a decision that cannot be made in isolation.
Any cloud migration decision is, in essence, an application or infrastructure modernization decision
and needs to be made in the larger context of related application portfolio management (APM) and
infrastructure portfolio management (IPM) programs.
Figure 1 represents the complete context for this Decision Point. The decision to migrate an
application to one cloud tier or another is, in reality, a small cog in the IT portfolio and project
management machine. Figure 1 illustrates two iterative phases of APM and IPM programs: firstly,
measurement and strategy; secondly, sourcing and execution. This Decision Point is represented in
the lower section of the overall IT portfolio management process in Figure 1, which provides cloud-
sourced options for modernizing applications and infrastructure.
Figure 1. IT Portfolio Management Programs Giving This Decision Point Context
Source: Gartner (December 2010)
Gartner,This
Inc. |research
G00207162
Successful organizations will apply existing Gartner frameworks that guide the activities in Figure 1
before they decide how to approach the cloud-specific sourcing issues required by an application's
modernization approach.
Table 1 details the Gartner frameworks to apply prior to this Decision Point, as shown in Figure 1,
with the questions each framework answers about a specific application. Each of these frameworks
provides analysis that will be part of the structured decision making in the "Decision Tool" section of
this Decision Point.
Table 1. Gartner Frameworks to Apply Before This Cloud Migration Decision Point
Gartner IT1 guidance framework What does this framework tell us about an application?
"Application Portfolio Management" "What are the new demands for this application?"
(APM is an ongoing program that encompasses the subsequent
frameworks)
"Application Rationalization: Burning Fat "Where in its life cycle is this application?"
and Building Muscle" "Is this application of strategic importance?"
"Where is this application's position on the value/(cost + risk) matrix?"
"Strategic Software Assessment "Is this a strategic application? If so, how much is it worth?"
Framework" "How can I quantify an application's delivered business value, total cost,
risks, and technical quality?"
"SWLegMod: A Framework for Legacy "What technologies constitute the application and its architecture,
Software Modernization" infrastructure, and dependencies?"
"Which skills are required to maintain and enhance it?"
"If replacement is required, what is the modernization strategy for this
application?"
"Build, Buy, or Borrow: Choosing "What is the sourcing strategy for modernizing this application?"
Custom Development Software, Open
Source Software, Commercial Off-the-
Shelf Software, or Software as a
Service"
"Building a Solid Cloud Adoption "What is my organization's strategy for adopting cloud computing?"
Strategy: Success by Design"
"Data Center Sourcing: Cloud, Host, "What is the correct model to host an IT application or service: external
Co-Lo, or Do It Yourself" (cloud, hosting, or co-lo) or internal data center?"
"Application Platform Foundations" "What frameworks and platforms should organizations use to build
application systems?"
Two areas in Figure 1 are hatched in green and red to indicate that further detail is available, as
shown in Figure 2 and Figure 3.
Page 6This
Figure 2 extends the diagram representing application modernization alternatives described in the
IT1 guidance document "SWLegMod: A Framework for Legacy Software Modernization." Figure 2
shows the migration strategies presented in the "Alternatives" section of this migration Decision
Point as solution-delivery options for each style. While the migration alternatives do not map 1:1
with modernization styles, Figure 2 shows a mapping to the most applicable alternative for each
strategy. For each modernization style, while "Build, Buy, or Borrow: Choosing Custom
Development Software, Open Source Software, Commercial Off-the-Shelf Software, or Software as
a Service" provides the sourcing strategy, cloud migration alternatives in this Decision Point offer
execution possibilities.
Figure 2. Legacy Modernization Options Mapped to Cloud Migration Alternatives
Figure 3 depicts the steps composing the cloud adoption strategy guidance framework in the IT1
guidance document "Building a Solid Cloud Adoption Strategy: Success by Design." Figure 3
Gartner,This
Inc. |research
G00207162
indicates points of intersection between the guidance framework, this application migration
Decision Point, and the "Data Center Sourcing: Cloud, Host, Co-Lo, or Do It Yourself" Decision
Point.
Figure 3. Relating This Decision Point to the Steps of Gartner's IT1 Cloud Adoption Strategy Guidance
Framework
Any cloud migration decision will impact application platform decisions. See references in the
following order:
■ The IT1 root document "Application Platform Strategies for the 2010's" presents a strategic
vision for application platform infrastructure encompassing cloud computing. The intent of the
"meta-platform" described in this root document is that it must support IT externalization and
Page 8This
enable infrastructure federation. Supporting a meta-platform raises questions such as: How will
the organization manage identity and entitlements for applications migrated to the cloud? How
will the organization manage application and data integration across the internal/external
boundary?
■ The "2010 Planning Guide: Application Platform Strategies" describes current trends influencing
application infrastructure and architecture
■ The sub-templates of the Reference Architecture template "Application Platform" describe the
infrastructure models envisioned in the root document in more detail, particularly the
"Frameworks and Containers" and "Managed Communications Infrastructure" templates.
Related Decisions
This decision shares explicit dependencies with the following IT1 Decision Points:
■ "Data Center Sourcing: Cloud, Host, Co-Lo, or Do It Yourself" focuses on answering the
question: "What is the correct model to host an IT application or service: external (cloud,
hosting, or co-lo) or internal data center?" Once IT decision makers are guided through the
decision to adopt a data center sourcing model based on cloud, this application migration
Decision Point helps architects make a more detailed choice between alternative tiers of the
cloud to engage for a specific application. The data center sourcing Decision Point presents the
operational, security and regulatory requirements and constraints shared with this application
migration decision.
■ "Application Platform Foundations" guides architects to consider "What frameworks and
platforms should organizations use to build application systems?" Thinking through answers to
this question will help architects assess cloud platform programming language, frameworks,
management, and application topology capabilities.
■ "Programming Languages" helps organizations answer the question: "What programming
languages should an organization use for a particular software development project?" Choice of
programming language may be constrained by the cloud platform chosen. Architects should
consider if this is a trade-off worth making. The development team's desire to retain the
application's existing language will constrain migration options.
■ "Java Server-Side Container Frameworks" helps an architect answer the question: "Which
server-side container frameworks should an organization use to develop and deploy an
enterprise Java software application or service?" When selecting a cloud platform to host a Java
application, choice of supported container frameworks may be constrained.
■ "Web Presentation Technologies" helps organizations answer the question: "What kind of Web
presentation technology should a Web application use?" Cloud platforms may limit Web
presentation technology options, or present innovative capabilities such as easy support for
mobile Web applications.
■ "Service Container" focuses on the question: "What type of service container should be used to
implement and host a service?" Development teams use service containers as frameworks to
Gartner,This
Inc. |research
G00207162
build and deploy services. No single type of container supports all service use cases, so most
organizations use a variety of containers within their environments. Architects should evaluate
whether platforms offered by cloud migration alternatives support their requirements and
constraints for a service container.
Evaluation Criteria
Consider the following evaluation criteria when deciding how to migrate applications to cloud
platforms:
■ Requirements and constraints

■ Principles
Requirements and Constraints

The following requirements and constraints will strongly influence the cloud migration alternative for
each application or service:
■ Migration goals and priorities

■ Legacy application characteristics
■ Modernization requirements
■ Application platform and architecture principles
■ Development and operations skills constraints
■ Migration cost considerations
Migration Goals and Priorities

The organization's objectives for cloud migration will direct the choice of an alternative. A number of
often-conflicting factors influence those goals. The company's cloud adoption and legacy
modernization strategies will dictate relative priorities of the following goals:
■ Deliver rapidly to market: Organizations may face deadlines related to infrastructure support
end of life, regulatory compliance, or seasonal business opportunities which require a rapid
application migration. Teams will favor alternatives that allow migration with minimal
architecture impact and without kicking off a development project.
For migration projects that include development of new functionality, reducing the volume of
code needed to express a capability is another way to make development teams more
productive. Cloud platforms vary in the degree they provide or support productivity features,
such as customizable application templates and data models, metadata-driven engines, and
prebuilt components (supplied directly or via a community application store). The need to
deliver business capabilities at ever greater speed implies that a modest set of application
Page 10 of 45
This research note is restricted to the personal use of guilherme.martins@unicred.com.br. Gartner, Inc. | G00207162
requirements should require a modest effort, without excessive fixed costs to mobilize a
2
development team and project to satisfy those requirements.
■ Deliver new application capabilities: Legacy modernization strategy may dictate that the
application admits new functional requirements. More maintainable software drives agility, such
that systems can accommodate rapid, cost-effective changes to functional and non-functional
system requirements (e.g., capacity). More usable software reduces the cost and time to recoup
implementation investment.
Another objective for revision work is optimizing the application architecture for cloud
infrastructure. For example, if the application is not scalable on its current infrastructure, it won't
scale any better in the cloud without significant revision.
■ Scale elastically: Organizations may require better (or more cost-effective) availability to meet
unpredictable demand, such as peak seasons or end of month. Consumption-based pricing
also enables IT organizations to perform better budget forecasting.
■ Control operating expenses and preserve capital: Operating expenses include head count
(both development and operations) and infrastructure costs (including data center power and
cooling). Relevant capital outlay includes purchase of servers, storage, and software. For
example, one infrastructure aspect organizations are targeting to control capital and ongoing
costs is moving from legacy reduced instruction set computer (RISC)/Unix systems to
commodity x86 systems with Linux or Windows. If an organization's present cash flow is more
important than long-term cost, or it lacks capital to modernize an application using internal
infrastructure, a priced-by-consumption model is an attractive solution.
■ Wring operational efficiencies: A complex IT portfolio often impedes an organization's ability
to respond to new demands and business opportunities. Is the primary goal of cloud migration
the ability to install, provision, and secure new infrastructure quickly? Or does the enterprise
desire to reduce or reassign development or operations head count assigned to this
application?
■ Consolidate infrastructure: For IT departments running out of power, cooling, and physical
space in their data centers, migrating or retiring applications frees up these precious resources
for applications that must reside on-premises.
■ Leverage existing investments: To maximize their ROI of funds already sunk into IT,
organizations want to leverage existing investments in development and operations skills,
experience, tooling, infrastructure, and deployed applications. Portfolio management activities
must evaluate the net value of these investments. For example, is the application's codebase
valuable? Alternatively, is the organization willing to modify its business processes to use
migration options that encapsulate prepackaged processes and capabilities?
■ Open multichannel access: Migrating an application to cloud can enable wider, secure access
to the application, to all employees, external partners and customers, regardless of desired form
factor or location. For example, better support for mobile users is a common feature of some
innovative platform-as-a-service (PaaS) and software-as-a-service (SaaS) solutions.
Gartner,This
Inc. |research
G00207162
■ Compose and integrate solutions: Does the team desire to integrate the application more
easily with other cloud, SaaS, and Web applications?
See the following documents for a full discussion of typical objectives of adopting cloud computing:
■ "Cloud Computing: Transforming IT"

■ "Building a Solid Cloud Adoption Strategy: Success by Design"
■ "Moving Out: The Externalization of IT"
■ "Stuck Between Stations: From Traditional Data Center to Internal Cloud"
■ "Migration from Unix/RISC to x86"
Legacy Application Characteristics

The organization must catalog specific architecture characteristics of the application that constrain
the possible choices. The portfolio management guidance frameworks that precede this Decision
Point, mentioned in the "Architectural Context" section, provide techniques for analyzing the
application's architecture and supporting infrastructure. Aspects of architecture fit that influence
cloud migration decisions include:
■ Application pattern: Architects should determine which of the following processing and
interaction patterns characterizes the application because cloud platforms often have a bias
making it easier (or impossible) to host particular patterns:
■ Web application (broken into the familiar three-tier or model-view-controller [MVC] pattern)
■ Fat client application
■ The application provides Web services or APIs in addition to an interactive client
■ The system is a batch process or has regularly executed background processes
■ Business logic complexity: Code bases with complex or highly specialized business logic will
be more costly and risky to replicate.
■ Data parallelism: Data that exhibits high locality of reference, or is already partitioned (e.g.,
horizontally sharded) will migrate more successfully onto horizontally scalable infrastructure.
■ Application licensing restrictions: Server virtualization software has matured to the point that,
from a technology point of view, most applications can efficiently run inside virtual machines
(VMs). But many application vendors have not matched that technical maturity with licensing
and support policies offering virtualization compatibility. Architects should determine, for the
application under consideration, whether third-party COTS components or dependent libraries
that run on a VM are supported by the vendor in a virtual environment.
■ Demand life span and volatility: An application may have an extremely limited life span. For
example, if business demand is transient or the application satisfies one-off computing
requirements (e.g., The New York Times famous archive digitization project on Amazon Elastic
Compute Cloud [EC2]). Variable and vacillating business demand can also influence whether the
Page 12 of 45
requirements warrant the attentions of a development team, rather than prototyping several
commercial software options or simply migrating the existing application as-is, while demand
stabilizes.
Modernization Requirements
The structured program for legacy software modernization (SWLegMod) and strategic software
assessment framework (SSAF) frameworks will determine application modernization requirements.
Decision makers should consider implementing the following modernization requirements when
evaluating cloud migration options:
■ Scalability: Applications are required to cope with additional concurrent users and increased
data volume or transaction frequency. Scalable applications satisfy these additional demands
by incrementally adding hardware resources. An application that is already horizontally scalable
is a better fit for migration onto infrastructure that offers to elastically scale resources in
response to demand. Determining the degree to which the components are autonomous and
stateless and finding the most critical processing bottlenecks is required pre-work for this
decision. Do the architects need to change the application architecture to remove latency or
parallelism bottlenecks? Scaling purely by throwing hardware at an inherently non-scalable
application will become expensive in an elastic and pay-as-you-go (PAYG) environment.
■ Security: Enforcing consistent role-based access control and providing single sign-on for users
requires federation of identity provisioning and management systems between on-premises and
cloud services. Web-based services increasingly require support for open authorization and
distributed authentication frameworks such as OAuth and OpenID. Teams that want to federate
more easily with other Web services and SaaS will favor providers that support common identity
management mechanisms. Additionally, business-critical applications require enforcement of
policies related to auditing, data retention, data integrity, privacy, and confidentiality. For more
guidance, refer to the IT1 documents "Developing a Cloud Computing Security Strategy" and
"Using Encryption to Protect Sensitive Data in Cloud Computing Environments."
■ Transactional integrity: Online transaction processing (OLTP) systems can have stringent
requirements regarding distributed transactions and support for a two-phase commit (2PC)
protocol when updating multiple data sources. Application semantics may also require that
operations be completed in a strict order. Variable network latency, variable service provider
availability, and unguaranteed service levels mean applications with 2PC requirements are not
suitable models for cloud platforms. Architects should modify such applications to move
transactional integrity semantics from protocol to application semantics.
■ Integration requirements: How an individual application relates to others in the IT portfolio has
significant impact on its migration prospects. Picking up and moving an application with
multiple dependencies, point-to-point integration, and complex interdependencies will be
challenging, if not impossible. To leverage cloud computing beyond trivial use cases,
organizations should plan to create an IT environment without boundaries. This requires an
architecture spanning (or "cohabiting") internal, private, and public cloud
implementations. Modernization requirements may include implementing better interfaces
before shifting the application to the cloud. Refer to "Planning Considerations for Externalization
Gartner,This
Inc. |research
G00207162
and Cloud Computing" for a discussion of architecture requirements for co-habiting
applications.
Migration options vary in the degree to which integration with on-premises applications is
possible. For example, can the migrated application appear to be on a private subnet of the
organization's network? Or, is the migrated application entirely cut off from on-premises
applications except for the provider's proprietary import/export interfaces and limited APIs.
■ Preserving codebase value: Gartner APM, application rationalization, legacy software
modernization, and SSAFs provide guidance on how to value source code within existing
applications (see the "Architectural Context" section of this Decision Point). Organizations with
valuable codebases that provide competitive advantage will favor migration options that
leverage this existing asset.
■ Segmenting non-core (or context) capabilities: Developing new code or actively maintaining
code that implements standardized or commodity processes provides little competitive
advantage. Requirements for shared business services, such as HR, finance, or horizontal
applications, such as Web conferencing, are well understood and are riper for "buy" migration
options than specialized competencies. Adopting some of the alternatives will depend on
business users' willingness to modify business processes they regard as "specialized."
Department-specific applications may also have limited scope, making them less risky to
prototype on more innovative cloud platforms.
Application Platform and Architecture Principles

Architects considering application migrations will require varying levels of control over programming
languages, frameworks, runtime infrastructure, and deployment topologies. Trading off architecture
control for provider innovation is relevant to dealing with the following issues:
■ Domain specificity: Cloud platforms can be agnostic (or "generic") when they are used to build
applications for any domain (e.g., Microsoft Windows Azure), or they may have a specific
domain bias, or "flavor." Applications deployed on a domain-specific platform extend the
domain-based features or templates and are often described as "adjacent applications." For
example, force.com applications can easily extend and leverage Salesforce CRM data and
functionality. Organizations that have already made investments in a provider's services, such
as Google Apps for Business or Salesforce CRM, may favor creating adjacent applications to
extend their investments.
■ Lock-in, portability, and interoperability: Portability would not be a consideration if an
architect could migrate an application and its data to a cloud provider and leave it there for its
lifetime. In reality, ignoring platform lock-in is risky, so architects must consider a multi-sourcing
strategy for multiple facets of cloud portability. VM portability covers VM image format and
management APIs for hardware infrastructure as a service (HIaaS). Code and framework
portability determines how easy it is to take an application deployed on one PaaS offering and
deploy it to an alternative platform (another PaaS offering or an on-premises solution). Data
portability measures whether an organization can easily retrieve its data and move it to an
alternative (cloud-based or in-house) application in a reasonable time, at a reasonable cost, with
no loss in data semantics. Refer to the guidance in the "Devise a Cloud Exit Strategy" section of
Page 14 of 45
the IT1 document "Managing Availability and Performance Risks in the Cloud: Expect the
Unexpected" for a discussion of provider switching triggers, actions, and realities.
Development and Operations Skills Constraints

Externalizing an application by migrating it to a cloud platform implies handing over some
operational control to the provider's staff. Examining skills profiles for the remaining development
and operations teams will determine how much or little control is desirable to hand to the provider.
Aspects to consider include:
■ Development team skills profile: Modernizing legacy software sometimes requires that a
development team recompile or repackage the existing system reliably from the source code.
Given layers of version control sediment, this is not always a straightforward task and may
require specialist knowledge or technical folklore.
Taking advantage of scalable infrastructure requires that the development team has concurrent
programming, workload decomposition, and data partitioning experience. The development
team also requires experience debugging distributed systems.
Resolving the tension between familiarity and innovation is a key to choosing between migration
alternatives. Innovative teams may be amenable to learning new languages, or to relearning
how to build and deploy applications using new frameworks and containers. In contrast, teams
relying on the familiar may favor migration rather than optimization and move their traditional
application platforms onto platforms as similar to the status quo as possible.
■ Operations team profile: The migration project should determine if the enterprise presently has
skilled resources to efficiently install, manage, and maintain the application. Another migration
consideration is whether the system administration and database administrator (DBA) teams
can competently create VM images and data packages that allow an application stack and its
data to be migrated. Some cloud platforms offer very low-level services that are aimed at
experienced system administrators.
■ New skills: Externalizing to a cloud environment requires IT solution teams to acquire new skills
or upgrade rusty ones, such as vendor management, capacity planning, metrics, and cost
estimation.
Migration Cost Considerations

Migrated applications have to meet adequate service levels. Breaking down service-level
agreements (SLAs) into their constituent measurements and baselining them accurately are
important pre-migration steps. Engineers tend to ignore the need to measure this data because
budgeting for on-premises applications can capitalize resources to make the cost of those
resources disappear, such as CPU or storage costs that are already capitalized. With cloud
deployments, all computing resources are measured, may be explicitly charged for, and cannot be
hidden with accounting tricks.
Gartner,This
Inc. |research
G00207162
Before and after application migration to a PAYG environment, development and operations teams
should perform iterative design optimization cycles both to prove SLAs are achievable and to
minimize computing resource costs.
The following application interaction requirements will impact design (and execution cost) of a
modernized or cloud-migrated application:
■ Low-level interaction patterns: For example, the level of "chattiness" of the application's
distributed components impacts the need for API usage and data movement.
■ Data requirements: Architects must assess the volume of data the application generates
and/or needs to store and the nature of the required storage. For example, the application may
explicitly require file or block storage services and include specific performance requirements,
retention policies, or compliance restrictions.
■ User requirements: Quantitative analysis of the number of users (including concurrent users)
accessing the application is important capacity- and migration-planning data.
■ Latency: Interactive applications may be sensitive to network and processing latency for proper
usability. Latency due to distance between users and a remote service provider may require
teams to consider regional proximity. The goal should be to select a provider that can guarantee
an acceptable response time range. See the IT1 documents "Framework for Improving
Application Performance over the WAN and the Cloud" and "Managing Network Performance of
Cloud-Based Applications" for guidance.
■ Input/output (I/O) requirements: Architects must make assessments of the network
bandwidth and speed required to support the ingress and egress data rates before migration. If
the application requires a specific transport or network protocol for internal functions, or to
provide access to clients, these form other migration design criteria.
■ Independent software vendor (ISV) licensing requirements: Cloud providers may use a
Services Provider License Agreement (SPLA) from ISVs (e.g., IBM or Microsoft,). In an SPLA, the
price of the software license is included in the PAYG compute instance price. However, the
specific SPLA may not allow consumers to transfer internal software licenses to the cloud.
Principles
The following architectural principles (see "Reference Architecture Principles") will impact the cloud
migration decision:
■ Degree of autonomy: Because of PAYG and self-service characteristics, application migration

to cloud providers can support a departmental autonomy strategy. This principle impacts the
migration decision because some alternatives can be used more opportunistically, without
central IT support, than others.
■ Closed vs. open solutions: Organizations favoring open solutions will have a dramatically
reduced choice of cloud providers. Each alternative presents lock-in challenges related to the
service offered. Closed versus open means different things from virtualization, code, container,
and data perspectives.
Page 16 of 45
■ Single vendor vs. best of breed: The organization's sourcing principles may dictate the use of
single vendors over best-of-breed vendors and influence the decision when multiple migration
options meet an application's requirements. Incumbent platform vendors may not have
offerings corresponding to all alternatives.
Alternatives
Service providers crowd the cloud computing market. Figure 4 illustrates the approximate place on
the spectrum of options for a selection of the best known cloud providers. Because comparing
provider offerings is challenging, this Decision Point presents migration options as a choice
between five alternative actions. This Decision Point will lead readers not toward a particular service
provider, but to an appropriate migration strategy. The alternative migration strategies considered in
this Decision Point are differentiated in the following five sections:
■ Rehost
■ Refactor
■ Revise
■ Rebuild
■ Replace
Gartner,This
Inc. |research
G00207162
Figure 4. The Rehost, Refactor, Revise, Rebuild, and Replace Cloud Migration Alternatives Mapped to the
Four Cloud Tiers (HIaaS, SIaaS, PaaS, and SaaS) and Examples of Cloud Service Providers
The mapping between providers, migration options, and cloud tiers is not straightforward. Cloud
model tiers, described in the "Cloud Computing Tiered Architecture" template, overlap both with
current providers and the five migration options. The current crop of cloud providers' offerings (and
how they market themselves) does not correspond exactly to one of the cloud tiers.
Rehost
Table 2 concisely defines the rehost migration option.
Page 18 of 45
Table 2. Defining the Rehost Migration Option
Definition ■ Redeploy the application to a different hardware environment

■ Change the application's infrastructure configuration
■ Similar to deploying a Java application server on a Linux x86 server instead
of Solaris SPARC-based server
Cloud model tiers ■ HIaas and SIaaS
What services am I ■ VMs as a service/OSs as a service, block or volume storage as a service

consuming?
Audience ■ System administrators, operations staff, "DevOps"

3
Examples ■ Deploying an existing Java EE container with a Java EE application on EC2

Linux instances from Amazon Web Services (AWS), backed by Elastic Block
Store (EBS) for persistent VM images
Rehost migration can work with systems where code modifications are impossible, but the
application can be reconfigured to run on different hardware infrastructure. Assuming the
application and its dependencies can run in a VM, this "cut and run" strategy is possible not only for
in-house-developed systems, but for COTS and other code that cannot be rebuilt. Rehosting an
application without making changes to its architecture can provide a cloud migration solution over
an extremely short timeline. HIaaS can provide elastic scalability if the application or data is already
parallel or easily parallelizable. A stateless Web application that can be effectively load balanced
over multiple instances is a good fit. Retaining full control over the software development life cycle
(SDLC) is also an advantage for teams with mature software development and operations
processes.
The disadvantages of choosing the rehost option include "moving without improving" and the low-
level do-it-yourself (DIY) nature of the service. The primary advantage of HIaaS—teams can migrate
systems quickly, without modifying their architecture—also becomes its primary disadvantage. If a
team rehosts an application using HIaaS without making changes to the application's architecture,
they may not benefit from the cloud characteristics of the infrastructure (e.g., elastic scalability).
Rehosting may afford efficiency and operations improvements in the same way as moving
applications from existing servers into a new data center with server virtualization and consolidation.
However, neither activity makes application architecture improvements.
The unit of compute service offered by HIaaS providers is a VM instance. Before the application's
execution environment can be reproduced, the team needs to create a VM image configured with a
complete stack with all its moving parts and dependencies (e.g., application server). Providers
manage image directories that allow teams to pick the closest image "off the peg." Otherwise, the
team may engage a third-party provider in the HIaaS provider's ecosystem (e.g., CohesiveFT Elastic
Gartner,This
Inc. |research
G00207162
Server) to assemble a bundle, use a physical-to-virtual (P2V) capture tool (e.g., PlateSpin Migrate or
AppZero), or assemble the required stack themselves. One show-stopping issue for HIaaS migration
is whether third-party applications or dependent libraries are licensed and supported for
deployment in a VM. Early-adopter client experiences indicate that developers who deploy
applications to the cloud, particularly using HIaaS, find that they return to the bad old days when
developers had to do their own system administration. Unless the migration strategy simultaneously
brings along app-dev, data management, security, and operations, developers can find themselves
swimming in elastic Internet Protocol (IP) numbers and hacking Domain Name System (DNS)
registries, just to keep their applications running.
Each HIaaS provider has different APIs for management and configuration, and several competing
VM image and storage formats exist. Work on potential standards solutions such as Open Virtual
Machine Format (OVF), vCloud, Deltacloud, and OpenStack is progressing. To date, the largest
HIaaS player, Amazon, has not chosen to participate, thus leaving its Amazon Machine Image (AMI)
format and APIs as de facto standards in the market and its ecosystem. The downside of this
potential lock-in is that tools developed to automate rehosting an application on one provider will
not work with another. Effort spent assembling VM images will be wasted if the team decides to
switch providers. Lock-in is a concern in the cloud/no-cloud decision, but it is not a disadvantage to
HIaaS when compared to the other options. Any migration to the cloud involves lock-in concerns,
but of the five alternatives, rehost has the least lock-in concern. The following documents describe
the HIaaS market in more detail:
■ "Market Profile: Hardware Infrastructure as a Service (HIaaS), 2010"

■ "Amazon EC2: Is It Ready for the Enterprise?"
■ "Cloud Storage: An Emerging Market"
■ "P2V: Migrate or Migraine?"
■ "Virtualization Licensing and Support Lethargy: Curing the Disease That Stalls Virtualization
Adoption"
Refactor
Table 3 concisely defines the refactor migration option.
Page 20 of 45
Table 3. Defining the Refactor Migration Option
Definition ■ Running your applications (usually Web applications) on cloud provider's

infrastructure
■ Make application code or configuration changes to connect the application to
new infrastructure services
■ Similar to linking in a new database driver, identity management system, or
authentication module; also similar to moving a Java EE application from IBM
WebSphere to Red Hat JBoss (same type of container, some different
frameworks and configuration)
■ Necessary changes vary from none to widespread code change to invoke new
APIs
■ 4
Relink/recode is "backward-compatible" PaaS; existing programming models,
languages and frameworks can be used and extended
Cloud model ■ SIaaS and PaaS

tiers
What services ■ Providers supply cloud-based frameworks and management tools that allow
am I developers to take advantage of cloud characteristics of provider's
consuming?
infrastructure
Audience ■ Developers
Examples ■ Deploying Ruby on Rails Web application to Heroku (including linking a

monitoring service based on New Relic) deploying Active Server Pages
for .NET (ASP.NET) app to Windows Azure.
The primary advantage of the refactor strategy is blending familiarity with innovation. "Backward-
compatible" PaaS means developers can reuse languages, frameworks, and containers they have
invested in, thus leveraging code the organization considers strategic. The team can also take
advantage of providers' best practices for cloud architecture, which are baked into providers'
framework abstractions. For example, some providers advocate a non-relational model for big,
distributed datasets. Each provider has its own framework abstraction for workload scaling (e.g.,
Heroku has dynos, slugs, and workers; Google App Engine has automatic scaling using Servlet
abstraction; and Microsoft Windows Azure platform uses tiers and roles).
The disadvantages of a refactor strategy include missing capabilities, transitive risk, and framework
lock-in. At this early stage in the PaaS market, some of the capabilities developers depend on with
existing platforms can be missing from PaaS offerings. Architects should verify that a PaaS
supports the required frameworks and APIs. For example, many existing Java applications can run
on Google App Engine without modification, but not all dependencies and APIs are supported. Java
Gartner,This
Inc. |research
G00207162
Platform, Enterprise Edition (Java EE) apps using EJBs, JDBC, JMX, JCA, JMS, JNDI, or RMI are
currently not supported on App Engine and will need to be modified to work with Google's sandbox
restrictions. Other PaaS offerings may not be so restrictive, such as WSO2 Stratos and Tibco Silver,
but applications may require refactoring in other architecture aspects to fit into their containers.
Some PaaS providers depend on HIaaS providers for infrastructure (e.g., Heroku on Amazon), which
creates a transitive risk for the consumer. For the refactor option, consumers need to be concerned
with code and framework portability. Some PaaS providers do not provide an on-premises product
option in addition to hosting application on their own infrastructure (e.g., force.com or Google App
Engine); other's do (e.g., WSO2 Stratos or LongJump). Code written for providers' specific
frameworks (e.g., Azure AppFabric Service Bus routing or Google's App Engine datastore) will only
work in the provider's environment, although the code may be written in C# or Java. Lock-in is a
bigger concern in refactoring than in rehosting because the development team is adapting the
application to exploit cloud-enabling software-infrastructure-as-a-service (SIaaS) features. Using
those features ties the application more tightly to a specific cloud provider. See the following
references for more details on refactor migration options and the PaaS market:
■ "Market Profile: Platform as a Service 2009"

■ "Cloud Databases: Structure in a Nebulous World"
Revise
Table 4 concisely defines the revise option.
Table 4. Defining the Revise Migration Option
Definition ■ Modify or extend the existing codebase to support legacy modernization

requirements, then use rehost or refactor options to deploy to cloud
■ Scale of changes encompasses major revisions to add new functionality or
rearchitect the application for the cloud
Cloud model tiers ■ HIaaS, SIaaS, or PaaS
What services am ■ Either VMs as a service (HIaaS) or frameworks and management tools that
I consuming? allow developers to take advantage of the cloud characteristics of a
provider's infrastructure (PaaS with or without SIaaS)
Audience ■ Developers
Examples ■ Redesigning a monolithic Java application, decomposing the functions into

smaller parallel chunks, and then deploying on Rackspace Cloud Servers
Choosing the revise alternative, IT organizations can take advantage of a valuable codebase by
enhancing it to meet other cloud adoption or legacy modernization goals. Revision may also be
Page 22 of 45
necessary when an application's target hardware changes, such as with moving native code from
Unix/RISC architecture to x86 systems. Enabling elastic scalability, dynamic reconfiguration, and
creative billing options most likely requires substantial architecture revision. Compared to the other
migration alternatives, revise puts the organization into a position to optimize the application to
leverage the cloud characteristics of providers' infrastructure.
The revise option fits into a range of legacy software modernization strategies, more closely
mapping to "refactor and rebuild" or "services" architecture modernization style (see Figure 2),
because it admits new business requirements.
The downside of revising an application is that kicking off a (possibly major) development project
will require upfront expenses to mobilize a development team. Depending on the scale of the
revision, revise is the option likely to take most time to deliver its capabilities.
See the following references for more details on evaluating revise migration options:
■ "SWLegMod: A Framework for Legacy Software Modernization"

■ Gartner Webinar "Optimizing Cloud Application Architecture with SOA Principles"
■ "Migration from Unix/RISC to x86"
Rebuild
Table 5 concisely defines the rebuild migration option.
Gartner,This
Inc. |research
G00207162
Table 5. Defining the Rebuild Migration Option
Definition ■ Rebuild your solution on a provider's application platform

■ Discard code for an existing application
■ Rebuild requires rearchitecting the application for a new container
■ Tends to be "forward-compatible" or incompatible PaaS: Not all existing
programming models, frameworks, and languages will be retained
■ Similar to moving from Java to .NET, but more likely to be programming for a
container at a higher level of abstraction
Cloud model ■ PaaS

tiers
What services ■ An externally managed application platform for building and running
am I consuming? applications
Audience ■ Developers, "citizen developers"

5
Examples ■ Building a force.com application for order management

■ Modernizing a C and FORTRAN financial risk calculation application by
redesigning it in C#, then using Windows Azure platform libraries and tools to
deploy it to Microsoft's cloud
■ Other providers include LongJump, WaveMaker, Cordys BOP, and Magic
Software uniPaaS
Source: Graphic, Gartner (December 2010)
"Market Profile: Platform as a Service 2009" provides more details on rebuild migration options
supported by the PaaS market and coins a term for providers supporting this option: cloud-native
platforms. This distinguishes vendors that support a rebuild strategy from those in the refactor
bracket, which are described as "earth-born migrants."
Although rebuilding requires giving up the familiarity of existing code and frameworks, the
advantage of rebuilding an application is access to innovative features in the provider's container.
Developer productivity is improved with tools that allow application templates and data models to
be customized, metadata-driven engines, and communities that supply prebuilt components. This
emphasis on metadata-driven (i.e., "point 'n' click" programming) approaches rather than code
gives non-professional developers (i.e., "citizen developers") the opportunity to develop and deploy
simple applications. PaaS offerings allow applications to transparently and automatically scale when
they are written to comply with the provider's framework and container model. Finally, cloud-native
platforms that exploit multi-tenancy automatically upgrade every tenanted application,
simultaneously freeing the consumer from patching, upgrading dependencies, and migrating users
between versions.
Page 24 of 45
With innovative PaaS platforms, lock-in is the primary disadvantage. Abandoning familiar
programming languages and frameworks means that second sourcing strategies to mitigate lock-in
risk may not work. If the provider makes a pricing or technical change that the consumer cannot
accept, breaches SLAs, or fails catastrophically (e.g., Coghead), the consumer is forced to switch,
potentially abandoning some or all of its application assets.
Replace
Table 6 concisely defines the replace migration option.
Table 6. Defining the Replace Migration Option
Definition ■ Discard an existing application (or set of applications) and use commercial
software delivered as a service (SaaS) to satisfy those business requirements
■ Typically, existing data requires migration to the SaaS environment
Cloud model tiers ■ SaaS
What services am ■ A complete, turnkey application solution (i.e., IT organization does not build
I consuming? solution but may configure and integrate it); users access SaaS via a user-
centric interface, such as a Web browser or a mobile device; application data
import/export is achieved with an API or configuration/admin console
Audience ■ Users—business or IT; Developers or DBAs perform initial configuration
Examples ■ Salesforce CRM, SugarCRM for customer records management

■ Workday for HR processes
■ Omniture for Web analytics, Live Meeting for Web conferencing
Unlike custom-built software or single-tenant COTS, SaaS providers can monitor and leverage
group behavior within a single tenant (one department or company), or across many tenants. Many
of the typical advantages of buy-before-build sourcing apply to replacing applications with SaaS.
Avoiding investment in mobilizing a development team is a clear advantage when requirements for a
business function change quickly.
Inconsistent data semantics, data access issues, and lock-in are crucial considerations for SaaS. As
Mike Rollings describes in his "Planning Considerations for Externalization and Cloud Computing":
Data within SaaS applications has a tendency to become land-locked because it is difficult to
interpret, access, and use. Many times, the information model for the application is designed to
be convenient to the vendor, and not many SaaS applications include documentation on their
logical data models. . . . As a result, an additional set of data semantics must coalesce with
existing meanings—of which there may be several—in an organization.
Gartner,This
Inc. |research
G00207162
Furthermore, organizations may struggle to gain access to the data even if it can understand it.
Will data and processes within SaaS, PaaS, or SIaaS be usable within an organization's
processes, workflows, and analytical environments without data transformations that hinder
performance? . . . Latency may force the use of data extracts, file transports, and data imports
as the only means for reasonable data access.
Unless a SaaS adoption plan includes a firm schedule for retiring replaced application(s) and the
governance oversight to see it through, new software (even delivered as a service) adds more
complexity and redundancy to the applications portfolio landscape.
Stretching SaaS beyond basic reconfiguration can be difficult. SaaS varies in the range of
configuration and personalization possible for each tenant. A SaaS provider's ecosystem size and
influence determines whether APIs and partner solutions can be used for heavier integration work.
Unless the business processes replaced by the SaaS can be isolated, integration with existing
systems and processes may be more difficult than with other migration options because APIs may
not be available, well-built, well-documented, or usable. SaaS adoption often requires a change to
internal business processes. This is not a good option if the process is unique or provides a
competitive advantage or if business users are not willing to adopt a different process.
See the following IT1 documents for more guidance:
■ "Considerations for Risk Management When Choosing Software as a Service"

■ "Planning Considerations for Externalization and Cloud Computing"
■ "Market Profile: The Amazing SaaS E-Mail Race 2010"
■ "SaaS Implementation Survey: Where, When, and How to Use SaaS"
Comparing Alternatives
Table 7 compares the change impact of each alternative migration strategy on common aspects of
an application.
Page 26 of 45
Table 7. Which Elements of the Migrated Application Change, Need to Be Updated, or Entirely Replaced with
Each Alternative?
Rehost Refactor Revise Rebuild Replace
Programming language Same Same Same Same/new N/A
Source code Same/ Updated Updated/new New N/A

updated
Application configuration/ Same/ Extended Extended New N/A

metadata updated
Frameworks Same Same/new Same/new New N/A
Containers Same Same Same/new New N/A
Application data Same Same/ Same/ Transformed Transformed

transformed transformed
Hosting hardware New New New New New
Distinguishing Products from Services

So far, this Decision Point has made no distinction here between public and private cloud options.
The distinction can be clearly made when considering what a purchaser is paying for: With
products, you buy the software; with services: you pay for access to the service. Table 8
summarizes this distinction, giving examples at HIaaS and PaaS tiers.
Gartner,This
Inc. |research
G00207162
Table 8. Distinguishing Cloud Services from Enabling Products
Services Products
What are Access to the service License to use software

you paying
for?
Example 1: Someone else is racking the hardware; their software Software (and appliance) products enable
HIaaS creates new instances, configures them, supports you, both internal IT organizations and external
and bills you per amount consumed. providers to build private HIaaS in a data
Example HIaaS service providers are center of your choice.
Amazon.com's AWS, Rackspace Cloud Servers, Example vendors are VMware, Citrix,
Terremark vCloudExpress/Enterprise Cloud, and Platform Computing, 3Tera, Eucalyptus
Microsoft Windows Azure. Systems, and IBM.
Example 2: Full application platform service offering, hosted by the An as-a-product offering, deployed by the
PaaS provider, or provided as an image and hosted by a buyer in its data center of choice in a
HIaaS partner. Accessed on the Web by the developer. cloud-enabled application platform.
6
Example providers include force.com, Heroku, Tibco Example vendors include Apprendra
Silver, and WSO2 Stratos SaaSGrid and LongJump
The advice this Decision Point delivers applies to application migration using both services and
products to create private or internal clouds. Refer to the "Adjacent and Related Markets" and
"Related and Adjacent Markets" sections of both of the following documents, respectively, for
7
further discussion of the cloud-enabling product versus service distinction:

Future Developments
Several trends in the industry are occurring in response to market pressures. These trends may
affect the decision to adopt cloud at one tier or another and can be summarized in the following
areas:
■ Progress on portability standards

■ Evolution of cloud business models
■ Incumbent platform players will wake up
Progress on Portability Standards

Risks of platform lock-in exist at every tier of the cloud. Organizations should monitor
standardization efforts and vendor support to enable portability of the following aspects:
Page 28 of 45
■ VM portability: As discussed in the "Rehost" section of this Decision Point, organizations such
as Distributed Management Task Force (DMTF) are busily developing standards for VM image
format and cloud management APIs submitted frequently by vendor coalitions. For example,
Oracle recently submitted a subset of the cloud management API they acquired with Sun to the
DMTF Cloud Management Working Group. The number of overlapping proposals to consider,
including other open cloud initiatives such as vCloud, OpenStack, and Deltacloud means that
standards efforts are fragmented. Without Amazon's participation, these efforts are valiant, but
represent only a minority of the industry and may not have significant impact on enterprise
decision making.
■ Code portability: Deploying applications across multiple cloud environments will become a
driver and a differentiator. Standards efforts presently focus on HIaaS and data portability
issues. In the absence of open standards, progress on code portability tends to be limited to
coalitions of vendors and service providers, such as the relationships VMware has formed with
Google and saleforce.com to promote the Spring Framework as a portable "programming
model for the cloud." Portability is such a hot adoption issue for organizations that proprietary
PaaS offerings with high lock-in risk will not survive; this will force some innovative pure-plays
out of the market.
■ Data portability: Microsoft's Open Data Protocol (OData) and Google's Google Data Protocol
(GData) are the platform giants' responses to the issue of portable data access. Both offer a
Web protocol for querying and updating data using HTTP, JavaScript Object Notation (JSON),
and Atom Publishing Protocol (AtomPub). GData is the basis for Google Data APIs for all of
Google's services (e.g., Google Apps, Calendar, Finance, Health, and YouTube). Both Microsoft
and Google have extended AtomPub in various ways, and Microsoft suggests:
Since OData is based on AtomPub, it is possible for OData clients and services to be
written with minimal extra code allowing them to work with AtomPub (and GData) data.
Data access based on standards, interoperable or not, does not solve data portability issues
because access does not concern itself with data semantics. For example, if an organization
wants to move its application back on premises or to another provider, the following questions
are pertinent: "Can it get all of its data out of the provider's datastore, in a reasonable time, and
at a reasonable cost? Will it still understand it? How many of its original relationships are
preserved? Can its current provider supply useful metadata (e.g., logical or physical data
schema)? Now that the organization has migrated away from the provider, can it prove that its
data has been deleted?"
Concerns about data portability are most acutely felt in the consumer and social networking
clouds. Efforts such as DataPortability Project and Google's Data Liberation Front aim to make
users' data as portable as possible across services.
Refer to the following documents for further discussion of portability at different levels:

Gartner,This
Inc. |research
G00207162
Evolution of Cloud Business Models

The HIaaS and PaaS markets in particular will change dramatically in the next three years. Factors
influencing this change include:
■ Today's cloud offerings are prototypes; pricing models, SLAs, and terms and conditions will all
change to become more flexible and a basis for genuine competition in the market.
■ Unintended consequences of today's immature pricing models influence service consumption
patterns. For example, aspects of application runtime behavior, such as data movement, that
were considered "free" (incorrectly) are now explicitly priced.
■ ISVs will be forced toward providing SPLAs to allow cloud providers to bundle the price of
software into the price of the compute service. This will unshackle many applications that today
cannot be migrated because their third-party dependencies are not licensed for execution on a
VM or with a PAYG model.
■ Private cloud offerings will continue to mature; these will offer many of the cloud characteristics
without the regulatory and contractual risks.
■ Cloud brokers and other ecosystem players will emerge. This means cloud migration will require
less low-level, DIY, system administration, and DBA work (particularly in the HIaaS space).
Incumbent Platform Players Will Wake Up

Both SAP and Oracle offer some of their range of business applications as SaaS. However, neither
SAP nor Oracle has yet shown its hands as a PaaS service provider. Oracle and IBM are presently
pursuing a stopgap strategy by partnering with Amazon at the HIaaS tier to provide certified AMIs of
some of their software products—licensed on a bring-your-own (BYO) or PAYG model. Oracle also
offers a Virtual Assembly Builder for assembling VM images with complete stacks for HIaaS
environments.
To date, the incumbent platform players only support the rehost and refactor options, which limits
options in organizations that have a strict superplatform or "single vendor where possible" principle.
Efforts to move into other markets (rebuild on cloud-native PaaS, particularly) could have a
significant impact on the decision. Similarly, if superplatform players begin offering compelling
migration kits and standard PAYG licensing models for all their middleware and applications, they
will likely disrupt the market and influence decisions.
The major platform vendors are torn between two business models because they retain a vested
interest in keeping customers on their existing platforms with dependable maintenance and support
revenue streams. Refer to the "Vendor Trends" section of "Market Profile: Platform as a Service
2009" for more details on forces the market is exerting on platform vendors.
Page 30 of 45
Decision Tool
Selecting a cloud migration option for given business applications and data requires a series of
interrelated decisions that are influenced by a number of often conflicting factors, including
application requirements, constraints, personnel skills, and organizational principles. These factors
are described in the "Evaluation Criteria" section of this Decision Point.
Pre-Decision Assumptions
As stated in the "Decision Context" section of this Decision Point, IT decision makers have already
decided to migrate this application to cloud. Before using the tools in this section, decision makers
should first make a number of assumptions.
Assumption 1: Quality of Service Risks

Issues Gartner clients mention as the highest cloud adoption barriers include service provider trust,
user support, security, service-level quality, confidentiality, and additional operational complexity
issues inevitably pertaining to any externalization arrangement. The "Data Center Sourcing: Cloud,
Host, Co-Lo, or Do It Yourself" Decision Point provides additional operational, resiliency, and
recovery requirements impacting quality of service (QoS).
Architects need to approach these QoS requirements with a different mind-set and toolset than they
do with service levels for on-premises applications. Some risks to service levels cannot be avoided,
pre-determined, or quantified prior to hosting applications in the cloud. Today's public cloud
providers typically do not offer a variety of service levels, and the "take-it-or-leave-it" approach to
service levels may not meet an application's SLAs.
Inadequate service-level guarantees represent a significant cloud adoption barrier for enterprise
applications. However, to examine other issues, this Decision Point assumes that if the application
has very stringent service level requirements, then it isn't a candidate for migration to the cloud, and
therefore this Decision Point does not apply.
This Decision Point assumes that either:
■ These risks can be satisfactorily addressed and will be manageable.

■ If the application has very stringent service level requirements, then it isn't a candidate for
migration to the cloud, and therefore this Decision Point does not apply.
This assumption does not intend to minimize these most pressing adoption barriers, but they are
covered in detail in the following IT1 documents, which contain guidance on managing service-level
risks:
■ "Managing Availability and Performance Risks in the Cloud: Expect the Unexpected"
■ "Using Encryption to Protect Sensitive Data in Cloud Computing Environments"
■ "Data Availability in the Cloud"
Gartner,This
Inc. |research
G00207162
■ "Framework for Improving Application Performance over the WAN and the Cloud"
■ "Managing Network Performance of Cloud-Based Applications"
Assumption 2: IT Portfolio Management Frameworks

Prior to using this decision tool, organizations should apply the APM guidance frameworks
described in the "Architectural Context" section of this Decision Point for each application and
service. The frameworks will arm the organization with detailed information on the architecture
characteristics, criticality, and value of the application to the enterprise. Architects have already
identified the "cloud or not" characteristics of the application that make it suitable for cloud
migration, such as the following:
■ The application is relatively isolated, with a manageable number of dependent applications and
resolvable direct infrastructure dependencies (e.g., tied to specific hardware or software
libraries).
■ The demand pattern for the application is bursty, seasonal, or otherwise not constant. Cloud
deployment economics make it unlikely that a cloud sourcing strategy makes sense if an
application is in constant use 24/7 (or in engineering terms, the application has a high duty
cycle).
In parallel with the APM guidance, decision makers should apply the guidance framework in
"Building a Solid Cloud Adoption Strategy: Success by Design." Additionally, the Decision Points
listed in the "Related Decisions" section of this Decision Point should also be considered.
Using the Decision Tools

Figure 5 outlines the steps needed to use the decision tools to assist teams in making cloud
migration decisions.
Page 32 of 45
Figure 5. Steps Required to Use the Cloud Migration Decision Tools
Decision Filters
One or more factors can rule out each of the migration alternatives. Use the decision filters that
follow to narrow the migration options that should be considered further for the applications under
evaluation.
Filter out Rehost
Conditions that rule out rehosting the application on HIaaS concern operations team skills,
modernization requirements, licensing restrictions, and application form-factor, as illustrated in
Figure 6.
Gartner,This
Inc. |research
G00207162
Figure 6. Conditions for Filtering out the Rehost Migration Alternative
Filter out, Refactor, or Revise
Conditions that rule out refactoring the application for PaaS with new SIaaS or revising the
application include development-team skills, time to market, and requirement volatility.
Page 34 of 45
Figure 7. Conditions for Filtering out the Refactor and Revise Migration Alternatives
Filter out Rebuild
Rebuilding on PaaS with proprietary frameworks or programming language constructs is ruled out if
the organization considers the risk of being locked into those features too great or if the
organization has a strict sourcing policy favoring established vendors.
Gartner,This
Inc. |research
G00207162
Figure 8. Conditions for Filtering out the Rebuild Migration Alternative
Filter out Replace
Conditions that rule out replacing the application with SaaS include level of competitive advantage
afforded by the processes supported by the application, the business users' willingness to modify
their business processes, the anticipated required level of customization or integration with on-
premises systems, and the organization's attitude toward data lock-in.
Page 36 of 45
Figure 9. Conditions for Filtering out the Replace Migration Alternative
Migration Goals Assessment Tool

Use the migration goals assessment tool to identity the alternative that best fits the migration goals
for this application. Using Kiviat diagrams, the tool allows the project team to assign weights to the
migration goals and to visually compare them to the capabilities supported by the alternatives. The
decision tool is implemented as an Excel spreadsheet, which is available for download at the top of
this Web page.
Using the migration goals assessment tool to assist in selecting a cloud migration option is a three-
step process:
1. Choose the "Alternative Assessment Tool" sheet in the "Cloud Migration Decision Toolkit.xls"
workbook (available for download at the top of this Web page). Prioritize the migration goals for
the application under consideration. Choose "1" when the migration goal is not important, "2"
Gartner,This
Inc. |research
G00207162
when the goal is somewhat important, and "3" when the goal is essential to the success of the
project.
2. Choose from the list of alternative migration strategies in cell F7. (Use "Decision Filters" to
narrow the list of alternatives that should be evaluated.) Scores for each alternative's support
for migration goals (and a brief explanation comment) can be found in the "Migration Goals
Support" worksheet. The data is copied into cells F8:F16 in the "Alternative Assessment Tool"
sheet when different alternatives are chosen.
3. Compare the alignment of support for migration goals selected in Step 2 with the priorities for
the project selected in Step 1. Step 3 maps prioritized migration project goals to the Kiviat
diagram. Support for those goals in the alternative strategy selected is then plotted and overlaid
on the diagram. Visually comparing the overlap gives a quick guide to the suitability of an
alternative. Uncovered areas of highly prioritized goals for the project are easily spotted and
need examination.
See the "Decision Justification" section of this Decision Point for a brief explanation of why each
decision is recommended and for a summary of the conditions when the decision best applies.
The decision may be tied if more than one migration alternative closely matches the project's
priorities. Choosing between the applicable options becomes a prioritization and a sourcing
decision, which requires teams to analyze requests for quotations (RFQs) from providers, including
factors such as vendor preference and cost. Architects should evaluate vendors on their abilities to
deliver the requirements discussed in the "Requirements and Constraints" section of this Decision
Point.
Finally, prepare to fail! The IT1 management initiative "The Dark Side of Cloud Computing" presents
an IT management perspective on the implementation pitfalls and negative implications of any cloud
migration choice.
Decision Justification
This section provides a brief explanation for each decision and summary of the conditions for which
the decision applies.
Use Rehost
The rehost alternative is appropriate when leveraging existing software investments is a primary
goal. HIaaS is most appropriate for the following scenarios:
■ Compute-intensive applications that are built for parallelism but don't require high-performance
inter-process communications (IPC) and have independent datasets. Applications for which
load balancing already increases scalability and availability.
■ Transient applications for which the hardware is not available or worth additional investment.
HIaaS also appeals to organizations that lack capital to procure enterprise IT infrastructure (e.g.,
startups or new lines of business).
Page 38 of 45
Rehost options can be ruled out when licensing compatibility for third-party software cannot be
extended to VMs or if the architecture doesn't fit (e.g., fat client architecture).
Use Refactor
Deploying a modified application onto a PaaS provider's platform is optimal when leveraging an
existing mature development skill set and codebase is paramount and code portability is a concern.
Application fit is crucial: When the application fits a standard pattern (e.g., n-tier Web application) or
can be easily redesigned to work within the providers' sandbox restrictions, refactoring can be a
productive and cost-effective execution environment.
Refactoring is not an appropriate option and can be ruled out when an application cannot easily be
adapted to meet provider's sandbox restrictions or when skills or infrastructure to rebuild existing
code are unavailable (e.g., build scripts or dependencies cannot be located and fixed, or developers
cannot be assigned the task).
Use Revise
Revise is an appropriate option when the application needs a major revision to incorporate new
capabilities or to work more effectively on a cloud platform.
Revise should be ruled out if time to market is the overriding priority, project scope creep is an
unacceptable risk, or the codebase is no longer valuable to the organization.
Use Rebuild
Rebuilding an application for a PaaS service is most appropriate when rapid prototyping is crucial or
the scope of an application is limited (e.g., limited by life span or limited to a specific audience).
Another sweet spot for PaaS is extending previous investment in a cloud platform (e.g., if the
organization's customer data has already been migrated to Salesforce CRM or if the company
extensively uses Google Apps as its productivity suite).
Rebuilding an application for a proprietary PaaS should be ruled out when risk of code or framework
lock-in is considered unacceptably high or if vendor sourcing strategy rules out smaller vendors. If
rapid time to market for the application is paramount, rebuilding complex functionality for a new
container is not a good choice.
Use Replace
Financial control scenarios that favor SaaS include urgent cash flow and lower operational
expenses requirements. Upfront costs are likely to be lower with SaaS than alternatives, and
providers often offer try-before-you-buy access, thereby providing application value more rapidly.
SaaS also offers an opportunity to rapidly reassign or cut IT head count.
SaaS is also appropriate when demand for a commodity service can't be met in-house (e.g., Web
conferencing and Web analytics) or the enterprise doesn't have the IT skills or resources to run
complex software in-house.
Gartner,This
Inc. |research
G00207162
Choosing SaaS is also a sensible strategy when business requirements change quickly because
SaaS avoids the involvement of a development team. For example, when a company is figuring out
enterprise social networking capabilities, prototyping different products can be valuable.
SaaS is best avoided when the organization is unsure about the level of integration and
customization to the core feature set it will require. Enterprises sometimes overlook crucial
configuration and ecosystem requirements, which limits the APIs and partner solutions used for
integration work. SaaS can lose its long-term value if the organization has little or no flexibility over
the data model, semantics, locations, sources, or security, or when data switching costs are
exorbitant. Some SaaS vendors will charge enterprises for extracting data from their services. SaaS
is also ruled out if the enterprise is not willing or able to modify its business processes.
Recommended Reading
Some documents may not be available as part of your current Gartner subscription.
Gartner documents that are related to, and will impact, the cloud migration decision are listed
below:
■ Gartner IT1 documents:

■ "Building a Solid Cloud Adoption Strategy: Success by Design"
■ "Cloud Computing: Transforming IT"
■ "Cloud Storage: An Emerging Market"
■ "P2V: Migrate or Migraine?"
■ "Virtualization Licensing and Support Lethargy: Curing the Disease That Stalls Virtualization
Adoption"
■ "Cloud Databases: Structure in a Nebulous World"
■ "Application Platform Strategies for the 2010's"
■ "2010 Planning Guide: Application Platform Strategies"
■ "Build, Buy, or Borrow: Choosing Custom Development Software, Open Source Software,
Commercial Off-the-Shelf Software, or Software as a Service"
■ "Developing a Cloud Computing Security Strategy"
■ "Using Encryption to Protect Sensitive Data in Cloud Computing Environments"
Page 40 of 45
■ "Planning Considerations for Externalization and Cloud Computing"
■ "Moving Out: The Externalization of IT"
■ "The Dark Side of Cloud Computing"
■ "Market Profile: The Amazing SaaS E-Mail Race 2010"
■ "Software as a Service Enterprise E-mail: Get Ready to Go Beyond the Grind"
■ "SaaS Implementation Survey: Where, When, and How to Use SaaS"
■ "Who's Who in Application Platforms for Cloud Computing: The Cloud Specialists"
■ "Who's Who in Application Platforms for Cloud Computing: The Enterprise Generalists"
■ "Cool Vendors in Application Platforms as a Service, 2010"
■ "Gartner Reference Architecture for Multitenancy"
Revision History
December 2010
■ Initial version.
Gartner,This
Inc. |research
G00207162
Acronym Key and Glossary Terms
2PC two-phase commit
AMI Amazon Machine Image
APM application portfolio management
ASP.NET Active Server Pages for .NET
AtomPub Atom Publishing Protocol
AWS Amazon Web Services
BYO bring your own
COTS commercial off-the-shelf
DBA database administrator
DIY do it yourself
DMTF Distributed Management Task Force
DNS Domain Name System
EBS Elastic Block Store
EC2 Elastic Compute Cloud
GData Google Data Protocol
HIaaS hardware infrastructure as a service
IP Internet Protocol
IPC inter-process communications
IPM infrastructure portfolio management
ISV independent software vendor
Java EE Java Platform, Enterprise Edition
JSON JavaScript Object Notation
OData Open Data Protocol
OLTP online transaction processing
Page 42 of 45
OVF Open Virtual Machine Format
P2V physical to virtual
PaaS platform as a service
PAYG pay as you go
QoS quality of service
RAD rapid application development
RFQ request for quotation
RISC reduced instruction set computer
SaaS software as a service
SDLC software development life cycle
SIaaS software infrastructure as a service
SLA service-level agreement
SPLA Services Provider License Agreement
SSAF strategic software assessment framework
SWLegMod structured program for legacy software modernization
VM virtual machine
Notes
1 The terms "core" and "context" are described in the IT1 Perspective document "Moving Out: The
Externalization of IT" and derive from Geoffrey Moore's book Living on the Fault Line: Managing for
Shareholder Value in the Age of the Internet. Moore defines core activities as those that directly
affect the company's competitive advantage; everything else is context.
2 The following quote from Chris Keene, CEO of PaaS provider WaveMaker, makes the point about
rapid application development (RAD): "It comes back to the Mount Everest thing. If in order to climb
a mountain it's going to cost me $250,000, no matter the size of the mountain, well, then I am going
to tend to do a lot—I am going to tend to do a lot more every time I get that thing together. So IT
doesn't build "apps," IT builds applications, and the reason for that is, it costs so much for them to
get out of bed in the morning, that it's not worthwhile to get out of the bed to move around a few
Gartner,This
Inc. |research
G00207162
things, I have got to do something really big and really meaningful in order to justify the cost, just for
them to do anything."
3 "DevOps" is a recently identified sub-species of IT professional (typically either infrastructure-

savvy developers or development-minded system administrators) skilled in templating and scripting
infrastructure configuration for automatic consumption and deployment of infrastructure services.
4William Vambenepe. "PaaS portability challenges and the VMforce example." William
Vambenepe's blog. 28 Apr 2010.
5Eric Knipp, David Norton, Nicholas Gall. "Citizen Developers Are Poised to Grow." Gartner. 23 Mar
2010.
6Yefim V. Natis, Massimo Pezzini, Eric Knipp. "Gartner Reference Architecture for Cloud-Enabled
Application Platforms." Gartner. 6 Jul 2010.
7Also see this Bertrand Meyer speech that provides a humorous look into whether software is a
product or a service.
Page 44 of 45
GARTNER HEADQUARTERS
Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096
Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM
For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp
© 2010 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see “Guiding Principles on Independence and Objectivity.”
Gartner,This
Inc. |research
G00207162

Migrating Applications To TH 207162

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Migrating Applications To TH 207162

Uploaded by

Copyright:

Available Formats

G00207162

Migrating Applications to the Cloud: Rehost,

Analyst(s): Richard Watson

This research note is restricted to the personal use of guilherme.martins@unicred.com.br.

Figure 1. IT Portfolio Management Programs Giving This Decision Point Context....................................5

As economic pressures increase, organizations have expressed overwhelming interest in cloud

Figure 1. IT Portfolio Management Programs Giving This Decision Point Context

Source: Gartner (December 2010)

Source: Gartner (December 2010)

Figure 2. Legacy Modernization Options Mapped to Cloud Migration Alternatives

Source: Gartner (December 2010)

Source: Gartner (December 2010)

■ Requirements and constraints

Requirements and Constraints

■ Migration goals and priorities

Migration Goals and Priorities

■ "Cloud Computing: Transforming IT"

Legacy Application Characteristics

Application Platform and Architecture Principles

Development and Operations Skills Constraints

Migration Cost Considerations

■ Degree of autonomy: Because of PAYG and self-service characteristics, application migration

Source: Gartner (December 2010)

Definition ■ Redeploy the application to a different hardware environment

Cloud model tiers ■ HIaas and SIaaS

What services am I ■ VMs as a service/OSs as a service, block or volume storage as a service

Audience ■ System administrators, operations staff, "DevOps"

Examples ■ Deploying an existing Java EE container with a Java EE application on EC2

Source: Gartner (December 2010)

■ "Market Profile: Hardware Infrastructure as a Service (HIaaS), 2010"

Definition ■ Running your applications (usually Web applications) on cloud provider's

Cloud model ■ SIaaS and PaaS

Examples ■ Deploying Ruby on Rails Web application to Heroku (including linking a

Source: Gartner (December 2010)

■ "Market Profile: Platform as a Service 2009"

Table 4. Defining the Revise Migration Option

Definition ■ Modify or extend the existing codebase to support legacy modernization

Cloud model tiers ■ HIaaS, SIaaS, or PaaS

Examples ■ Redesigning a monolithic Java application, decomposing the functions into

Source: Gartner (December 2010)

■ "SWLegMod: A Framework for Legacy Software Modernization"

Definition ■ Rebuild your solution on a provider's application platform

Cloud model ■ PaaS

Audience ■ Developers, "citizen developers"

Examples ■ Building a force.com application for order management

Source: Graphic, Gartner (December 2010)

Table 6. Defining the Replace Migration Option

Cloud model tiers ■ SaaS

Audience ■ Users—business or IT; Developers or DBAs perform initial configuration

Examples ■ Salesforce CRM, SugarCRM for customer records management

Source: Gartner (December 2010)

See the following IT1 documents for more guidance:

■ "Considerations for Risk Management When Choosing Software as a Service"

Rehost Refactor Revise Rebuild Replace

Programming language Same Same Same Same/new N/A

Source code Same/ Updated Updated/new New N/A

Application configuration/ Same/ Extended Extended New N/A

Frameworks Same Same/new Same/new New N/A

Containers Same Same Same/new New N/A

Application data Same Same/ Same/ Transformed Transformed

Hosting hardware New New New New New

Source: Gartner (December 2010)

Distinguishing Products from Services