The Discover/Assess Phase

https://cloud.google.com/solutions/best-practices-migrating-vm-to-compute-engine
 Assess/Discover Plan/Foundation Migrate! Optimize your
your application Create a landing Pick a path, operations and
landscape zone to the cloud and get started save on costs

Cloud migration is the journey, the end-to-end lifecycle whereby things

move from other locations (on-prem, other clouds) and into the GCP.
GCP is the destination where these things migrate to,
and which are often modernized/optimized in-cloud
afterwards.

You are here icon...get it?

 Learn how to...
Discover what apps a client has, using tools and interviews

Generate TCO and ROI estimates

Asses the discovered apps, sort by effort estimation, and pick a

first mover

Generate the input into the Plan/Foundation phase

Tools and interviews complement each other in the discovery phase.

TCO/ROI estimates were quite possibly completed in the sales process, but we will
refine them as part of discovery.
Agenda
Project Phases

Assessment and discovery

Phase 1: Automated discovery

Phase 2: Surveys and interviews

Phase 3: Analysis

Phase 4: Deliverables
 Project phases

Discover/Assess Plan/Foundation Migrate! Optimize

Preliminary Discovery Preliminary Planning

(pre-sales) (pre-sales)
Migration Optimize
Sprint Sprint

Main Discovery Main Planning

(pre/post sales) (pre/post sales)

Make the point that there’s the major, up front discovery/foundation phase you do to
build the foundation you need before you start migrating VMs to the cloud. Then,
there’s the short, more focused discover/foundation you’ll do each wave, to determine
how the foundation needs to be fine tuned. Plan/Foundation is Module 2, and then
we’ll be talking about the migration sprints in Module 3.
Agenda
Project Phases

Assessment and discovery

Phase 1: Automated discovery

Phase 2: Surveys and interviews

Phase 3: Analysis

Phase 4: Deliverables
 Discover and assess

Data gathering Application interviews Migration Backlog

Understand the requirements, Inquire about each application’s Rank & group applications and use
technical elements, dependencies, and criticality to the business, its impact story points to estimate effort.
complexities around each application. of migration on its users, roadmap &
most suitable strategy.

● Discover the service topology:

○ Identify existing applications, and their environments
○ Map the application dependencies

● Assess the challenges

○ Virtual machines or bare metal machines
○ On-premises, AWS, other
○ Licensing (Microsoft, Oracle)
○ Database: large, shared, unsupported

● Review your organizational requirements

○ Authentication and authorization
○ Server and application licensing
○ Network security requirements
 Discover/Assess overview
The Discover/Assess phase will help uncover the existing workloads that will need to be
migrated, and the information necessary to determine migration type, level of effort,
and application groups.

Input Activities Output

● Business objectives ● Phase 1: Automated discovery to see ● Workload grouping
● Key stakeholders what’s really there ● First mover workloads identified
● Technical assumptions ● Phase 2: Surveys and interviews to add ● Refined TCO/ROI Analysis
● Security approval for tooling context and scope ● High-level effort estimations
● Phase 3: Analyze, pick a first mover, and
start Wave planning
● Phase 4: Generate inputs to foundation

The goal here is to understand what you have, and what VMs can be migrated. We’ll
typically look to gather inventory data for the whole estate in one go using an
automated tool. This may have been done already as part of the initial ROI/TCO
analysis used to make the argument for moving to GCP. Once the inventory is
gathered, then consultants work with application owners and SMEs to help assign
meaning to what the tools are finding. This phase is the starting point of your VM
migration journey
 Discovery estimated Full Time Equivalents (FTEs)
● Typically discovery is 30%-50% of migration effort
● Rough estimates for assessment/discovery timing
○ Small – 200 VMs, up to 10 apps, 17 FTE days
○ Medium – 1000 VMs, up to 25 apps, 25 FTE days
○ Large – 2500 VMs, up to 60 apps, 50 FTE days
○ Extra Large, 4+ months
● Discovery for Migration Timing Details
● Discovery FTE Calculator

