SMART CLOUD MIGRATION

A PROVEN, BUSINESS-FOCUSED APPROACH

“WE WOULD LIKE TO DISCUSS
OUR CLOUD MIGRATION.”

It is a frequent topic of discussion least sophisticated clusters. This is the

these days. Most enterprises are “canary-based” approach to migration,
contemplating or already migrating to which first migrates less complex apps and
the cloud. Companies deal with a sense of software and tests for any negative effects.
overwhelming complexity and risk. They (See Exhibit 1: “Smart Migration Strategy,”
worry about how to generate value and not which outlines the processes described in
just “migrate for the sake of migrating.” this paper).
They wonder where to start and how
to proceed. A cloud migration should directly embrace
IT-process automation for repeatability
This paper lays out a smart cloud-migration and re-use, and prioritize pre-production
strategy. The first step is to establish clear environments. It is essential to keep an
business goals. The second step is to group open mind about cloud innovation; just
applications into “clusters,” which leads looking for cost reduction is short-sighted.
to a 6-step sequential migration plan, Balance the need for cost-efficiency against
treating different clusters in different ways. the upside of disruptive cloud capabilities,
To execute, start migrating pre-production such as machine learning or natural-
applications, and then the smallest and language processing.

Exhibit 1: SMART MIGRATION STRATEGY

EXECUTION
• Lower level baseline
• Scripted migration
DEFINE factory where possible
APPLICATION • Canary model for migration
CLUSTERS
1 • High level baseline
• Define application clusters
3 • Governance interlock for
prioritization and impact
management
5

BASELINE & GOALS 6 STEPS REVIEW

• Cost vs. innovation vs.
time to market priorities
2 MIGRATION PLAN
1. Application disposition
4 & EXPAND
• Continued application
• Scope 2. Choose target platforms re-factoring
• Define KPIs and governance 3. Define non-production strategy • Capture lessons
4. Prioritize clusters learned & business case
5. Enable forensics • Evolve migration
6. Evaluate third-party applications automation to
compliance checking
• Adjust operating
model, train the
broader team

1
 THE STARTING POINT Some companies tend to underestimate
the relevance of innovation in migration
projects. Managers tend to concentrate on
Any migration project should start with a
cost/risk avoidance, and see migration as
statement of objectives, along with their
an internal IT activity. But using migration
related baseline. What are the business goals
as a springboard to innovation – enabling
and objectives for migration?
new business capabilities and business
•• For savings: Do we understand total models – will yield greater results.
cost of ownership (TCO) by application?
Do we understand where costs are tied
to committed investments and budgets DEFINE APPLICATION
(such as infrastructure-lease contracts)?
CLUSTERS
•• For time to market: Is there a link
and commitment to the Software
Development Lifecycle (SDLC), and is the Cloud migration with a clear intent is
process part of the change program? complex, and requires a more abstract and
•• For innovation: Is there an open-ended suitable view of the application environment.
view that is aligned with the business Some enterprises have segmented their
strategy on where to unleash IT-enabled applications by size or cost. A better
innovation? Is there a readiness approach is to follow natural points of
to invest? modularity and segment the application
•• For any other KPIs (cost and business base into clusters along natural “fault
metrics, percentage of public cloud lines” (see Table 1: “Applications Clusters
migration), what are the baseline and Migration Challenges”). This will also
metrics and governance?
segregate different migration approaches.
Enterprises will usually end up with a mix
of the above objectives and refine them Here’s a quick rundown of the application
during baselining. Once these essential clusters. Web front-ends deliver the user
questions are answered, a more thorough experience – how the interaction feels, and
baseline is required and configurations how the data is presented. These front-
should be compiled by a team that holds ends are complemented by standard,
the tacit knowledge of the targeted- horizontal, workplace applications,
application portfolio. such as collaboration, video, chat, and
email. Systems of integration create
Often, a cloud migration offers a viable the insights and connections between
opportunity to consider the make vs. buy multiple data sources, and perform all
issue, and reconsider which elements key custom operations. These “Mudball”
of the value chain should be handled by apps (Systems of Integration) deserve
external providers. Cloud computing allows special attention. Their cloud migration is
enterprises to move from outsourced iterative. Mudball apps contain a host of
vertical-application silos to outsourced highly interconnected – and sometimes
capability layers with well abstracted inadequately documented – functions
interfaces, while retaining innovation that requires deeper analysis and modular
capabilities in-house. Of course, this requires decomposition. They are supported by
an understanding of the team’s capabilities grid or other homogeneous calculation
to master and lead the transformation and tools very suitable for cloud migration. In
later own innovation. turn, they connect to the core third-party
applications, which are at the heart of almost
all enterprise-IT systems (Oracle and SAP
exemplify this category). These third-party

