These materials are © 2020 John Wiley & Sons, Inc.

Any dissemination, distribution, or unauthorized use is strictly prohibited.

 Cloud
Migration
Virtana Special Edition

by Brett McLaughlin

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Cloud Migration For Dummies®, Virtana Special Edition

Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2020 by John Wiley & Sons, Inc., Hoboken, New Jersey

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without
the prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com,
Making Everything Easier, and related trade dress are trademarks or registered trademarks of
John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be
used without written permission. All other trademarks are the property of their respective owners.
John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO

REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF
THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING
WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY
MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE
AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS
WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN
RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL
ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE
SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING
HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK
AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN
THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION
OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS
SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR
DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

For general information on our other products and services, or how to create a custom For
Dummies book for your business or organization, please contact our Business Development
Department in the U.S. at 877-409-4177, contact [email protected], or visit www.wiley.com/go/
custompub. For information about licensing the For Dummies brand for products or services,
contact BrandedRights&[email protected].
ISBN 978-1-119-73411-6 (pbk); ISBN 978-1-119-73413-0 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

Publisher’s Acknowledgments

Some of the people who helped bring this book to market include the following:
Project Editor: Elizabeth Kuball Production Editor: Siddique Shaik
Executive Editor: Steve Hayes Special Help: Andy Kicklighter,
Editorial Manager: Rev Mengle Bob Farzami and Ricardo Negrete

Business Development
Representative: Karen Hattan

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Introduction
T
“ o the cloud!” That was the tagline of a famous commercial
a few years back, and while the sentiment was perhaps
overly simple, the intent was right on the money. Everyone
is moving to the cloud these days, and for good reason.

The era of giant servers running in frigid rooms, raised floor-

ing for miles of network cabling, “spinning disks” overheating
and needing to be replaced, server blades and memory sticks,
well, that era is coming to an end for almost every company in
the world. That era was costly, was resource- and maintenance-
intensive, and required a massive personnel commitment to be
sustained.

The new era — that of the cloud — is still complex and requires
tremendous expertise. But unparalleled increases in bandwidth,
disk capacity, computational power, and architectural flexibility
are all available, often at fractions of the pricing found in the on-
premises era. Applications have greater demands on a wider array
of services than ever before, and the cloud can be the best way to
make these applications sustainable, cost-effective, and flexible.

But the reality is that “to the cloud” really is just a tagline, a clever
marketing phrase. Actually moving to the cloud is as complex as
the cloud itself, and it often requires radical upheaval before suc-
cess. It’s a tricky process, requiring the right people, clear goals,
and, in almost every case, an experienced and savvy partner. But
by bringing to bear the right resources with the right expecta-
tions, you can reduce the complexity of a migration and get to the
significant benefits of the cloud much more quickly.

In Cloud Migration For Dummies, I outline the different options you

have to migrate your own infrastructure and applications to the
cloud, including best practices, tips that come from the experi-
ence of multiple actual migrations, and how to ensure success
after you’re on the cloud.

Introduction 1

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 About This Book
This is a book about migrating to the cloud. It’s direct, clear, and
instructional. It stands on its own, and while you’ll certainly need
many more resources to complete a successful cloud migration,
this book can easily serve as your high-level guide, stuck in a back
pocket or pulled up with a few touches on your tablet.

Because this book is meant to be small and direct, it doesn’t mince

words, and topics that might span eight pages may only show
up as a bulleted list in this book. However, the upside is you can
easily read it over a lunch break, and then refer back to it as much
as you need.

You should consider this book as a jumping-off point. Each chap-

ter, and even each section, should cause you to generate questions
and notes that will lead you into potentially deeper exploration
of the topic at hand. Follow those questions and interests, and
then come back to the next chapter, the next section. By the time
you’re finished, you’ll have a clear picture of a good cloud migra-
tion and how to architect and manage your own.

Foolish Assumptions
You may have heard what assuming does to you and me, but
despite the old warning, I still make a few assumptions in this
book:

»» I assume that you want to perform a cloud migration (or

maybe more than one), and you’re trying to figure out
how best to make that successful. I do not spend any
substantial time laying out the advantages of the cloud, or
how to decide if you may want to migrate. That would take
more space than I have in a book of this length.
»» I assume you have a basic understanding of the cloud. If
you’re an IT executive, a chief technology officer (CTO), or a
chief information officer (CIO), this book will give you a
simple organized framework for preparing a cloud
migration.

2 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 This book isn’t just for executives, though. IT managers,
engineering vice presidents, and technologists will find a
clear blueprint and keys to successfully moving your
applications and technologies into the cloud. This book
doesn’t have a ton of code, but it’s very much a technically
driven book. You’ll find security and sizing considerations are
addressed, as well as recommendations for taking advan-
tage of what the cloud has to offer.

If any of these assumptions and assertions describe and appeal

to you, then this is your book. If none of them do, keep reading
anyway — you’ll learn a ton about the cloud and you may find
yourself intrigued and wanting to learn more.

How This Book is Organized

Cloud Migration For Dummies consists of seven chapters that
explore the following:

»» The basics of a cloud computing environment, and common

terms you’ll want to get familiar with (Chapter 1)
»» Preparing for a cloud migration, from the roles and people
involved to the meetings you’ll need (Chapter 2)
»» Understanding your options for cloud migration and making
a good decision about which option to choose (Chapter 3)
»» How to test out your migration before you go live (Chapter 4)
»» Flipping the switch on your migration (Chapter 5)
»» Building out systems to ensure your system stays running in
the cloud (Chapter 6)
»» Ten ways to guarantee a successful cloud migration
(Chapter 7)

Each chapter is written to stand more or less on its own, so if

you see a topic that interests you, feel free to jump ahead to that
chapter. If topics are mentioned in one chapter but covered in
more detail in another chapter, I let you know.

Introduction 3

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 That said, each chapter does create a progressively detailed pic-
ture of a successful cloud migration, from the first to the last. If
you’re new to this topic, or you’re about to take on a cloud migra-
tion in your company, you’ll get the most value from reading this
book front to back. That’s why I’ve kept it short and direct!

Icons Used in This Book

Throughout the book, I occasionally use special icons to call
attention to important information. Here’s what to expect:

This icon points out important information you should commit

to your nonvolatile memory, your gray matter, or your noggin —
along with anniversaries and birthdays!

Tips are appreciated, never expected, and I sure hope you’ll

appreciate those useful nuggets of information.

These alerts point out the stuff your mother warned you about.
Well, probably not, but they do offer practical advice to help you
avoid potentially costly or frustrating mistakes.

Where to Go From Here

There’s only so much I can cover in 48 short pages, so if
you find yourself at the end of this book, thinking, “Gosh,
this was an amazing book! Where can I learn more?,” check out
www.virtana.com/products/cloud-migration-readiness.

4 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Speaking the language of the cloud

»» Avoiding false mappings between

on-premises and cloud environments

»» Evolving your technology’s responsibility

model

Chapter 1
Cloud Computing
Environments 101

I
n this chapter, I explain the ins and outs of cloud terminology.
That will prepare you to get into how to compare your on-
premises environments with cloud-based ones. I also explain
how responsibility in the cloud is very different from what you’re
probably used to.