These numbers are based on Google’s experience with many VM migrations for
clients. The linked documents are used by Google as starting estimates for a
particular VM project.
 The migration discovery team
Partner Client

● Project manager(s) ● Project managers

● Cloud engineer(s) ● IT and security support
● Consultants with skills in: ● Application owners/SMEs for
○ Windows/Linux surveys and interviews
○ Security ● Project management support
○ Networking
● Compliance and licensing
● Google personnel? support

Let’s start with the team. The VM migration team will include partner consultants,
client contacts, and perhaps Google personnel.

Executive sponsorship is also critical for “making things happen” within the client
organization. They can, for instance, ensure you get the cooperation and support of
the key people within the organisation who you are relying upon for information
 Start!
● Start with a Kickoff event
○ Explain expectations and responsibilities to client
○ Migration Discovery Kickoff Deck
○ Migration Discovery Kickoff Agenda
● Create/contact GCP Center of Excellence team
○ Client is creating a Center of Excellence team
● Identify communication channels and key personnel
○ Track for easy access (Google sheet)
○ Who’s good at solving what kind of problem?

The linked documents are Google presentations you can tailor for your particular
project.

As your project progresses, you will need to document key personnel e.g. who knows
about what within the organisation.
Agenda
Project Phases

Assessment and discovery

Phase 1: Automated discovery

Phase 2: Surveys and interviews

Phase 3: Analysis

Phase 4: Deliverables
 Phase 1: automated discovery
● Number of tools that can help
○ CloudPhysics
○ StratoZone
○ RISC Networks, Cloudamize, others…
● When partners register the opportunity with Google,
CloudPhysics and StratoZone are free
○ May have optional commercial features
● RISC Networks and Cloudamize might require licensing
○ Keep checking!

Register to use:
● CloudPhysics: https://app.cloudphysics.com/partner/GCP/register
● Stratozone: https://gogcp.stratozone.com/
● RISC Networks: https://riscnetworks.com/google
● Cloudamize: https://app.cloudamize.com/setup .
Currently CloudPhysics and Stratozone are free for Google partners to use. The
other two tools may become free to use in the future, subject to agreement between
Google and the respective vendors
 Goals of automated discovery
● Shorten the sales cycle
● Understand existing infrastructure costs
○ On-prem or other cloud providers
● Predict TCO based on various configurations for GCP
● Spot migration challenges and obstacles
○ vSphere and OS versions
○ Machine and OS types

Automated tools can firm up the ROI figures for moving to the cloud, and can thus
shorten the sales cycle. It can also help you understand the current environment, and
even spot challenging VMs, all before you start trying to move it.
 Tools collect data in three main ways
● 1) From vSphere or AWS
○ Core infrastructure information
● 2) From machines using SSH/WMI
○ Add processes, installed applications, network connections, etc.
● 3) From agents installed node by node
○ Add database structures, resource usage breakdowns
● Data then compiled, encrypted, and passed back to tool hub
○ Usually cloud-based

CloudPhysics and StratoZone can both gather using the direct collection technique,
talking directly to AWS or vSphere. They can get a good deal of information with little
access.

StratoZone, RISC Networks, and Cloudamize all have options where an app or virtual
appliance is installed on a machine in the data center and then granted SSH/WMI
access to the other machines so they can gather more detailed data. RISC Networks
even has a version that can be installed all locally so no inventory or personalized
data passes out through firewall, if you’re willing to pay :-)

Cloudamize has a version that can get even more detailed information by installing an
agent on any inventoried machines.

Note that the same tool can use multiple information-gathering techniques, with
different access/security requirements. You will need to negotiate the latter with the
client.
 CloudPhysics VS StratoZone

● VMware or AWS customer ● Multiple hypervisor/CSP

