Helping business case formation, adoption strategy, team planning and road map creation, we enable the IT organization to deliver business value from your cloud investments.
Our process consists of 5 phases (Each built up on the other)
- Assess
- Pilot
- Move Data
- Move Applications
- Optimize
Phase One: Assess
Before any movement is even considered, we form a discovery exercise intended to understand current state your applications and determine suitability for Google cloud.
During this phase, we focus on hardware and performance requirements, users, licensing, compliance needs and any application dependencies.
We then classify the applications into 4 buckets:
- No Impact
- Low Impact
- High Impact
- Not suitable for the cloud
In our experience, applications that most often fall into the No impact bucket are greenfield apps, test and dev, staging and Q&A. In addition any internal web apps that include batch processing applications are also great Google cloud candidates due to the ability to scale horizontally rather than vertically.
Phase Two: Pilot
This is the phase where some action occurs, we plan and take one or two applications from the no impact group and try moving them. Of course, a lot of testing and upfront validation is involved before launching into a production move. We also help your team to learn about the Google Cloud Platform and its design patterns and how to to validate performance. We also discuss Google cloud licensing options and establish how to perform a rollback. Our advice is not to skip this step, and resist the temptation to migrate too many apps at once.
Phase Three: Data Movement
The cloud migration world has all kinds of approaches. We’ve heard many people say that it is best to move your applications first and only then move the data. Google recommends moving the applications after the data migration. Google understands that most applications have a lot of data and come with a lot of dependencies. Hence, proper movement of data to the cloud sets the stage for a successful application migration.
Phase 3 is the time to consider the various cloud storage options — regular Google Cloud Storage or Nearline? Local SSDs or persistent disks? Google Cloud SQL, Datastore or Bigtable?
There also needs to be proper planning around how the actual data movement will occur — will this be done via batch data transfers or will we leverage offline disk imports, or database dumps, or streaming to persistent disks?
Phase Four: Application Migration
Once the data is in the cloud, validation will be performed and in the most part this means, once the validation is completed, the movement of the actual apps is ready to go.
However, there still are decisions to make. Google recommends doing the minimum necessary to get the application up and running in the cloud. This doesn’t mean that there are compromises or changes in any functionality or complexity that was already there.
An example of the application migration considerations are: Is doing a straight lift-and-shift feasible? Or perhaps is there a way to get the app into the cloud by way of backing it up there?
There are various considerations in the event of an outage for example – this way, there’s a full copy of your environment in GCP waiting to take over at any point of failure.
Phase Five: Optimize
This is where you see the real power of the cloud and the fun begins.
After an application and its data have been migrated to Google Cloud Platform, there are some very cool ways to make it easier and seamless.
An example might be – This would be a time to think about adding redundancy in the form of availability zones, elasticity with auto-scaling groups, or enhanced monitoring with Stackdriver.
There also might be opportunities to offload static assets off of the application tier into Cloud Storage, or decouple tiers by using Pub/Sub.
Google’s Deployment Manager can make it very seamless to launch and scale new instances, while preserving your configuration in a second region thus insulating you from a regional outage.