Learning Cloud Terminology

There’s definitely a lingo when it comes to the cloud. You don’t
need to know every term — and Google is always your friend —
but there are some key terms you should know. That’s what I cover
in this section.

Everything begins with a cloud provider

Choosing a cloud provider — like Amazon Web Services (AWS),
Google Cloud Platform (GCP), or Microsoft Azure — is likely the
first decision you’ll make. The provider gives you the resources
you’ll use for your own cloud environment.

CHAPTER 1 Cloud Computing Environments 101 5

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Cloud providers have a few key capabilities:

»» Virtualization: Virtualization takes actual resources and

provides a different view of those resources to you. Most of
the resources in the cloud are virtual; they don’t directly map
to real pieces of hardware.
»» Managed service: A managed service is a capability that the
cloud provider manages (so you don’t have to).
»» Environment: Cloud providers let you create multiple
environments, either within a single account or across
accounts. Environments are completely independent and
can represent different pieces of applications, or separate
development from testing from production.

As-a abbreviations
The cloud, like most technologies, is full of abbreviated terms.
Here are three that relate to how you plan on using the cloud:

»» Infrastructure as a service (IaaS): This is the most basic

way to use the cloud. You’re taking the file storage and
network connections and computational units of the cloud
provider and building them up into your system.
»» Platform as a service (PaaS): In PaaS, you’re using not
just the raw resources of a cloud provider, but the more
advanced features and services that the provider offers.
So, you may use a managed database service or a serverless
code runner.

THE VALUE OF A MANAGED

SERVICE
Managed services are one of the biggest advantages of the cloud.
A managed service takes something that usually is your responsibility
to staff and deal with — like a database — and takes a large amount
of that responsibility off your shoulders. In general, the more you
can use managed services, the more value you’ll gain from a cloud
migration.

6 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 »» Software as a service (SaaS): Here, software from a vendor
gives you functionality and takes care of cloud hosting for
you. So, you may use an e-commerce SaaS, for example.

Understanding What’s Different

about the Cloud
Even more than terminology, the biggest favor you can do your-
self is to move away from thinking the cloud is just a virtual closet
in the sky.

Yes, you can migrate your current servers and networks and data-
bases directly into the cloud. There’s even a name for that: It’s
called lift and shift, and it’s discussed in Chapter 3. But if you really
want to maximize value in your cloud migration, you’ll consider
going well beyond just moving your existing resources and appli-
cations as is.

The cloud values independent

application components
One big advantage of the cloud is its ability to scale in and
scale out. Almost anything you put in the cloud is capable of scal-
ing out to meet demand and scaling in to reduce cost. But that sort
of scaling requires anything you put in the cloud to be indepen-
dent of other components. If you have a web server that assumes
it’s got the only database connection, that web server can’t scale
out, because then you’ll have two web servers, both acting as if
they’re the only one. The same is true of your application pro-
gramming interfaces (APIs), databases, and integrations.

The more independent your components, the better they’ll scale

in and out, and the more optimized your environment will be.

The cloud is widely distributed

You probably already realize that the cloud isn’t just one set of
servers in one place. You won’t have to worry about that too
much, but you still need to think about the general location of
your environments and resources.

CHAPTER 1 Cloud Computing Environments 101 7

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 SCALING IN THE CLOUD IS
HORIZONTAL
You’re probably used to thinking about an application scaling up to
meet demand and then back down when demand decreases. Think of
this as the equivalent to moving your application to a bigger server in
your data center with more CPU, memory, and networking when you
need it. In the cloud, although this is still possible to some extent (for
instance, by adding more resources to a cloud-based virtual machine),
the best outcomes result when your application is architected to scale
out or in. Think of a horizontal row of virtual servers. If more servers
are needed, the row grows wider — that’s called scaling out. If fewer
servers are needed, the row gets narrower — that’s called scaling in.
The classic model for this is the three tier web application — using
web servers, application servers, and databases. Load grows fastest
on the web server tier, and more can be added or removed when
needed. In contrast, the application server tier may occasionally need
to add or remove a server and the data tier is static.

Cloud providers typically support the following:

»» Regions: A region is a large geographical area, often with

multiple zones. So, you may have the eastern region of the
United States or the southern region of Japan.
»» Zones: A zone is a smaller area of service. Most zones also
have redundancy, often two or three actual data centers that
support your virtualized cloud environments.

You use multiple regions to support better fault tolerance and dis-
aster recovery. You can also use different regions to serve cus-
tomers closer to their actual location. A customer in Japan will see
much better performance from an application hosted in that area
than one hosted in a region of the United States will.

The cloud is flexible

You can have a near-infinite number of configurations in the
cloud. You can store your data on your local network but put web
servers in the cloud. You can host all your infrastructure in the
cloud. You can ditch your infrastructure altogether and write code

8 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 that never requires a virtual server. And you can combine all these
into a never-before-seen configuration perfect for your needs.

Sharing Responsibility for Operation

One final significant change when migrating to the cloud is the
sharing of control. You no longer wholly own your servers, your
network, or your database. But you also no longer wholly own the
upkeep, patching, and versioning of those resources. You jointly
own both of these with your cloud provider.

This is called a shared responsibility model. You have responsibility

for your data, your application security, and how you use the cloud
resources you employ. But your cloud provider has responsibility
for the security of those resources and keeping them running at
a basic level. For more on cloud security and the shared respon-
sibility model, check out the Cloud Security Alliance (https://
cloudsecurityalliance.org).

CHAPTER 1 Cloud Computing Environments 101 9

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Setting clear and obtainable goals

»» Measuring your before so you can judge

your after

»» Building the right teams with the right

people

»» Saving time by working with experienced

partners

Chapter 2
Preparing for a Cloud
Migration

T
here’s no substitute for a good plan — every smooth cloud
migration began with a great plan. You need to have clear
goals, well-staffed and communicating teams, and in most
cases, help from a partner that has done multiple cloud migra-
tions. Add those factors up, and you’ll have a much stronger and
more efficient cloud migration.

Setting Clear Goals and Expectations

for Return on Investment
Return on investment (ROI) is a business term that’s thrown around
a lot. With a cloud migration, tying the ROI to the overall digi-
tal transformation strategy is essential. You’re migrating to get
something. Whether you want to reduce costs, take advantage of
new capabilities, enable scaling on demand, or take advantage of
cloud infrastructure to more quickly respond to changes in busi-
ness environment, you’re looking for a return on your migration
investment. That return begins with understanding your “now.”

CHAPTER 2 Preparing for a Cloud Migration 11

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 A helpful way to quantify expectations is to examine the following:

»» What you want to reduce

»» What you want to increase
»» What’s not working

What do you want to reduce?

Begin with things you want to reduce. These are usually pretty
easy and often fall into one of these categories:

»» Cost: Everybody wants to pay less, and the cloud is excep-

tional (when a migration is done well) at reducing overall
spend.
»» Wasted resources: Over-provisioning is when you have
more compute power, disk space, bandwidth, or anything
else that is sitting idle. A migration can help right-size your
resources.
»» Time spent not getting important things done: “Get
important things done” sounds vague, but it’s still true. The
more time your staff is configuring networks or trouble-
shooting servers, the less time is available to move the
business forward with innovative applications.