● Agentless and probless ● Agentless, scans networks & queries VMs
● Google-Intel partnership w/ ● Also partner funded
● partner GTM and funding ● Full, unlimited access to discovery &
● Full, unlimited access to assessment and planning & roadmapping
discovery & assessment ● Provides migration module (extra cost)
● No automated dependency ● Integrates w/ Migrate for Compute Engine
scanning (coming late 2019) ● Professional services team

Both these tools are currently free to use for Google partners, so these are the two we
will be concentrating on in this class.
When to use:

● VMware or AWS customer ● Access to vSphere and to SSH/WMI into VMs

(Azure by end of 2019) ● Need TCO to make sale on non
● Can get access to vSphere VMware/AWS client
● Need TCO to make the sale ● Want deeper automated discovery including
● Need high level inventory info for dependency mapping for better discovery
discovery ● Willing to put up with tool
 CloudPhysics
5 Minutes to Activate on VMware and AWS
20 Minutes to Usable Analytics
Key Capabilities:
● HIPAA/ GDPR/SEC Compliant
● Continuous and most granular industry data collection
● Full resolution metadata unlocks savings missed by others
● Shared access – collaborate internally and with clients (SaaS) OBSERVER
Agentless
● The most accurate Cloud cost simulator in the market Non-intrusive
● Fact backed automated TCO proposal generator Lightweight
Multi-source

Nothing to install. Makes secure connection to VSphere or AWS and strictly pulls
infrastructure information. No agent to install, no internal machine metrics.

Sample report:
https://drive.google.com/open?id=1zM2rMKaH94z3nl_pOR7L0EKqYj3RlApY
 CloudPhysics operation
● Install the CloudPhysics Observer virtual appliance
○ Installing the Cloudphysics Observer
○ CloudPhysics Security
● Collect data from vSphere/AWS through read-only API access
○ No direct machine access
○ Updates every 20 seconds
● Compile data and send to CloudPhysics via SSL

Partners can register and set up their CloudPhysics partner portal here:
https://app.cloudphysics.com/partner/GCP/register

For additional installation information:

https://www.cloudphysics.com/installing-cloudphysics/
 Lab 1
Examining initial inventory and predict TCO/ROI
post-migration using CloudPhysics
 The dependency challenge
● Not just moving the app code
● Applications typically involve multiple VMs
○ Load balancers, web and app servers, DB servers, dev pipelines
● Applications may interact with other applications
○ Service architectures
● As a result, groups of machines will need to migrate together
○ Migration wave: group of related machines migrated together
● Dependencies should be collected over a business cycle
○ 7-30 days typically

VMs typically won’t be moved in isolation, you’ll want to move a group of related VMs
as a unit. A wave is a group of machines that we move together.

At the time of writing, CloudPhysics doesn’t do dependency mapping.

 Lift and shift before:

API gateway +
Data Center
VPN/Interconnect

Users
Dependency Dependency

Load balancer Web Application Application storage

Load balancer Web server Application
MySQL
appliance Linux server Linux
External
applications

Identifying these dependencies between VMs is vital in planning migration waves.

Tools like StratoZone, and talking to application owners and SMEs, can help us with
this task.
StratoZone
 Dependency mapping
● StratoZone’s StratoProbe is installed on a Windows machine in
the data center
○ Granted access to vSphere for infrastructure
○ Granted SSH/WMI access to machines (credentials, firewall)
● Collected data sent to StratoZone cloud via SSL
● Stratozone Deployment Guide

So the StratoProbe VM is installed into the data center. Firewalls are configured to
allow it to see the other machines. The probe is given credentials to get access to
vCenter, SSH access to Linux machines, and WMI access to Windows machines.
Using a combination of the inventory data coming out of vSphere, interactions
between machines tracked with netstat, and services inventories from the machines
themselves, StratoZone builds a map of different VMs and how they interact with
others. It also assigns labels to machines with common services.

Note that StratoZone interacts with individual machines as well as vSphere, so

greater security access needs to be granted.
 Lab 2
Set GCE rightsizing parameters and explore
dependencies with StratoZone
 Other tools: RISC Network

