Move to Google Cloud without a nervous weekend
From on-prem servers, a PaaS or another cloud: planned in stages, rehearsed, and reversible until the last step.
Sound familiar?
- The data center contract is ending, or the PaaS bill grew faster than the business.
- Nobody fully knows what runs on the old servers.
- The last migration stalled halfway, and now you run both.
- Downtime is not an option, and neither is freezing features for six months.
What you get
An honest inventory
What really runs, what depends on what, and what can simply be switched off.
A plan in stages
Each stage with a way back, so nothing is a one-way door until it has to be.
The target built first, in code
Networking, IAM, GKE or Cloud Run, and Cloud SQL, ready before any traffic moves.
Data moved carefully
Replication where it matters, so the cutover is a switch, not a long export.
A rehearsed cutover
A runbook practised beforehand and usually run after hours.
How it runs
Review
You show me what runs and where it hurts. I look at the real setup, not a slide deck.
Plan
A short written plan: what changes, in what order, and how long it takes.
Build
Small steps you can review and roll back, dev before prod.
Handover
Docs and a runbook so your team can run it, with me on call if you want.
Where I've done this
- Moved a B2B SaaS startup off Heroku onto GKE and Cloudflare, then, in the same five-month engagement, added a second region outside Google Cloud.
The second region, in detail → - Migrated a bank's legacy on-prem applications to GCP, redesigned for the cloud, at about 35% lower infrastructure cost (HSBC).
- Migrated on-prem applications to cloud-native equivalents at InPost.