Copyright © 2018 Oliver Wyman

Table 1: APPLICATION CLUSTERS AND MIGRATION CHALLENGES

APPLICATION TYPICAL MIGRATION MIGRATION INTENT

CLUSTER FUNCTIONALITY COST % CHALLENGES (% - LEVEL OF COST FOCUS)
Web Front-ends User Interface and data 10% Easy to decouple; Higher scalability; faster
presentation to internal transactional data feature rollout; higher
and external users flow; stateless resilience (30%)
Workplace Collaboration, email, 10% Easy to migrate; watch Lower cost; policy-based
voice, video for usage outside collaboration with third
corporate firewall parties; support mobile
workforce (30%)
Systems of Customized apps to 25% Complex Feature velocity;
Integration support transactions interdependence robustness; enable process
(“Mudballs”) in line with business between applications; transformation (50%)
process; middleware migration modules
systems integrating and embrace 80% application
exposing logic to front- communication
ends
Calculation/Grid Perform complex model 5% Migration of large data Scalability; cost management
computation on large sets: time consuming; (50%)
data sets data gravity
Third-party Dedicated functionality 7% Dependent on vendor Lower cost (50%); feature
Applications delivered by external roadmap may require velocity (50%)
vendor, for example leapfrogging SW
transaction processing, revisions - issues with
billing, and ERP, … backward compatibility
Systems of Record Billing, order, and 28% Security implications; Lower cost (50%)
account management; data gravity implications
batch processing
Glue Apps Highly networked 5% Customization, often Keep functionality
small-scale apps, often developed in-house and support overall
developed in house architecture (10%)
System Platforms DNS, authentication, 10% Security implications; Lower cost (20–40%);
monitoring, asset complex to move (HA feature velocity
mgt, API gateways, always-on requirements)
development workflow,
firewalls, load balancers

applications rely on systems of record that Generally, a cloud migration can create a
hold the bulk of corporate data. Third-party higher feature velocity when it is combined
applications require interaction with the with modularization and the construction
vendor and a conscious decision on what of microservices. A “lift-and-shift” of a
to migrate, what to leave to the vendor’s workload onto a virtual infrastructure does
roadmap, and what simply to keep and not create feature velocity. Typical challenges
replace later. Third-party vendors need found in a few clusters are data gravity (the
to explain their cloud plans in detail to need to migrate large amounts of data), and
prove value. high availability and other infrastructure-
related requirements.
There are two supporting application
clusters: Glue apps, highly customized or Application clusters provide the abstraction
in-house interface applications that perform level at which business leaders and
custom integration tasks; and system executives should be involved to set
platforms for abstraction and automation, priorities without being exposed to the
system and storage management, firewalls, full granular complexity. Application
and other security workloads. In the table clusters should allow business units to
above, the Migration Intent column calls out discuss innovation versus cost focus,
the main benefits for each cluster during a and development priorities. Introducing
cloud migration. too much complexity at this level creates
the pitfall of becoming solely cost/risk
avoidance focused.
3
 MIGRATION PLANNING •• Is the application scheduled
