I’ve carried production systems on Azure, AWS, and Google Cloud — and walked workloads from one to another when the economics said to. Years of doing that taught me when a fast lift-and-shift beats a rewrite, when a refactor actually pays for itself, where serverless saves money and where it bites, and when Kubernetes earns its operational weight. My rule is simple: pick the cloud the workload wants, and build so the exit door never rusts shut.
Translating from the one cloud you know sounds fine until you’re the one on call. I’ve been accountable in production on each of the three: rebuilding a mainframe banking core on Azure for ten million users, running distributed ML on AWS EKS at Koch Industries, and right now walking an enterprise healthcare platform through an AWS → GCP migration — a service-by-service translation where Lambda becomes Cloud Run, DynamoDB becomes Firestore, and HealthLake becomes the Google Healthcare API. That working fluency is the only honest basis for telling anyone which cloud to choose.
Six disciplines I practice hands-on, keyboard down, across Azure, AWS, and Google Cloud.
The first call on any migration is which of the four R’s a workload gets — rehost, replatform, refactor, or rearchitect — and I’ve learned to make that call per workload, never per portfolio. I’ve moved on-prem estates to cloud, cloud to cloud, and mainframes into microservices, keeping hybrid coexistence patterns and identity/network bridges alive so nothing goes dark mid-flight. Then I write the code, not just the diagram.
I reach for AWS Lambda, Google Cloud Run and Cloud Functions, Azure Functions and Durable Functions when traffic is bursty and idle compute is wasted money. Orchestrating Durable Functions over a legacy SQL estate in oil & gas taught me the most; today I run Cloud Run services on a live healthcare migration. The lesson I keep re-learning: scale-to-zero is both a billing feature and an architecture constraint — design for both.
I’ve run production clusters on AKS, EKS, and GKE — Flux for GitOps, KEDA for event-driven autoscaling, and stateful workloads handled with the respect they demand. My take after years of clusters: reach for Kubernetes when portability genuinely matters, and have the discipline to skip it when it doesn’t. See my Kubernetes work
I’ve built warehouses and lakehouses on BigQuery, Synapse, and Databricks, streamed events through Event Hub, Kinesis, Pub/Sub, and Kafka, and hauled SQL Server, Oracle, and DB2 databases into cloud-native stores. Every migration I’ve run has confirmed the same thing: the data layer is where cloud moves get stuck — so I start there instead of saving it for last.
I stopped trusting hand-built environments a long time ago. Everything I stand up now is Terraform, Pulumi (C# / TypeScript / Python / Go), or Terragrunt with OpenTofu — that last combination on a current GCP engagement. My working rule: an environment that isn’t in the repo is a rumor, not infrastructure.
I design the compliance posture before I draw the second box: KMS and envelope encryption, least-privilege IAM, VPC segmentation, and real secrets management on whichever cloud I’m standing on. Shipping under HIPAA, banking, and insurance regimes taught me that retrofitting security is always the expensive way to do it. See my security work
The two habits I bring to every cloud program — triage migrations workload by workload, and refuse to get locked in.
I’ve watched both failure modes up close: the all-lift-and-shift program that pays a premium forever, and the all-refactor program that never reaches production. So I triage. Stable systems get rehosted, systems starving for managed services get replatformed, the few that justify the effort get refactored, and anything nobody will miss gets retired — and only once the estate has landed do I turn to cost and operations.
flowchart LR
ASSESS["Assess -- inventory, dependencies, compliance"] --> DECIDE{"Per-workload decision"}
DECIDE --> RH["Rehost -- lift-and-shift, fastest path"]
DECIDE --> RP["Replatform -- managed DBs, containers"]
DECIDE --> RF["Refactor -- serverless, microservices"]
DECIDE --> RT["Retire -- decommission the dead weight"]
RH --> LAND["Land -- hybrid identity and network bridges"]
RP --> LAND
RF --> LAND
LAND --> OPT["Optimize -- cost, performance, runbooks"]
I use managed services enthusiastically — behind interfaces I own. On my current healthcare migration that meant writing a fully unit-tested Pub/Sub abstraction layer, so swapping Google Pub/Sub for Kafka is a configuration decision rather than a rewrite. Containers, IaC, and open interfaces do the same job at other layers; it’s how I make sure whoever I’m building for walks into every renewal with options.
flowchart TD
APP["Application services -- containers, tested business logic"] --> ABS["Abstraction layer -- messaging, storage, identity interfaces"]
ABS --> AZ["Azure -- AKS, Functions, Event Hub, Synapse"]
ABS --> AWS["AWS -- EKS, Lambda, Kinesis, HealthLake"]
ABS --> GCP["Google Cloud -- GKE, Cloud Run, Pub/Sub, BigQuery"]
IAC["Infrastructure as code -- Terraform, Pulumi, OpenTofu"] --> AZ
IAC --> AWS
IAC --> GCP
Six engagements I worked hands-on across Azure, AWS, and GCP — the migrations, serverless builds, and clusters that carried real traffic.
Right now I’m moving an enterprise healthcare interoperability platform from AWS to Google Cloud: AI agents doing the heavy lifting on the FHIR/HL7 codebase ports, Cloud Run and Pub/Sub waiting on the receiving end, Terragrunt/OpenTofu standing up the infrastructure, and the HIPAA posture held intact every step of the way.
At Fiserv I was Business Solutions Architect on a mainframe-to-Azure banking modernization with ten million users depending on it. Distributed microservices took over from the legacy cores piece by piece, and the architecture patterns I set were what sixty developers coded against.
At Koch I built a production-capacity forecasting platform on AWS EKS with KEDA event-driven autoscaling: feature processing parallelized across the cluster, inference scaling with per-business-unit demand, and multiple Koch companies served from the one platform.
For FM Global I delivered a property-risk GIS platform built on Azure end to end: an AKS cluster crunching a satellite-imagery analysis pipeline, KEDA handling the autoscaling, Databricks wired in for the analytics — while I led a 50-developer team to delivery.
One of my favorite pragmatic wins: I put Azure Durable Functions to work orchestrating long-running workflows directly over a legacy SQL estate for an oil & gas platform. The client got serverless elasticity years before a full replatform could have delivered it.
For a national wealth-management and tax-advisory firm I went fully serverless on the account-maintenance workflows: Step Functions driving Lambdas behind API Gateway, Cognito scopes handling authorization, CloudFormation and the Serverless framework defining the stacks. I paired with QA to test it and walked it into UAT myself.
The engagement that taught me what hosting really costs: I designed, built, and then ran a B2B EDI distribution system on Google Cloud for eight years — the VM, MariaDB, the FTP estate, nginx, the cron fleet, and the pager all mine. You write different code when you are the one it wakes up.
Read the write-upMigrations, serverless, Kubernetes, data, security — I do the work myself on Azure, AWS, and Google Cloud, and I match the cloud to the workload rather than the other way around.