https://www.riscnetworks.com/use-casescloud-and-data-center-migration/
Can get flat rate partner or transactional pricing.
Partner licensing starts at $14,400 for 100 node licenses.
Transactional: $30 per node for 30 days, a node is a VM/device/server
Each collector can handle up to 15,000 VMs. Most tools top out at about 500 per.

Similar capabilities to Stratozone, but easier to use. Downside is cost (at time of
writing, partners have to pay to use this tool)
 Cloudamize
Assess
Make the business case of moving
to the cloud via TCO analysis across Data-backed
cloud service providers, and see answers to your
exactly what your infrastructure questions
would look like in the cloud
Plan
Quickly build an accurate, $100M in
executable migration plan based on end-client cost
application dependencies, savings
suitability, rightsizing, and in last 18 Months
complexity

Migrate 75%
Use to build more automated time reduction of
processes for migrating to the cloud migration
lifecycle

Cloudamize can get a lot of specific details using their installed agent approach, but
that means an agent being installed on every VM, which can be a challenge on many
fronts. Without the local agent, it takes a snapshot every 5 min and operates using
SSH/WMI and netstat.

Cloudamize can also break down R (Rehost, Replace, …) scores and generate a
matrix for you to help make decisions. Can also generate Migrate for Compute Engine
runbooks.

Cloudamize offers course attendees:

● 15 POC licenses at no-cost
● A Cloudamize demo and technical walkthrough
Feel free to register for a demo account and self-service training
● Register at https://dashboard.cloudamize.com/register.do (Leave access code
blank)
● Email [email protected] to set up a demo or for further technical
documents

27
 Tool summary
● CloudPhysics
○ Good with initial TCO/ROI, “Should we move to GCP”
○ Requires access to vSphere, AWS, or manually data upload
○ Free
● StratoZone
○ Good with automated discovery (including ROI) and dependency
mapping
○ Needs SSH/WMI access to machines
○ Poor documentation
○ UI could be more user friendly
○ Free

Again, both of these are free to Google partners.

Tool summary (continued)
● RISC networks
○ Feature rich, automated discovery and dependency mapping
○ Uses virtual appliance, needs SSH/WMI access to machines
○ Migrate for Compute Engine runbook generation
○ Check on cost
● Cloudamize
○ Good with automated discovery and dependency mapping
○ Uses SSH/WPI or installed agents for even more info
○ Check on cost
Agenda
Project Phases

Assessment and discovery

Phase 1: Automated discovery

Phase 2: Surveys and interviews

Phase 3: Analysis

Phase 4: Deliverables
 Phase 2: surveys and interviews
● Phase 1 delivered good information
● What’s missing?

Context! Through tools like StratoZone we see the machines with names, can
determine the running processes, and then the network interactions between can
identify dependency patterns, but even with all of that, we can’t know for sure exactly
what we are seeing.
What kind of people should we talk to?
●
●
●
●
●

● Need client app owners and SMEs

● Who knows about:
○ The applications as a whole?
○ This particular application?
○ What’s this VM doing? Why are these connections
being made?
○ How data is stored or cached?
○ The servers and their groupings?
○ The network/subnet/firewall configurations?
● Build a matrix of topics and SMEs/Stakeholders
● Send them the questions!
 Detailed interviews
● Automated tools are the start
○ Have an inventory, perhaps some apparent dependencies
● Start with questionnaires
○ Example application discovery questionnaire
○ Sample results used in exercise
● Could also generate manual worksheets like:
Application Inventory [TEMPLATE]

Why start with questionnaires and not jump right to in person interviews?
What if there are 100 apps. How many meetings before you find the right people, and
then find the answers that you need? Let the questionnaires filter and do initial
information gathering. Figure out who will be the helpful few for each application.
Keep those names for when you start migration (as opposed do discover/foundation)
sprints.

But! People tend to ignore questionnaires. Make sure there’s a good executive
sponsor who can wield the carrot/stick to keep the answers flowing.
 Lab 3