PEOPLE ARE RESOURCES

It’s easy to think about a server sitting idle as a wasted resource. But
you also can have staff that are wasted as well. Sometimes you have a
specialist — perhaps a database administrator — who is paid full-time
to work on tasks that take 20 hours a week. Those are wasted hours
and, therefore, wasted resources.

If you can significantly reduce redundant tasks like upkeep and main-
tenance, you can remove those wasted resources. Repurpose them to
higher-value tasks or replace them with business-specific needs.

12 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 What do you want to increase?
In addition to reduced costs and waste, you should see increases
in important activities. Even if those improvements are just the
result of reductions, make a note of them as goals for your project,
and record them.

Common goals for improvement include the following:

»» Flexibility: A cloud environment is inherently more flexible

than an on-premises one. You can turn off five database
servers and turn on four file stores in minutes, with no
capital cost and minimal configuration.
»» Customer engagement: With the time and money available
for a reduction in overhead and maintenance, you can build
more dynamic customer experiences. You can also take
advantage of greater performance, resulting in customer
satisfaction.
»» Business analytics: The cloud offers access to advanced
analytics tools, as well as machine learning often inaccessible
to even medium-size businesses at a fraction of the cost.
»» Online offerings: If you have a significant physical presence,
a cloud migration can enable you to move many of your
products to a digital delivery model and increase their
visibility and sales.

What’s not working?

With a clear understanding of what you want more of and what
you want less of, turn your attention to what could be improved
through a cloud migration.

This is harder to quantify because each business is unique, but a

common improvement is the ratio between your capital expendi-
tures (CapEx) and your operational expenditures (OpEx). CapEx
will be high for on-premises installations. You pay a lot upfront
for equipment, and you pay a lot in recurring chunks to replace
that equipment. OpEx is what you “pay as you go.” Many busi-
nesses prefer to reduce CapEx in favor of OpEx. A cloud migration
is a great way to make that adjustment — to make your CapEx
work better for you.

CHAPTER 2 Preparing for a Cloud Migration 13

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Another common improvement from cloud migration is a techni-
cal staff that is engaged and modern in development and opera-
tions practice. Many engineering and IT organizations that are
inefficient can be moved out of the “not working” category
through a migration to the cloud and realignment around cloud
best practices.

Establishing a Clear Baseline

Your baseline is where you begin. It should include a number of
components: an objective set of metrics, a subjective state of your
applications and environment, and a gut-level feel from your key
stakeholders.

You’ll never know if your migration is successful if you don’t

understand where you’ve come from. The best way you can
understand what your current environment really looks like is to
gather data on:

»» OpEx: What is your monthly operating cost for equipment?

This should include everything from servers and bandwidth to
air conditioning to keep your server closet or warehouse cool.
»» CapEx: How much are you paying, and how often, for
hardware, network gear, racks, and so on? Capture all your
one-time costs and their recurrence.
»» Usage and capacity: For every resource you have, what
capacity do you have? And of that capacity, how much is
used? If you pay for 200 terabytes (TB) of hard drive space
and use 150TB, record that. If you typically see your servers’
CPU usage at 60 percent, note that, too.
»» Operational headcount and cost: How many personnel do
you have dedicated to operations? How much do those
people cost your organization? Use fractions if you need
to — you may have an engineer who’s focused on server
upkeep for half of her time, so note that as 50 percent.
»» Operational hours: On top of the personnel considerations,
how much time is spent in total on operations? Be sure you
include work on capital budgets, purchasing contracts, and
then, of course, IT and operations hours.

14 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Getting the Right People Involved
A cloud migration is often seen as a technical challenge. How-
ever, most successful cloud migrations succeed or fail based on
the people involved more than any other factor.

Finding the right people currently on

your team
Even a relatively small cloud migration takes a lot of people. You
need to ensure you have the right people from your existing orga-
nization from the first meeting all the way through to the last.

You should be pulling in

»» Stakeholders: A cloud migration is technical but rarely just

technical. You need the key decision makers available and
ready to contribute opinions, budgets, requirements, goals,
and information.
»» Engineers: Cloud migration requires your application
engineers to be clear about their application requirements,
components they’ll need from the cloud, and how their
applications interact with services like databases and file stores.
»» IT: IT and operations are often separate from engineers,
especially if engineering in your organization is analogous to
development. In short, whoever runs your hardware and
systems has to be a key ingredient in any cloud migration.
»» Managers: You absolutely, without doubt, will have conflicts
in a migration. Migrations are complex, and someone will
have to move things forward when agreement can’t be
reached. Managers — and ideally, a clear hierarchy for critical
decisions — are essential to ensure smooth migration.
»» Finance: Even if cost savings is not a key goal, budgets are
complicated when you migrate to the cloud. You’ll need
someone who can manage budgets and ensure you’re on
target throughout the project.
»» Project managers: All these people require a lot of coordi-
nation. You’re going to need a strong project manager
(or two or three) to keep the wheels turning in different
departments and across departments. A project manager
can ensure you stay on task and on time.

CHAPTER 2 Preparing for a Cloud Migration 15

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Honestly, this list isn’t exhaustive. You may also need people in
legal, procurement, contracts, and more. But if you start here,
you’ll uncover what else you need through these key people.

Finding the right new people

As detailed in Chapter 1, migrating to the cloud is not creating a
new one-to-one mapping of your current technology stack and
environment. You’ll need new skill sets, and they all can’t simply
be trained. You’ll likely need some new personnel.

Here are common additions to teams that facilitate successful

cloud migrations:

»» DevOps: DevOps represents a modern collaboration

between what are traditionally two organizations: develop-
ment and operations. You need engineers with this principle
instilled in them to be successful, and you likely don’t have
many (or any) of these if you’re mostly or all on-premises
today.
»» Cloud specialists: You should find engineers and operations
folks who are experts in cloud computing. You may also
want to look for people with experience in the specific cloud
provider you’re using.

You may not need one of each of these roles, and you may find you
need more than one of some.

Training everyone
Now, take every person on your team — from the top on down —
and insist they learn cloud concepts. Whether it’s online training,
an in-person course, a YouTube video, a learning platform, or a
training session led by an educator you bring in, you have to get
your teams on a level playing field with cloud terms. Have them
all read this book and maybe a curated set of white papers.

The larger the gap in cloud concepts and understanding from one
team member to the other, the more arguments and disagree-
ments will arise that aren’t substantive but actually reflect learn-
ing gaps.

16 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Coordinating (and coordinating
some more)
If this chapter were limited to a single page, that page would be
entirely about coordination. The biggest challenge is getting a
team with all these disparate parts to work together. It’s hard,
it’s time consuming, and it’s at least as difficult as the various
technical challenges involved.

Set up daily meetings with your core members (if you’re using
Agile methodologies, this would be a daily standup). Set up weekly
meetings with the broader team. Insist on a single leader to run the
daily meeting and a single leader to run the weekly meeting. Send
out clear agendas and action items, and timebox your meetings.

You should already have clear goals. Every meeting must support
those goals, and if you don’t make it clear how the meeting results
in furthering those goals, you won’t have effective meetings.

Choosing an Experienced Partner

