Cloud migration
Migrate to Google Cloud Platformfrom your current servers or another cloud
Google's tools move VMs and databases, but they differ a lot in what they cover. Here are the supported paths, where conversion stops, and what needs a human decision.
Virtual machines
Migrate to Virtual Machines moves VM instances and their disks into Google Cloud. Google lists on-premises VMware vSphere, AWS, Azure and Google Cloud VMware Engine as sources, and the target can be a Compute Engine VM or Persistent Disk volumes. Moving the disks alone is useful when you plan to attach the data to a machine you have built fresh.
A VM that moves unchanged keeps its operating system, its old packages and its assumptions about the network. So the first question for each machine is whether it should move at all. Some workloads are better replaced by a managed service, while a server nobody can explain is usually better investigated than copied.
Databases: which paths Google supports
Database Migration Service targets Cloud SQL and AlloyDB for PostgreSQL. The paths Google names are MySQL to Cloud SQL for MySQL; PostgreSQL to Cloud SQL for PostgreSQL or AlloyDB; SQL Server to Cloud SQL for SQL Server; and Oracle or SQL Server to Cloud SQL for PostgreSQL or AlloyDB. Check your exact source version against Google's documentation before planning around any of them.
Continuous migration runs a full dump and load, then follows changes through change data capture, so the final switch can be short. How short depends on how far replication lags at the moment you stop writes, and on how long your application takes to reconnect and warm its caches. We measure both in rehearsal, and base the cutover window on the measurement.
Changing database engine is a different project
Moving from Oracle or SQL Server to PostgreSQL uses a conversion workspace, which converts schema and objects and lets you refine the results in a SQL editor, with Gemini-assisted conversion available. That gets you a long way on tables and views. The difficult part tends to be stored procedures, vendor-specific SQL inside the application, and differences in how each engine treats types, time zones, empty strings and sort order.
Conversion output needs testing against real queries from your application, not just a successful build. Reports and financial totals are the first thing to compare, since small differences in rounding or null handling show up there.
What to plan outside the tools
- IAM. Google Cloud's project and folder structure and its service accounts don't map one-to-one onto AWS accounts or on-premises roles, so permissions get designed rather than copied.
- Networking. VPC design, private access to Cloud SQL and any link back to your old network come before the first workload moves.
- DNS and TTLs. Lower them well before cutover, or the switch takes as long as the longest cache.
- Rollback. Decide in advance how long the old system stays ready, and what happens to data written to the new one in that time.
What we can show you
We have no published Google Cloud migration. Our published migration work is at application and database level, such as moving a cabinet manufacturer from MySQL 5.0 to MySQL 8 with validation at every step. If you need a Google Cloud partner for a data-centre exit, look for that specifically. If your need is an application and its database moving safely, that is closer to our experience.
Google Cloud migration questions
Can we move from AWS or Azure to Google Cloud?
Google lists AWS and Azure as sources for Migrate to Virtual Machines. Managed services on the old cloud don't move this way, so those need their own plan, and that often accounts for most of the work.
Will Oracle to PostgreSQL convert automatically?
Partly. A conversion workspace converts schema and objects, and you refine the rest. Plan for manual work on stored procedures and on SQL embedded in the application.
What database are you running, and which version?
Tell us the engine, its version and how long you can pause writes. We will tell you which path applies and what to test first.
We reply within one business day (IST).