for replacement/phase-out or
to depreciate?
Once you have clarity on the business •• Is there a need to re-factor the
benefits and have grouped applications application to enable velocity gains?
into clusters, you are in a position to create •• Will the application migrate in standard
a master plan that details the sequencing fashion and move to a container?
for migration. Thorough preparation
minimizes risk; resist the urge for immediate These dispositions require budget estimates
action. Execution without a clear end-goal and must have an approximate (quarterly)
guarantees failure. Migration planning time-frame identified. This process step
involves the following: feeds directly into the target application list
for migration and informs the priority.

1. ASSESS APPLICATION
DISPOSITION 2. CHOOSE TARGET
PLATFORMS
Conduct a top-down inventory of all
applications, and require the application As evidenced above, migrating each
owners to provide a clear future disposition application cluster has its own motives
of that application: and challenges. Therefore, choosing the
appropriate target destinations for each
cluster maximizes the overall migration ROI.

Table 2: MIGRATION STRATEGY PER CLUSTER

APPLICATION CLUSTER TARGET PLATFORM MIGRATION APPROACH

Web Front-ends Public cloud (with appropriate private Host the new URLs in the cloud,
links back to on-premises DC) canary test it, and swing traffic over
Workplace Commercial-off-the-shelf Rebuild: Retire apps, migrate
(COTS) offerings for cloud-based configurations and data, redefine
collaboration and messaging security policy
Systems of Integration (“Mudballs”) Cloud-based container solutions Subsequent isolation and
containerization of microservices,
stepwise re-architecting of Mudballs.
Containerizing makes them portable
for on-premises or cloud. Move to
cloud when majority of apps have
swung over
Calculation/Grid Public cloud or container platforms Refactor code to new
(e.g. Hosted Apache Spark) to virtual infrastructure
manage distributed computing
Third-party Applications Agree migration with vendor, avoid In agreement with third-party vendor,
a lift and shift, which does not add move to cloud only when NPV
new capabilities. Ideally also port on makes sense
container environment
Systems of Record Re-platform and move to public- Potential re-platforming, data
cloud data services only when ROI migration strategies. Disaggregate
makes sense SOR needs for new born-in-cloud
applications and de-centralize away
from on-premises legacy systems
Glue Apps Cloud-based infrastructure as a Lift and shift, rebuild only where it
service (IaaS) or container services is cost effective. Use opportunity to
consolidate business logic to frontline
systems, and try to retire
System Platforms Re-architect for cloud platform; for Use forensics to discover detailed
example, move from physical to configurations, simplify, standardize,
virtual firewalls and port

Copyright © 2018 Oliver Wyman

Exhibit 2: MIGRATION OF PREPRODUCTION ENVIRONMENTS
Migrate Preproduction First

Design Test Stage Preproduction Production

Migration Progressive
Automation,
1  Automated
Testing,
Cloud Migration
2  

3     

3. DEFINE NON- You can achieve non-trivial gains with

PRODUCTION STRATEGY non-production migrations, since there
are typically many more assets in these
Each of the above clusters has a non-
environments than production. A major
production presence (also commonly
international bank had two-thirds of its data
referred to as staging or dev/test), built out
center assets tied into non-prod systems.
to varying degrees depending on the stage
that environment is in the development A critical strategy is to introduce load
lifecycle. For example, application instances balancers (or even API gateways) in front of
in early-stage environments may have each application end-point and reconfigure
dummy back-ends but are functionally the neighboring applications to point to
a replica of the production stage. These these load-balancers. Once legacy and
dev/test environments are a great place cloud instance are both connected to the
to “prove out” cloud before moving load balancer, it is easy to test and complete
production workloads. migration. Cutting over to (and back from)
the cloud instance of that application is
It is, in fact, necessary to move these non-
greatly simplified, and this greatly increases
prod environment stages to cloud prior to
flexibility in testing the migration.
the actual production instances. This ensures
you identify and iron out any issues early, Finally, run a catalog of reliable automated
safely using the standard dev/test process. tests on the legacy environment, so that
DevOps team sprints must be dedicated application business flows can be confirmed
for cloud migration; resist every urge to after the migration. Without this set of
introduce new software features during automated tests, the migration program
these sprints! becomes heavily dependent on having
QA teams run manual testing after each
migration. Manual testing can add major
costs and delays in a migration.