If you’ve never ridden a horse, simply finding one and saddling up
may not be the best approach to learning to ride.

Cloud migrations are complicated, multifaceted, and time con-

suming. Like riding a horse, they’re best done by experienced,
savvy specialists. Just as important as finding and connecting the
right people on your internal teams is finding the right people to
partner with for success.

A company that specializes in cloud migration and has done

many of them is a good partner. A company that has done a lot of
different types of cloud migrations and views your business as
unique is a great partner.

Here are some other traits of a great partner:

»» A great partner has clear readiness guidelines. When you

evaluate potential cloud partners, begin by asking what
offerings they have to evaluate and assess readiness.
Anything short of a well-documented, clear process is
unacceptable and tells you that you haven’t found the right
partner yet.

CHAPTER 2 Preparing for a Cloud Migration 17

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 A great partner provides measurement of your “now” (as
discussed earlier); walks you through your specific goals in
terms of cost, flexibility, customer engagement, and industry
standards; and explains your options without bias.
»» A great partner has tools and products specific to
migration. You wouldn’t hire a plumber without a wrench,
so don’t bring on a partner without similar tools. You should
expect products from your partner that optimize and
capture your existing workloads and help you simulate your
migration before cutting over to the cloud.
You should also expect monitoring tools that provide clear
value, both before and after your migration. Cloud providers
offer their own monitoring tools, but ask any potential
partners what enhancements they offer and how those tools
may integrate into your existing operational processes.
»» A great partner engenders trust. You should trust your
partner and, in the best partnerships, even like them! If
you’re constantly handed off to salespeople who seem more
engaged by your total contract value or engineers who can’t
speak to your business goals, be scared!
Great partners provide multiple levels of engagement —
interacting with your business goals, your executive team,
and then your project managers and engineers. If you don’t
feel your partner is providing value, find one that does! You
should leave each interaction with a strong sense of trust
and a greater understanding of your migration.

PARTNERS MATTER
When NASA’s Earthdata mission decided to take their massive data
store and move it online, they brought in multiple consulting partners.
When a $15 billion hedge fund in Washington, D.C., needed to consol-
idate multiple cloud providers, they brought in an experienced con-
sulting partner. And when a technically savvy NBA team needed to
move their business to the cloud, they did the same.

Each of these well-positioned, already-technical organizations recog-

nized that the shortest and most efficient path to success when migrat-
ing to the cloud required expertise that they didn’t have. By partnering
their internal staff with specialized partners, they all built cost-saving,
industry-leading cloud environments while minimizing mistakes.

18 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Differentiating between common
migration strategies

»» Making a decision based on your

organization’s specific needs

»» Building a multi-phase approach to

reduce risk and migration time

»» Expecting and responding to the

unexpected

Chapter 3
Determining Your
Migration Strategy

S
aying that you’re migrating to the cloud is a bit like saying
you’re eating dinner. It gives a general idea of what’s hap-
pening, but it leaves a lot of room for filling in the details.
Are you moving everything? Are you keeping your applications as
they are or refactoring? Are you using the cloud as infrastructure
as a service (IaaS) or platform as a service (PaaS)? One cloud? Two
clouds? Hybrid?

Every detail matters, and very few of those details are arbitrary
are inconsequential. In this chapter, learn the common migration
approaches and decide which is best for you. (Hint: It may be more
than one!)

Identifying Your Options

The cloud is not a one-size-fits-all offering. Each cloud
provider gives you not just a vendor-specific set of offerings —
like Google BigQuery, Amazon Web Services (AWS) Lambda, or
Microsoft Azure Container Registry — but variety within your

CHAPTER 3 Determining Your Migration Strategy 19

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 own architectures. You need to make a decision about your high-
level migration approach early, because almost all planning will
follow from that key decision.

Here are the key options:

»» Lift-and-shift
»» Cloud-optimized
»» Cloud-native
»» Replace with software as a service (SaaS)

Lift-and-shift: simple and quick

Lift-and-shift refers to literally taking all your architecture as it
stands and moving it to the cloud in as close to a one-to-one
fashion as possible. Thus, you lift your architecture and shift it
into your cloud provider. This is a case of using the cloud as IaaS,
and basically keeping all your processes, server profiles, data
stores, and file stores intact.

The biggest advantage of lift-and-shift is that it’s relatively quick

and relatively simple. You’re only focused on a clean mapping
from your environment into your cloud provider’s environment.

In Chapter 2, I explain that the cloud is not intended to be a virtual

closet, but lift-and-shift tries to be just that. Be cautious about
thinking of lift-and-shift as a panacea. You may see quicker cost
benefits and capital expenditures (CapEx) reductions, but longer-
term gains can be elusive.

To take the greatest advantage of the cloud, consider more sweep-

ing initiatives in a later phase to move your environments — and
your staff — more firmly into a cloud-centric way of thinking.

Cloud-optimized: The same,

but a little different
A cloud-optimized approach is an incremental step further toward
a real cloud-centric paradigm than lift-and-shift. It keeps your
application architecture intact, but it seeks to use cloud-based
managed services as drop-in replacements for your existing
functionality whenever possible.

20 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 For instance, instead of using a database hosted on a server, you
could replace your PostgreSQL or Oracle instances with managed
instances that your cloud provider provides. Instead of large file
volumes, you could look at file storage like S3 in AWS, Cloud Stor-
age in Google Cloud Platform (GCP), or Microsoft Azure. You’re
keeping your application architecture intact but taking advan-
tage of key services to reduce your management and operational
overhead.

Another option is to extend your critical applications to use cloud

infrastructure, while keeping some components in your data cen-
ter. This is called hybrid cloud. For example, if transaction time is
critical for a back-end data tier in a medical or financial appli-
cation, maintaining application performance is often better done
with local, high-performance storage assets, while other appli-
cation and web components can be moved to the cloud to take
advantage of advanced scaling capabilities when needed.

For most basic services, you can simply search the web for your
preferred cloud provider and the service, and you’ll get results
that suggest cloud-optimized alternatives. For instance, search-
ing for “AWS file storage” returns articles on the Elastic File Sys-
tem and S3, while searching for “Azure database MySQL” gives
you information on Azure’s managed MySQL instances.

Cloud-native: Not at all the same,

but turbo-charged
Cloud-native is a complete commitment to the cloud and, often,
to a specific cloud provider. In this model, you’re taking the func-
tionality of your application — a user interface accessible on the
web, a data store, an application programming interface (API) —
and looking to refactor and even rewrite your application based on
cloud-specific functionality. So, you may use a serverless technol-
ogy to serve your front end, worker threads to return responses
for an API, and a columnar data store for some data and dynamic
file storage for other data.

In other words, you’re evolving your application from a server-

based paradigm to a cloud-based one. This is by far the most
difficult and complex migration, but it also can offer the most
extreme gains in performance, as well as massive reductions in
cost and maintenance.

CHAPTER 3 Determining Your Migration Strategy 21

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 This approach depends heavily on your people and your coor-
dination (see Chapter 2). Without a great team of cloud-savvy
engineers, cohesive management, and an experienced partner,
cloud-native migrations rarely succeed.

Replace with SaaS: Buy over build