Set up and use the application discovery template
 Questionnaire review
● In the questionnaire, what were the major question categories?
● Any questions surprise you?
● Any questions you would add?

Remember, there’s a fine line between asking enough and asking too many. Not
everyone will know the answers to all questions, but this will help find who can help
and in which areas.
Agenda
Project Phases

Assessment and discovery

Phase 1: Automated discovery

Phase 2: Surveys and interviews

Phase 3: Analysis

Phase 4: Deliverables
Coming into phase 3: analysis
● Prerequisites for analysis:
○ Automated inventory and dependency groupings
○ Domain experts have added context
■ But they are still available to answer questions!
○ Better understanding of application architectures
 Phase 3: analysis

Limitation Analysis

Migration Approach

Effort Estimation

Wave Grouping

First Mover

Migration - Discovery - Data Analysis

1. Limitation analysis
○ Hard or impossible to move
2. Migration approach selection
○ How to get it into the cloud
3. Effort/complexity estimation
○ S/M/L complexity per app
4. Wave grouping (categorization; not waves)
5. First mover identification (nomination)

S/M/L as an example based on the t-shirt sizing approach:

https://medium.com/radius-engineering/project-estimation-through-t-shirt-size-ea496c
631428
 1) Limitation analysis: disqualified workloads
● Hardware: Mainframe, load balancer, AS-400, ...
● Desktop or non-intel operating systems
● Licenses that forbid cloud deployment
● General architecture challenges
○ Non-RFC 1918 IPs
○ Nested virtualization
○ UDP multicast

Limitation Analysis

Requirements for a specific MAC address.

Attached licenses on a USB.
 1) Limitation analysis: hard to move workloads
● Data challenges
○ Oracle, SQL Server
○ Large amounts of data
○ File servers/NAS/SMB/SAN
● Microsoft challenges
○ Windows Server Failover Clustering
○ SharePoint, SQL Server, AD, Azure AD
● Misc challenges
○ SAP, moving from Azure

Limitation Analysis

We’ll address most of these in this course.

Oracle
SQL Server

SQL Server in GCP best practices

Running Windows Server Failover Clustering

 2) Migration approach selection options

Public Lift and Shift Go Cloud Native

On-prem Remain On-premises Improve and Move

Classic apps & operations Cloud-native apps & operations

Migration Approach

Remember, most of our migrations will be somewhere on the lift and shift/improve and
move spectrum
 3) Effort/complexity estimation

● What are some ways we could rank application complexity?

● Rank complexity with a scoring system
○ Can be basic: Easy, Medium, Hard, XHard
● Good list of key elements here
● Example from the next exercises here

Effort Estimation

One approach here is to get each of the team to assign a complexity score to each of
the applications that need to be moved. High score and low score can explain how
they came up with the assigned score. Then the team leader can pick a score and
assign it to that particular application.

The linked document on the slide shows some of the dimensions of an application
that Google have found need to be considered when assigning a complexity score to
a migration.
 Sprints, backlogs, and waves

● Sprint: a time-boxed period when a team works to complete a set

amount of work
● Backlog: a prioritised list of work items
○ Each sprint will attempt to complete a portion
● Wave: a group of machines that will be migrated as a unit
○ Defined by a runbook in Migrate for Compute Engine
■ Broken into subunits called run groups

Once you have categorised your applications, you can decide in which sequence you
are going to migrate your application waves. As per Agile methods, we can organise
these waves into sprints, backlogs and waves.

Sprint: https://www.atlassian.com/agile/scrum/sprints
Backlog: https://www.atlassian.com/agile/scrum/backlogs
Wave is a migration-specific construct, that is defined by a runbook in Migrate for
Compute Engine
 Migrate
4) Wave grouping Prepare
Build target
environments and
Execute move of
apps and
services to GCP
select migration
candidates from
● Move groups of apps in waves backlog

○ An app is typically the Migration

