network require, are not available
off-network. To address this need, the
team introduced a DNS resolver that
runs inside each instance to proxy requests for internal DNS zones back
to the corporate servers over HTTP
through a BeyondCorp proxy.
Alpha and Beta Rollouts
Before beginning the migration to GCP
in earnest, the team conducted alpha
and beta rollouts as initial sets of features were ready. The alpha release targeted roughly 100 users, while the beta
release targeted roughly 1,000 users.
To evaluate the success of both
releases, the following metrics were
tracked and compared with Google’s
existing corporate fleet statistics:
˲ Pager load. There was a 95% drop
in pager load once we migrated virtual
desktops to Google Cloud, in large part
because of the platform abstraction
provided by GCP. While the team maintained a large fleet of physical servers,
storage units, network equipment, and
support software to run virtual desktops on the corporate network, GCE
removed all these concerns.
˲ Interrupts load. Initially, the migration to cloud led to an increase in
interrupts as a result of the novelty
of the system (which also resulted in
a corresponding increase in product
bug reports). After this initial surge,
interrupts load dropped to just 20% of
the volume experienced when virtual
desktops were hosted on the corporate network.
˲ Login rates. Seven- and 30-day login
rates before and after the migration
To inform the roadmap for future
milestones, the team also collected
data during alpha and beta releases via
two main avenues:
˲ User-reported feedback. User feedback in the form of tickets, bug reports,
emails, and word of mouth provided a
list of items to fix. The team filed bugs
to track each list item, prioritized by severity, number of users impacted, and
aggregated customer preference. The
last metric was made measurable by offering power users 100 “feature points”
to apportion across features as they
wished. These metrics could then be
used to inform development priorities.
˲ Surveys. Surveys measured subjec-
tive impressions from the user base
with the goal of improving market-
ing. For example, subjective feedback
on the relative performance of virtual
desktops on Cloud versus the corpo-
rate network was split (when, in fact,
performance on Cloud was superior).
In response, the team emphasized and
more heavily promoted benchmarking
results to customers, with the hope of
prompting more objective valuations.
Surveys also helped quantify fears
about the transition, most notably
around performance, user-data mi-
gration, and the ability to roll back to
the corporate network-hosted offer-
ing when a given user workflow was
Based on survey feedback, the team
emphasized the following aspects to
make the migration to Google Cloud
attractive to users:
˲ Improved VM specs. Users were offered large increases in standard CPU,
RAM, and disk specs.
˲ One-click personal data migration.
The migration process was easy to begin with, and it automated the most
time-consuming part of users’ workflow: copying over personal data.
˲ Easy rollback. The migration process allowed users to roll back to their
Corp-hosted instances, which were
simply shut down before the migration
to Cloud. Unused Corp-hosted instances were deleted after a grace period of
˲ Impact on the company. Clearly articulating the cost reduction to Google
helped reassure users they were doing
the right thing for the company.
Migrating Users: Technical
and Process Details
After collecting data and feedback from
alpha and beta rollouts, the team was
ready to proceed with the general migration to Cloud. This section details the
main features of the migration process.
Trade-in. Once the provisioning system was ready for new users, approximately 20,000 virtual desktop users
had to be moved to the new product.
The team briefly considered a naive
strategy of simply moving each user’s
disks into a new Cloud instance, but
experience in managing the existing
platform pointed in a slightly different direction.
Occasionally, the old platform experienced a fault that required significant
A host must be
able to securely
to construct its
policies such that
users have access.