5
 4. PRIORITIZE CLUSTERS 5. ENABLE FORENSICS
Typically, when prioritizing which ROI from cloud migrations often assumes
cluster to start with, there are three infrastructure service-level agreements
popular approaches: (SLAs) would be equal or better than
hosting on-premises. However, owing
•• By size: This simplistic approach
attempts to gain ROI early in the to “spaghetti” application architectures,
migration initiative. However, the largest inefficient database calls or various
applications are often the hardest to other reasons, application throughput
migrate, and offer the least cost and can sometimes take a nosedive post-
agility benefit, as they are already migration! This destroys the business case.
optimized on-premises and are running It is important, therefore, to clearly enable
steady with constant load transaction-performance measures across
•• By cost: An application with high the application cluster fault lines, allowing
cost can look like an attractive first for quick diagnosis and isolation, and
target. However, the most expensive
remediation at the atomic level. Front-end
applications often have the most
customization, and those customizations interfaces typically have plenty of telemetry
don’t fundamentally change when this set up; it is the middleware layer downward
application is migrated to the cloud, where forensics must be set up. One
unless one fully re-factors or re-architects popular method of improving visibility is to
the application introduce an API gateway layer in front of the
•• By anticipated cloud benefit: Often the downstream application.
optimum target applications within this
list are those with low customizations,
high variability in capacity use, and/or 6. EVALUATE THIRD-
rapidly growing footprint PARTY APPLICATIONS
The recommended approach is to segment Several organizations rely heavily on
the migration relying on typical enterprise- third-party applications for core business
application clusters, identify quick wins functions, and slow-moving vendors or
(such as systems of engagement), and poorly shaped contracts can severely hinder
then move to more complex segments, modernization efforts. Statement of Work
such as systems of integration, high (SOW) Contracts with these vendors can
computing grids, and glue apps. Systems be crafted (or modified) to push them to
of record are typically in the last migration deliver on DevOps-style increments, and
wave, and some assets within this cluster to require modernization and visibility into
category never migrate to the cloud. Often, their software-development lifecycle (SDLC)
regulatory and privacy concerns are quoted. practices (such as continuous integration,
(The authors are of the view that public automated testing, and containerization).
clouds can be as secure as private IT). Also, Abstraction from the infrastructure and
as mentioned earlier, some clusters (such as environment automation is a critical
systems of integration) require re-factoring requirement within these contracts. If these
prior to migration for optimum returns. third-party applications are developed,
tested, and deployed on-premises using
modern SDLC principles, moving them
to the cloud is typically an inexpensive,

Copyright © 2018 Oliver Wyman

and often a welcome, proposition for the •• To execute migration, we mostly use the
vendor. If not, it’s better not to migrate the “canary” (taken from “canary in a coal
applications. Some vendors promise a lift- mine”) model (see Exhibit 3: “Canary-
and-shift to their own proprietary cloud. This Based Migration”)
provides short-term gains, but makes it even •• Gradually move traffic from on-premises
harder to evolve in the long term. to the cloud, dividing traffic between
on- and off- premises; use “canary”
where possible
EXECUTING •• Measure performance metrics carefully,
with special attention on those expensive
MIGRATION calls to SOR (systems of record)
•• Switch over the entire user base once
In this paper, we take a high-level look at the canary test passes and performance
migration. A migration will evolve over metrics are satisfactory
time, so the use of a migration-planning
tool is helpful. These tools can capture To migrate standard clusters, build a scripted
dependencies that will rebuild the integrated and automated migration factory and pre-
plan after changes have been made. The stage migration using factory stages.
tools will also accommodate for an ever finer
A governance board that links migration
granular baseline, reflecting configuration
plans back to the business, tracks KPIs, and
and dependency changes that will occur
works around any business constraints is
over the lifetime of the migration.
also advisable. Finally, set up 24x7 vendor
support during migrations to accelerate the
process and hedge risks, especially when the
window for migration is tight.