In some cases, you really don’t need a lot of custom applications.
Perhaps off-the-shelf solutions would provide you the function-
ality you need while still offering your business the customization
that’s required to differentiate your business. You want to concen-
trate your people on your key value adds and distinguishing char-
acteristics. SaaS applications can often take non-key services off
your plate, resulting in fewer distractions to your core business.

In this case, you may choose to migrate to that software, instead of

actually moving your own applications. This can be a fantastic solu-
tion if you don’t need as much flexibility but really want to move
quickly and with assurance of a tested platform as the outcome.

Choosing the Right Strategy

At its simplest, you can evaluate the basic pros and cons of each
approach, compare those to your goals for the migration, and
make a decision. Table 3-1 lists the major items to consider.

TABLE 3-1 Effects of Various Migration Strategies

Lift and Cloud-
Shift Optimized Cloud-Native SaaS

Degree of change to Very low Low Very high N/A

architecture

Complexity Low Medium Very high Medium

Operational High Medium Medium Low

overhead

Reduction in cost Low Medium Potentially Varies

very high

Increase in Medium High Very high High

productivity

22 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Realistically, this decision is never easy, and each option is a
trade-off. Cloud-native has huge potential for cost reduction,
improving productivity, and attracting and energizing top engi-
neering talent, but it brings with it significant complexity and
will likely require a lot of new training and new hires. Addition-
ally, even if phased, this option can be quite risky and expensive
compared to less volatile strategies.

On the other hand, while lift-and-shift is very straightforward,

you’ll realize only a fraction of the benefits of a cloud-optimized
migration, let alone a cloud-native one.

SaaS is in many ways the most variable. Different partners with

different solutions offer wildly different price points, advantages,
and tradeoffs. If you examine SaaS as an option, you’ll need a
completely different decision matrix for evaluating between dif-
ferent offerings.

It’s very easy to become enamored with one approach or another.

Perhaps you really love the idea of the simplicity of a lift-and-
shift, or you think you could attract top-notch engineering talent
with a cloud-native approach.

The key is to evaluate these strategies against your original goals

(see Chapter 2). If your prime consideration is cost, it doesn’t
matter how intriguing and expensive SaaS may be; you may need
to ignore SaaS because of the primary cost factor. If you’re in need
of a next-generation application, but cloud-native looks intimi-
dating, consider a partner or phased approach instead of aban-
doning your key goal.

Ultimately, you should change your strategy to accommodate

your goals, not the other way around. Sometimes there is a middle
ground (of sorts). Read on!

Migrating in Multiple Phases

Sometimes the best strategy to choose is actually more than one
strategy. A phased migration allows you to move through more
than one strategy in an incremental approach.

Consider lift-and-shift. This is the least complex strategy with

the least architectural upheaval. That typically translates into

CHAPTER 3 Determining Your Migration Strategy 23

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 the easiest (in relative terms) migration. The big benefit here is
that you’re “in the cloud,” albeit without a lot of optimization or
maximized benefit.

But if maximizing cost or attracting better engineering talent is

your ultimate goal, then lift-and-shift should just be your first
migration. You may want to consider moving from lift-and-shift
to cloud-optimized. You’ll increase your cost savings, and while
you still have to do some re-architecting, you’ve already overcome
the initial migration to the cloud.

Put another way, you can actually break your cloud migration into
successive smaller cloud migrations. Each migration takes the
simplest step from your current state to your next desired state.

If you follow this approach, the primary extra spent resource will
be time (and that often incurs cost). You’ll never be able to per-
form two phased migrations in the time it takes to perform one
larger migration; however, that isn’t the same as saying bigger is
better. Taking longer may ultimately save you a lot of headaches
or multiple failed attempts at migrating.

As with most things in the cloud, you and your team will have to
exercise judgment and make the best decision based on your orga-
nization’s business goals.

A phased approach is often a great idea, but it’s not a one-

size-fits-all solution. You won’t always find intermediate steps
between your current state and where you want to get. SaaS is a
great example; there’s rarely an advantage in doing a lift-and-
shift before going to SaaS.

Regardless of your approach, a phased migration is still a complete

migration. That means you need to establish goals, set up kick-
off meetings, assemble the team, have signoffs and contracts, do
cost assessments, and have business reviews. You may abbreviate
some of these meetings at the end of one phase and the start of
another, but don’t skip steps. The phase will suffer, which means
the overall migration will suffer, too.

24 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Planning for Surprises
Every cloud migration comes with its share of the unknown. No
matter how well planned, and regardless of whether you choose
lift-and-shift, cloud-optimized, SaaS, or something altogether
different, you’re moving a significant, valued part of your infra-
structure to a new environment that you don’t control. That’s a
recipe for uncertainty.

With that uncertainty comes tremendous value. But how do you

plan for uncertainty? You can’t ignore it. You can’t accurately
estimate it. So, what do you do? Here are my tips:

»» Favor conservative estimates. There are plenty of times to

be aggressive, challenge your teams, and set hard deadlines.
A cloud migration is a terrible case for this approach. You
don’t have to sandbag, but try to find realistic, if not slightly
conservative, estimates. Also, be sure to plan time for
meetings and handoffs!
»» Lean on partners. Experience is the best insurance against
the unknown. A partner here can be invaluable in identifying
potential problem areas. This is also where finding a partner
that has done a migration as close as possible to yours is
critical.
»» Simulate your migration without time constraints.
One of the best things you can do is to actually do a sample
migration. Ideally, this would be a prototype team that is
working prior to your major migration initiatives. A team
like this — with the right tools — can uncover a lot of the
unknowns that would otherwise plan your carefully sched-
uled actual migration. Chapter 4 digs into this topic in much
more detail.

CHAPTER 3 Determining Your Migration Strategy 25

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Planning the steps and sequence of a
migration

»» Using tools to project results without risk

»» Responding to failure through iteration

»» Setting realistic expectations

Chapter 4
Migrating Before You
Actually Migrate

N
o matter how much you’ve learned about cloud, assembled
the right time, conducted the right (and effective) meet-
ings, and carefully laid out a migration strategy, migration
is still very hard. There is almost no chance that things will go
well on your first attempt.

Sounds ominous, doesn’t it?

It’s okay, though. If you know this going in, you can plan for
problems and take the extra care that’s required to ensure that
the problems you’re bound to encounter improve your ultimate
migration, rather than derail it.

In this chapter, I explain just how much you can do before your
actual migration to ensure success. Through tools, expectation
setting, and (even more) planning, you can reduce your migration
time and increase your end value.

CHAPTER 4 Migrating Before You Actually Migrate 27

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Modeling Your Migration Beforehand
The absolute best thing you can do before migrating your envi-
ronments, applications, and workloads to the cloud is to model
your migration beforehand. Modeling here means more than just
“test.” It involves

»» Creating a representative workload of your desired migra-

tion off-cloud to understand your actual resource needs
»» Validating that your representative workload will work in
your target cloud environment
»» Testing your representative workload in your target cloud to
validate expected performance and cost
»» Tuning and tweaking your representative workload

Application discovery and

dependency mapping
For any migration plan, you’ll also need to understand the bound-
aries and landscape of services that support your applications.
These applications’ interdependencies help determine how much
traffic you’ll have coming out of your cloud environment, which
translates into cost. You’ll also learn which applications may best
be served by staying on-premises, the design of your representa-
tive workloads, and how to schedule your migration events.

