Back in May, Google Cloud announced its intent to acquire Velostrata and its enterprise cloud migration technology. Since then, our Professional Services Organization has participated in large VM migration initiatives and observed the tremendous value that you, our customers gain from using Velostrata to migrate their virtualized workloads to Google Cloud Platform (GCP).

Velostrata decouples compute from storage and adapts workloads on the fly for execution in GCP. This means that your workloads start running almost immediately in GCP while the cold data migration takes place transparently in the background, but without any performance degradation to your workload. While following a prescribed process, our customers used Velostrata to migrate hundreds of VMs in just a few short weeks, and were able to avoid the operational difficulties that traditional migration methods interject. Through these experiences, our Professional Services team formed a lift-and-shift practice to assist our enterprise customers complete high-throughput VM migrations.

The secret to these migrations’ success is Velostrata’s smarts. Rather than take a deep copy mirroring approach, Velostrata uses an agentless technology to bootstrap VMs on the cloud, then streams in real-time compressed, deduped, and encrypted disk blocks from the original VM. Within minutes, the replacement cloud VM is up in the environment that was prepared for it and has access to the full original context. Your migration ops team quickly performs a smoke test of the application on the cloud and hands the app back to its owners. Velostrata, meanwhile, transfers the full content of the virtualized server transparently in the background. This all happens while maintaining data consistency in case a rollback is needed. When the cloud server is ready, Velostrata then cuts over (“detaches”) the newly deployed cloud environment and completes the migration.

How the Velostrata migration process works

Our experience building the Velostrata lift-and-shift practice demonstrated that dividing migration efforts into three major phases yielded the most optimal results.

1. An initial proof of concept of the technology to build user confidence in the technologies and methodology.  

2. Foundational activities, including setting up the GCP environments to receive the applications and the required shared services (LDAP, DNS, SSO, etc.).

3. The migration phase itself, organized into multiple biweekly sprints.

The migration phase is composed of three main activities, each with its own dedicated team, starting with discovery, followed by the migration itself and finally a post-migration transition. These activities take place in sequence and repeat on every sprint. Let’s explore these further.

1. Discovery

This first step in the migration, the discovery process, gathers relevant information about the source servers (configuration and dependencies) to be migrated. During this phase, the migration schedule for the sprint is established and communicated to the application teams. The discovery step is the foundation for a successful migration, and thus takes a disproportionate amount of time compared to subsequent steps. In our experience, it’s common to use the first week out of a two-week migration sprint for discovery.

At a high level, the discovery phase process can be summarized in the following set of tasks:

1. Evaluate the migration schedule to date and identify the next batch of servers to migrate.

2. Model the characteristics of the servers to be migrated in order to identify dependencies and required services.

3. In parallel with above, send application owners a questionnaire that gathers technical information about the servers.

4. Compare and reconcile information about the servers’ configurations and dependencies from the questionnaire.

5. Set, refine and communicate the final migration schedule.

The questionnaire, in turn, should gather the following data points:

• Application team operational points of contacts

• Machine specifications (cores, RAM, local disk, etc.)

• Operating system and specific configurations

• Network ingress/egress bandwidth needs

• Associated firewall rules

• DNS entries

• Databases hosted/accessed

• Required attached storage

• Load balancing needs

• Authentication needs

• Integrated monitoring systems

• Associated cost center

2. Migration

The actual migration moves target VMs from on-premises data centers (and other cloud providers) into GCP. Because of Velostrata’s sophistication and automation, the migration is mostly transparent to the application, involving only a short (5 to 10 minutes) downtime that is both upfront and easy to predict and schedule, as well as almost no operational work. In our process, migration takes place during the second week of a two-week sprint.

3. Post migration

The post-migration step involves placing the migrated VMs and applications under observation and responding to any user-reported incidents, usually for a duration of a few days. The app then transitions to regular operations and you can decommission the original servers.

Using Velostrata for your migrations

We are very excited to see these early successes with our enterprise customers’ mass migrations to GCP, and we are even more excited to offer the Velostrata migration solution to GCP customers for free when migrating  to GCP. When you use Velostrata within this lift-and-shift practice, migrating large numbers of VMs to the cloud has never been easier. If your company is planning a large migration of servers and would like our help, feel free to reach out to your GCP sales representative and ask to involve Google Professional Services. Happy migration!