Exhibit 3: CANARY-BASED MIGRATION

Users and Customers

Traffic Splitter

VPC

Script engine/Automate
(e.g. Chef)
Public Cloud Legacy
(Not migrated)

Legacy Data Base (Migrate later)

7
 SUMMARY: SMART automation, staff training, and evolution of
their operating model.
MIGRATION STRATEGY
Start with easy, low-dependency clusters:
Here’s a quick review of the process Web and Dev/Test. Transform complex
described in this paper. apps by using microservices, then migrate
them. Move to SaaS as much as possible; IT
Break applications into clusters along no longer has to run everything. Modularize
natural fault lines. Chose a tailored “Mudballs,” meshing microservices. And
migration approach per cluster. Only say no to lift-and shift-migrations that rarely
migrate where there is business value; add value.
third-party applications and systems of
record sometimes do not offer business It is essential to keep the cloud migration
value for cloud migration. A cloud migration in line with business goals, and focus on
never stands alone; it usually interlinks with generating top-line impact along expected
many other aspects of the enterprise-IT cost reductions. Top-line impact results
architecture. Enterprises should use the from greater development speed and easier
momentum of a cloud migration to further IT addition of new features.

Exhibit 4: BENEFIT AND EASE OF MIGRATION BY CLUSTER

Impact
Systems of Integration Start migration process
(”Mudballs”) with less complex applications to
accelerate transformation

25%

5%
10% Workplace
28% Calculation/Grid
Systems Platforms 10%

Systems of Record
5%
10%
Third-party
Applications
Web Front-ends
Keep Legacy –
No Cloud Migration 5%

Glue apps

Ease of Migration

Copyright © 2018 Oliver Wyman

OMER ANSARI | omer.ansari@t-mobile.com UWE LAMBRETTE | uwe.lambrette@oliverwyman.com
Omer Ansari is a Director at T-Mobile, where he is responsible for Uwe Lambrette is a Partner in Oliver Wyman’s Digital Acceleration and
the digital transformation of all T-Mobile’s U.S revenue-generating Transformation, as well as the CMT Practice. Before Oliver Wyman,
applications – from legacy-monolith patterns towards cloud-based, he built his experience for the high-tech industry. After his PhD in
distributed micro-services. This utilizes Continuous Delivery, automated communications design, he worked in a major consulting firm, focusing
testing, service virtualization, data forensics, and advanced data- on technology and operating model transformation. He spent 10 years
management techniques. Prior to T-Mobile, Omer held multiple roles at at Cisco in strategic business development for cloud, and delivering and
Cisco related to building, designing, and operating cloud services. implementing cloud- and network-software solutions.
Oliver Wyman is a global leader in management consulting that combines deep industry knowledge with specialised
expertise in strategy, operations, risk management, and organisation transformation.

For more information please contact the marketing department by email at info-FS@oliverwyman.com or by phone
at one of the following locations:

EMEA AMERICAS ASIA PACIFIC

+44 20 7333 8333 +1 212 541 8100 +65 6510 9700

www.oliverwyman.com

Copyright © 2018 Oliver Wyman

All rights reserved. This report may not be reproduced or redistributed, in whole or in part, without the written permission
of Oliver Wyman and Oliver Wyman accepts no liability whatsoever for the actions of third parties in this respect.
The information and opinions in this report were prepared by Oliver Wyman. This report is not investment advice and
should not be relied on for such advice or as a substitute for consultation with professional accountants, tax, legal or
financial advisors. Oliver Wyman has made every effort to use reliable, up-to-date and comprehensive information and
analysis, but all information is provided without warranty of any kind, express or implied. Oliver Wyman disclaims any
responsibility to update the information or conclusions in this report. Oliver Wyman accepts no liability for any loss arising
from any action taken or refrained from as a result of information contained in this report or any reports or sources of
information referred to herein, or for any consequential, special or similar damages even if advised of the possibility of such
damages. The report is not an offer to buy or sell securities or a solicitation of an offer to buy or sell securities.
This report may not be sold without the written consent of Oliver Wyman.