This is a great area to look to your partner for help and even deliv-
ery. The best partners employ advanced techniques and statisti-
cal methods to analyze and produce a detailed set of application
dependency communication maps.

Building a representative workload

The most important technical task in your entire migration — from
the moment you decide to perform a migration to the final “all
clear” — is building a representative workload. This one step will
guide nearly every other decision you make. Pair this with the right
people and tight collaboration, and your chances of success soar.

28 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 REPRESENTATION, NOT
DUPLICATION
It’s important to keep in mind that you should build a representative
workload, not a complete copy or representation of your entire envi-
ronment. So, if you have five applications, each with a web server,
application programming interface (API), and database, all of varying
complexity, you may create one simple workload with a web server,
API, and database, and then apply a multiplication factor (in this case,
5) to your results.

The key here is to keep things simple. You’re not trying to get exact
numbers; instead, you’re trying to get a reasonable estimate of pro-
jected results. You don’t want to spend time building a workload; you
want to spend time analyzing results.

A representative workload is just a model of what you want to

migrate. It’s a set of resources and components that behave in a
similar way to your actual migration resources, but ideally, it’s
smaller and easier to move around.

You’re going to use this workload over and over, so take the time
to automate its creation, teardown, and re-creation.

Automation is an important part of the cloud. If you currently use

manual steps to set up your environments, this is a good time
to replace those manual steps with scripts. A tool like Terraform
(www.terraform.io) is a great place to start, and it works with
any cloud provider.

Building affinity groups for different

types of workloads
If you have two different workloads that are wildly different, you
may need two different workloads to represent them. That’s okay.
In fact, you can group your similar workloads into affinity groups
(similar workloads or resource stacks that share characteristics).

CHAPTER 4 Migrating Before You Actually Migrate 29

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 So, you may have three affinity groups in the set of things you
want to migrate:

»» Web applications: This group may have applications with a

web-based front-end, an API layer, and a data store.
»» APIs: This group could store APIs that don’t have web or
user-facing front ends, but instead just code backed by a
data store.
»» File stores: This group is just what it sounds like: raw file
storage that is accessed or mapped to drives on the
network.
»» Virtual servers or environments for software as a service
(SaaS): You may have software that runs as a service and
just needs a server instance and a database.

You can create a representative workload for each group, and then
validate each workload independently according to the number
of things in each group. This extra granularity will help increase
your accuracy in planning and forecasting.

Validating your migration

using your workload
Now that you have a representative workload, you should measure
and write down your expectations for that workload. What CPU
requirements do you have? What storage and memory require-
ments? What network latency is acceptable, and does that latency
vary for outbound versus inbound traffic?

These are all items you should have from earlier in your planning
(Chapter 2 talks in detail about your baselines), but now you’re
validating those with running resources. You can then simply
multiply your findings by the number of representative workloads
you’ll be running. So, if you have one web server/API/database
in your representative workload and need to support eight, just
multiple your resource validation numbers by 8.

A linear scaling like this isn’t always accurate. However, in most

cases, it’s good enough to help you find major gaps or holes in
your understanding, and that’s all you’re looking for at this stage.
However, if your representative workload is not representative —
if it’s oversized or undersized — then all your calculations will be
similarly off base.

30 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Using Tooling to Validate Your Migration
The process of coming up with representative workloads is rel-
atively straightforward. The process of validating those work-
loads, deploying them to a cloud provider, getting performance
and resource numbers, and projecting those out for your actual
workload is not.

This is an area where getting some help can go a long way — both
from a support-from-real-people perspective, and a help-from-
mechanical-tooling perspective.

Asking your migration partner

for planning tools
Your migration partner is an essential resource at this stage. Their
experience really should start to benefit you — in planning, in
projections, in aligning your goals to your digital transforma-
tion, and even in helping ensure you have the right teams and the
right people. Ask them for help in measuring resource utilization,
projecting costs, and even migrating your representative workload.

Some migration partners will actually be leading the charge at

this stage. The best will help you develop your representative
workload and even provide you tooling to simulate a deployment
to your cloud provider with on-premises resources.

You should also ask your migration partners to validate your

strategies and models. In fact, many will offer to help you develop
these in the first place, which is even better. The value of an expe-
rienced partner in a cloud migration really cannot be overstated.

Getting to know your cloud

provider’s support
Any major cloud provider supplies accounts with access to sup-
port resources, and for even medium-size accounts, you’ll likely
have a technical account manager (TAM). TAMs are dedicated to
helping your migration go well. They often have access to tools
and knowledge that are priceless for a good migration.

CHAPTER 4 Migrating Before You Actually Migrate 31

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Many people don’t realize this and never even reach out to their
TAM. Call or email your account manager or support and ask if
you have a TAM. If you don’t, ask what minimum requirements
must be met to get a TAM. Often, a higher level of support is all
you need, and a few hundred bucks a month may get you that
support — and access to your TAM.

Knowing what your tools

should tell you
The combination of your own resources, your TAM, and your
partner’s tooling should allow you to do the following:

»» Deploy a workload. Whether you have to run a script or

push a button, you should be able to deploy (and more
important, redeploy) your workloads to your cloud provider
without lots of manual intervention.
»» Measure resource usage by type. Once deployed, you
should be able to get objective (numerical) measurements of
disk space, CPU usage, network bandwidth, database size,
and just about anything else related to your workload’s
usage of cloud resources.
»» Project costs. With those usage metrics, your tooling should
tell you how much your workload would cost to run over a
day, a month, or a year.
»» Tune resource usage. Now you can tune things. What if you
want to expand disk usage, or reduce network throughput?
You should be able to make these adjustments and re-project
costs.
»» Plan for expansion. What if you need to scale out, or add a
secondary environment? You should be able to plan costs
for these variations that go beyond just ramping up disk
space or the number of file stores you use.

Getting It Right
You’ve selected the right partner, you’ve got tools in place, and
now you need to test, test, and test again. This effort will pay off
because it significantly reduces risk when you actually do perform
your actual migration.

32 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 AUTOMATION IS EVERYTHING
You’ve read about automation at least three times by now, and it
could easily be a few pages of material on its own. You should auto-
mate every step of your build and migration, and any time you do
a manual step, figure out a way to turn that manual step into an
automated one.

The addition of a good DevOps engineer will help a lot here.

Automation is a key part of DevOps culture. When it’s time to perform
your migration to production, it’s essential to ensure that no manual
intervention is required.

Here are the keys to using this phase to serve you and avoid lin-
gering problems:

»» Document every issues that arises, especially how that issue

showed up (dropped connections or a 404 web error or lack
of access to the console) and how you resolved it (added
more memory, changed a route, added an admin user).
»» Automate every single change you make. Nothing gets
changed manually unless it’s immediately automated!
»» Keep a running deployment log of changes.
The entire cycle here is to test, observe, fix, and then repeat until
you’re ready to migrate.

Setting Your Expectations Correctly

It’s important to have the right goals for this phase of your migra-
tion. Just as you need to have clear goals and measurements for
your overall cost savings, productivity increase, and everything
else discussed in Chapter 1, you need similarly clear objectives for
your preparation and tuning of representative workloads.