Improve Sprint
smallest wave unit Learn lessons,
Test/Verify
improve
Conduct UAT and
● Wave 1: High business value, low migration
regression testing
process
effort to implement.
● Wave 2: High business value, high Optimize
effort to implement. Decouple state
and stateless,
● Wave 3: Low business value, low scale horizontally,
rightsize and PVM
effort to implement.
● Wave 4: Low business value, high
effort to implement.

Wave Grouping
© 2019 Google LLC. All rights reserved.

So look at the two main considerations: business and technical. First and foremost
there’s Technical. It would be preferable to move applications that are connected or
dependent at the same time, in the same wave. But from the business perspective,
you might not want to take out two particular critical systems at the same time while
they are being moved, or might not like the risk of the dual simultaneous move.

Also, don’t forget that with the right team, there can’t be two different sub-teams
working on moving waves simultaneously.
Backlog
● Each major discovery and foundation component
goes on the backlog
○ Name some?
● Initial sorting should consider:
○ Low hanging fruit (quick wins)
○ Business impact vs tolerance of downtime
● Format up to team
○ Post-its on a board
○ Google Doc
○ Jira
 Examples of application sorting

Disconnected Connected and Connected

and non-critical non-critical and critical

Marketing website Back office ERP

Backup and archive Batch processing OLTP database
Dev/test Data analysis E-commerce application
Experiments Data warehouses
Legacy hardware

Legend:

Easy Hard Can’t

As the migration proceeds, you will want to refine these initial classifications
 5) First mover identification

● Solid business value ● Limited challenges

● Tolerant of downtime ● Clear cloud licensing
● Typical of other apps (learn!) ● Can afford downtime
● Managed by friendly team
● Tied to stakeholder who likes
innovation
● Fewer system to system
dependencies
● Basic data requirements

First Mover

Never underestimate the importance of the confidence a good first move will bring
both the client and the migration team.
 First mover sweet spot

Business Criticality

Sensitivity to Downtime

First Mover

An ideal first mover is both reasonably important to the business (i.e. so people care
when the move is successful), and relatively insensitive to downtime.
 Poor first movers are:

● Highly dependent or depended upon

● Business critical and not tolerant of downtime
● Edge cases with unique architecture/technologies
● Not good examples to learn and gain confidence from
● Large or have overly complex data migrations
● Client facing

The more of these characteristics a particular application has, the less suitable it may
be as a first mover.
 Architecture: good first mover
Middleware clusters Log storage
Mobile application
Logger pool MongoDb
Users Javascript
WebApp
Metadata storage
Comments
pool MongoDb

Load balancer Application storage

External
Blog post
applications Load balancer
pool Cassandra
appliance

Cluster monitoring
Infrastructure Monitoring/
logging

Mobile application. It’s stand alone, interacts with other systems through the load
balancer making service calls, not tightly tied to anytihng it couldn’t access from GCP.
 Help minimize risk
● Make the move in low/no usage periods
○ Dark migration
● Have a clear rollback strategy
○ May be as easy as updating DNS
● Are internal facing
● Plan for the worst case
● Have architectural and application support
personnel on hand to help troubleshoot

All of the above factors can help mitigate the risk that a cloud migration represents to
the client.
Agenda
Project Phases

Assessment and discovery

Phase 1: Automated discovery

Phase 2: Surveys and interviews

Phase 3: Analysis

Phase 4: Deliverables
 Discover/Assess Plan/Foundation Migrate! Optimize your
your application Create a landing Pick a path, operations and
landscape zone to the cloud and get started save on costs

Cloud migration is the journey, the end-to-end lifecycle whereby things

move from other locations (on-prem, other clouds) and into the GCP.
GCP is the destination where these things migrate to,
and which are often modernized/optimized in-cloud
afterwards.

Time to move on
Deliverables

● Summary report
○ Everything done up to this point
● First mover/wave recommendation
● Technical landscape requirements
○ Need a place for the VMs to land, that’s next
 Lab 4
Analyze four applications, check for limitations,
estimate complexity of migration, sort migration
waves, and pick a first mover