Migrating to Google Cloud Platform isn’t hard per se, but there’s a lot to think about. And thankfully, it doesn’t need to happen all at once.
In his presentation, “Getting to the Cloud with Google Cloud Platform: A Sequential Approach” Google Cloud Solutions Architect Peter-Mark Verwoerd lays out a five-step plan to migrate workloads from an on-premises environment to GCP. It’s worth watching the webcast in its entirety, but until then, here are the high notes.
Phase One: Assess
Before you move a single bit, take stock of your applications and how suitable they are for the cloud. Things to think about include (but are not limited to) hardware and performance requirements, users, licensing, compliance needs and application dependencies.
Generally speaking, apps fall into one of three buckets: Easy to Move, Hard to Move, and Can’t Move. In our experience, applications that most often fall into the Easy to Move bucket are greenfield apps (no surprise there), test and dev and Q&A. Internal web apps and batch processing applications are also good cloud candidates, because they can scale horizontally rather than vertically.
Phase Two: Pilot
This is the point where you take one or two applications, and try moving them. Learn about Cloud Platform and its design patterns, take the time to validate performance, consider your licensing options and establish how to perform a rollback. Don’t skip this step, and don’t be tempted to try and migrate too many apps all at once!
Phase Three: Move Data
Some people will tell you to move your applications first, then move your data, but we beg to differ. Most applications have a lot of data with a lot of dependencies. Properly moving data to the cloud sets the stage for a successful application migration later on.
This is also the time to consider your various cloud storage options — regular Google Cloud Storage or Nearline? Local SSDs or persistent disks? Google Cloud SQL,Datastore or Bigtable? You should also think about how you’re going to move all that data — via batch data transfers, offline disk imports, with database dumps, or streaming to persistent disks? There are lots of things to consider here.
Phase Four: Move Applications
Now that your data is in the cloud, you’re ready to move the actual apps. Here too, there are decisions to make. We recommend keeping things simple, and doing the minimum necessary to get the application up and running in the cloud, for example doing a straight lift-and-shift. Or perhaps you can get an app into the cloud by way of backing it up there? That way, in the event of an outage, there’s a full copy of your environment in GCP waiting to take over.
Phase Five: Optimize
This is where the fun begins. Once an application and its data have been migrated to GCP, you can start thinking about all the cool ways to make it better. For example, this might be a time to add redundancy in the form of availability zones, elasticity with autoscaling groups, or enhanced monitoring with Stackdriver. You might want to offload static assets off of your application tier into Cloud Storage, or decouple tiers by using Pub/Sub. Google’s Deployment Manager can make it easier to launch and scale new instances, and copying your configuration into a second region can insulate you from a regional outage.
See? That wasn’t so bad. In the meantime, if you’d like to turbocharge your VM migration process, we also have systems integration partners that are cloud migration and GCP experts and would be happy to assist you. You can find more resources on migrating to GCP, including a list of certifed partners, athttps://cloud.google.com/migrate/. Here’s the webinar once again, for a more detailed step-by-step guide.