CHAPTER 4 Migrating Before You Actually Migrate 33

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Focusing on deployment,
not architecture
Here are some great goals at this step:

»» Become confident in understanding the resources needed in

the cloud to support your workload.
»» Automate and make repeatable your deployment workflow.
»» Uncover hidden or undocumented deployment steps in your
planned migration.
»» Have order-of-magnitude cost projects that you can
compare to your original goals.

As a contrast, here are some goals you should not have:

»» Optimize the architecture of your representative workload.

»» Implement managed services or other cloud-specific aspects
of your workloads.
»» Highly tune costs of your representative workload.
Put even more directly, your focus at this stage is on smoothing
your deployments. You want a repeatable, predictable deployment
of components that model your environment. You do not want to
change your environments radically at this step.

Planning failure, not just success

Another key step of this phase is to clearly define processes for
when something goes wrong. Every failure to deploy or migrate
your test workloads should inform how you’ll respond if there’s
a failure in your actual migration. Write down who troubleshoots,
what tools are used, and how remediation is agreed upon.

In other words, you aren’t just building a process for a perfect

migration (although that would be nice!). Instead, you’re building
a process to handle all aspects of migration. You should have steps
that cover what to do when migration goes great, but you should
also have steps to cover what to do when migration goes poorly.

34 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Executing your migration

»» Thinking of your migration the right way

Chapter 5
Flipping the Switch

Y
ou’ve done all the preparation! You have the right people,
you’ve been having great meetings, and you’ve tested your
migration multiple times. You have a clear set of goals and
you’ve set a baseline. And you’ve adjusted that baseline based on
your representative workloads.

Finally, it’s time to actually migrate your workloads to the cloud.

Flip the switch — but don’t be surprised if things still don’t go
perfectly. That’s okay, though. You’re already prepared for what-
ever problems may arise.

Making Sure You’re Ready to Migrate

You’ve done a lot of hard and often tedious work at this point.
But that’s good! That means that what’s next — your actual
migration — should be pretty straightforward.

As a final checklist, you should have all the following before you
migrate to your cloud provider:

»» Well-defined teams that are all available to perform the

migration and escalate any issues that arise

CHAPTER 5 Flipping the Switch 35

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 »» A technical account manager (TAM) or support representa-
tive from your cloud provider, ideally available for help
»» A migration partner (and team) to help you migrate and
mitigate issues
»» Baselines and tests from your representative workloads to
measure your actual migration against
»» Contingency plans based on the various failed and partially
failed test migrations

If you have all of these, then it’s time to migrate! As simple as that
sounds, this step is really that straightforward.

Thinking of Your Migration as

Another Practice Migration
Think of your migration as just another migration in a long run
of practice migrations. If something goes wrong, the process is
no different. You roll back, capture lessons learned, make cor-
rections, and automate those corrections. Then you do the whole
thing over again.

It’s important that your actual (final) migration runs without

any errors. In other words, if you have to change anything post-
migration, you should automate that change and rerun the migra-
tion. This is the only way to be sure your process is repeatable.

Also realize that you’ve created something else that’s pretty

important: a repeatable process for deploying your infrastructure.
So, if you need to set up in another region, you can. If you need to
set up duplicate environments in the same region, you can.

All of these situations just require a working deployment, and

your hard work has given you just that.

Practice doesn’t make perfect; perfect practice makes perfect.

36 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Setting goals that guide your migration
approach

»» Building a plan and team to support your

migration

»» Determining if your goals have been met

through monitoring and metrics

Chapter 6
Managing Your Cloud
Environment

I
t’s easy to consider your migration complete when you have
everything you wanted in the cloud and running. But there’s
still important work left to do: You have to keep those resources
running. Even more important, you have to continue meeting the
business and technical goals you set weeks and months ago.

This chapter can’t possibly tell you everything you need to suc-
cessful manage a cloud environment. But it does get you headed
in the right direction and ensure you capitalize on your successful
cloud migration.

Visualizing Your Environment

Top performers in nearly every sport visualize their upcom-
ing competitions to gain a competitive advantage. In the high-
performance sport of business, the same is true. Successful
organizations have tools that provide them clear pictures of their
cloud environments. This is not just monitoring, but understand-
ing how your resources are laid out and connected, how you’re
using regions and zones in your provider, and what connects all
these environments.

CHAPTER 6 Managing Your Cloud Environment 37

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 There are a number of good free tools for inspecting and visual-
izing your environment, and your cloud provider may also provide
tooling here. You typically point these tools at your accounts, and
they give you a diagram (or more), as shown in Figure 6-1.

FIGURE 6-1: Visualizing top-level cloud-workload status.

As helpful as these tools are just for general understanding,

they’re also great for tracking down inefficiencies. Take some
time to trace a request from a customer through your various
resources, and make sure that you’re not doing unnecessary rout-
ing or wasting processing power. The increase in efficiency can be
monumental.

Selecting Cloud-Ready Tools

More than one company has had a great migration go off the
rails because a certain piece of software doesn’t function in the
cloud, or has only limited functionality in that context. This is
an area where you shouldn’t simply take a vendor’s word for it;
you should migrate and test your tools before you go live with the
same rigor that you test your own applications.

Not all tools that run in the cloud are created equal. Some tools
will run in the cloud, and others are built for the cloud. Unlike
your application, you should seek to convert to cloud-native tools
as quickly as possible. This is an area where a phased approach
will cost you time and money.

38 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Monitoring (the Smart Way)
Although monitoring certainly falls into the set of tools you’ll
want to select carefully — and select for cloud usage — it’s likely
the most important thing you can do for the health of your appli-
cation and your business.

Monitoring everything
One of the best things about the cloud is that monitoring is gener-
ally either free or so cheap at basic levels that it’s nearly free. And
if you choose third-party tools, those also often are either free or
incur a nominal payment.

The good news is that you don’t have to monitor just one set
of resources or one aspect of those resources. You can monitor
everything — and you should! You should collect metrics on every
resource, on CPU usage, on network usage, on disk space, on
requests and responses, on errors, and on pretty much anything
else you can think of.

The point is that by collecting data, you preserve flexibility.

Maybe you’ll need to track network requests in six months, and
that historical data you’re collecting now will become essential.
With monitoring and storage of metrics costing you only pennies,
you should be liberal with what you want to collect and how much
of that data you keep.

Reporting toward your goals

The next step is to build reports from your monitoring. Here, you
can be more selective. Some solutions will automatically build
application topology maps, alerting, reporting, and displays using
artificial intelligence (AI) and machine learning (ML) capabilities.
Take time to customize or build out reports (and often, real-time
dashboards) that show you what you want to see. This is where
your goals surface once again. If cost is a primary driver, create
graphs on cost and make them prominent parts of a cost utiliza-
tion dashboard. If you’re after increased traffic, report on traffic,
errors, request time, latency, and number of unique users.

In short, you should monitor everything, but report on your goals.

Building dashboards and reports takes time, so this is where you
should be selective. Then use those data to evaluate if you really
are meeting your goals, and adjust accordingly.

CHAPTER 6 Managing Your Cloud Environment 39

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Recognizing that unbounded
costs are a real thing
Even if you aren’t considering cost a primary driver, you should
have alerting and monitoring set up around costs. Cloud provid-
ers are typically unbounded in cost; that means that you can’t set
spend limits. You pay for what you use, and providers will typi-
cally let you use whatever — and however much — you want.

That’s a big deal. But the selections available are often complex
and hard to understand. If you aren’t paying attention, you can
easily amass thousands, and even tens of thousands, of dollars
in charges because all your developers spun up databases of their
own and your production application scaled out but was never set
to scale back down. Monitor costs and you’ll catch this and be able
to head off any unexpected costs quickly.

Buying versus Building

One important decision you’re going to have to face both main-
taining and moving forward with your applications is whether
to keep building out your own software and tools versus buying
existing ones.

This is always a consideration, but time and time again, the move
to the cloud has proven to be a major inflection point for com-
panies, and a great time to evaluate (or reevaluate) technology
decisions.

Building
Almost every organization with an existing engineering group
will lean toward building software, tools, and applications. It’s
likely why you created an engineering group — and what is hav-
ing engineers on hand worth if they’re not building something?

Building ensures ownership, intellectual property, deep under-

standing of what’s been built, and usually a greater degree of cus-
tomization than is possible with off-the-shelf software. It also
tends to increase engineering morale and, in many companies,
can increase the overall company value by providing proprietary
assets and competitive advantages.

40 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 The problem with building is ultimately time. It takes time to build
software, and that time costs money, opportunity, and potentially
market share. It also requires your team to be very good at any-
thing you build. This could gain you breadth but cost you depth
in other areas.

Buying
Buying may sound repugnant, especially to engineering-heavy
organizations. But the reality is that buying a solution — whether
for tooling or entire software suites — is often the faster and
more economical choice.

Consider building in one focused area that capitalizes on your

organization’s strength, expertise, and value propositions. If
you’re an ecommerce provider, build your core product and order
system. If you’re a data analysis firm, build your most complex
and valuable algorithms. Then purchase outside of those core
areas. You’ll move much more quickly and often get products
from organizations that are building out of their strengths.

You may be thinking that buying is expensive. But buying is rarely

more expensive than building. Just don’t buy in an area where you
need to capture value or maintain intellectual property.

If you decide to buy, begin with your migration partner. Do they

have solutions for you in terms of tooling and software? If not,
who have they worked with and integrated with before? The
more you can leverage an existing relationship — technical or
company-to-company — the more likely your purchase will be
a win.

CHAPTER 6 Managing Your Cloud Environment 41

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Identifying common migration
challenges

»» Knowing how to tackle those challenges

and keep moving

Chapter 7
Ten Cloud Migration
Challenges

H ere are ten challenges that you’ll need to overcome to

ensure a successful cloud migration.

Setting Clear and Flexible Business Goals

and Priorities
You need clear goals for your migration (see Chapter 1). But as
you move through migration, you need some degree of flexibility,
too. You may need to phase your migration, or you may find that
although cost is a driver, you’d be willing to give up some cost for
increased scalability and redundancy.

Your goals should be clear, but they must have some room for the
learning you’ll do during migration. If you have a change in prior-
ity, simply document that change and make sure the team knows
what they’re (now) shooting for. Then make sure your metrics
and baselines also reflect that new set of goals and priorities.

Change is not bad if it’s well communicated.

CHAPTER 7 Ten Cloud Migration Challenges 43

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Identifying What Should (and Should
Not) Be Migrated
Clear goals will give you insight into what you want to migrate
and what you may not. If high security of your data and blazing
throughput are key business and technical goals, you may want
to keep your critical data onsite, and build a high-speed virtual
private network (VPN) to your cloud. If cost and low maintenance
are drivers, you may want to migrate every resource you have.

Make clear decisions about which resources go to the cloud, share

those decisions, and stick with them. If you need to make changes,
consider an additional phase down the line.

Rearchitecting, Rewriting,
or Replacing Applications
Simple migrations are easier than complex migrations. Migra-
tions that involve re-architecture and rewriting often are trickier
than a simpler lift-and-shift.

Consider breaking your migration into steps. Move an application

to the cloud, convert to managed services, and then rewrite por-
tions of the application. This phased approach will significantly
reduce risk and complexity if you can afford the longer timeline.

Meeting Compliance and

Regulatory Requirements
This is a big one! If you have compliance or regulatory concerns,
you should either engage a partner or a team member that has
previous experience in cloud-based compliance. These issues
are quite complex ones in the cloud, with unbounded costs and
emerging policy considerations.

Do not try to figure this out for the first time during your migra-
tion. Instead, work with your experienced team members early to
reach out and get clarity on requirements, and check for compli-
ance at every step of your migration.

44 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Understanding Your Team’s Capabilities
Migration is an area where you shouldn’t be overly optimistic
about your team’s capabilities. Good team members can come
up on cloud skills, but you should bring in talent — employees,
consultants, and partners — to fill in the gaps if you want your
migration to move smoothly.

Consider building a matrix of responsibilities and fill in who on

your team will do each task. Any gaps should be filled before you
start migrating.

Keeping a Handle on Your

Costs as You Migrate
You need to do more than set a budget for your migration and
then check that budget every few months. Costs in migrations can
spike, often at unexpected times — perhaps when you create a
new database multiple times, or pull a lot of files you hosted on
the cloud back out of the cloud.

Checks on your costs should be a part of your weekly cadence,

and you should have a well-defined escalation and approval plan
when costs look to overrun.

Overrun is not necessarily bad if the overrun could predictably

result in long-term improvements toward your business goals.

Setting a Well-Controlled
Cadence for Transition
You should have weekly meetings that provide forward progress,
sprints with regular transition outputs, and a road map that you
reference and update weekly, if not daily. The more reliable and
predictable your schedule, the smoother your transition will go.
You’ll also be able to tell more quickly if things are falling behind.

CHAPTER 7 Ten Cloud Migration Challenges 45

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Right-Sizing Your Application
Workloads before Migration
You can right-size your application — hard disk space, allocated
CPUs, database shards, and so on — before or after you migrate.
The best solution, though, is to do both.

If you take some time to move over environments that are already
space-optimized, your baselines will be more accurate. This also
lets you separate two concerns: right-sizing your applications,
and the savings you get from your cloud provider.

Monitoring and Managing Your New

Hybrid or All-in-Cloud Environment
You should already believe that monitoring is a key part of oper-
ating in the cloud (see Chapter 6). But monitoring is an ongoing
process. You can’t just turn on monitoring and then never touch
things again. As you introduce new applications or re-architect
existing ones, you’ll likely need to tune your monitoring.

Consider setting up a quarterly monitoring review for all your

monitoring — onsite and in the cloud. Use this review to validate
what you’re monitoring, align with any new or updated business
goals, and adjust your metrics accordingly.

Measuring and Quantifying the Results

You need to decide what metrics you’re using to quantify success
(see Chapter 6). Is cost your primary driver? Is productivity? What
about uptime or users served?

Make clear decisions about which of your monitored metrics

define success, and try to consistently use those as key perfor-
mance indicators (KPIs).

46 Cloud Migration For Dummies, Virtana Special Edition

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.