Azure, AWS, and Google Cloud — we have shipped production systems on all three, and we’ve moved workloads between them. Lift-and-shift when speed matters, full refactor when the architecture deserves it, serverless where the workload is bursty, and Kubernetes where the platform needs to be portable. We don’t sell one cloud; we architect for the one that fits — and we make sure you can leave it if you ever need to.
Most shops know one cloud and translate. We have carried production responsibility on all three: a mainframe-to-Azure banking modernization serving ten million users, distributed ML on AWS EKS for Koch Industries, and an active enterprise AWS → GCP healthcare migration where we map services one-to-one — Lambda to Cloud Run, DynamoDB to Firestore, HealthLake to the Google Healthcare API. Knowing all three is what lets us recommend the right one.
Six cloud disciplines, delivered on Azure, AWS, and Google Cloud.
Rehost, replatform, refactor, or rearchitect — we scope which of the four fits each workload, then execute. On-prem to cloud, cloud to cloud, mainframe to microservices, with hybrid coexistence patterns and identity/network bridges to keep the business running through long migration windows. No consulting deck and walk-away — we ship the migration.
AWS Lambda, Google Cloud Run and Cloud Functions, Azure Functions and Durable Functions — compute that scales to zero when idle and to a spike when it isn’t. We wired Azure Durable Functions over legacy SQL for an oil & gas platform and run Cloud Run services on an active healthcare migration. Pay for work, not for waiting.
Production clusters on AKS, EKS, and GKE — GitOps delivery with Flux, KEDA event-driven autoscaling, and stateful workloads done properly. When the workload should be portable across clouds, Kubernetes is how we keep it that way. See the Kubernetes practice
Warehouses and lakehouses on BigQuery, Synapse, and Databricks; ingestion with Event Hub, Kinesis, Pub/Sub, and Kafka; database migrations from SQL Server, Oracle, and DB2 to cloud-native stores. The data layer is usually the hardest part of a cloud move — it’s also the part we lead with.
Reproducible environments defined in code — Terraform, Pulumi (C# / TypeScript / Python / Go), and Terragrunt with OpenTofu on a current GCP engagement. If it isn’t in the repo, it doesn’t exist: every environment stands up the same way, every time.
KMS and envelope encryption, least-privilege IAM, VPC segmentation, and secrets management on all three clouds — with HIPAA, banking, and insurance compliance postures designed in from the first diagram. See the security practice
Two patterns behind every cloud program we run — the migration decision path, and portability by design.
A migration that lift-and-shifts everything overpays forever; one that refactors everything never ships. We assess each workload and route it: rehost what’s stable, replatform what needs managed services, refactor what earns it, and retire what nobody will miss — then optimize cost and operations once the estate has landed.
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"]
Managed services are worth using and worth abstracting. On our current healthcare migration we built a fully unit-tested Pub/Sub abstraction layer so the platform can move between Google Pub/Sub and Kafka without rewrites — the same discipline we apply with containers, IaC, and open interfaces so the business keeps its leverage at renewal time.
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 across the three hyperscalers — migration, serverless, and Kubernetes under real load.
An enterprise healthcare interoperability platform moving from AWS to Google Cloud — AI agents porting the FHIR/HL7 codebases, Cloud Run and Pub/Sub on the receiving end, Terragrunt/OpenTofu standing it up, and the HIPAA posture preserved throughout.
Read the full case studyBusiness Solutions Architect on a mainframe-to-Azure banking modernization serving ten million users — distributed microservices replacing legacy cores, with the architecture patterns that sixty developers built against.
A production-capacity forecasting platform on AWS EKS with KEDA event-driven autoscaling — parallelized feature processing and inference scaling against per-business-unit demand across multiple Koch companies.
Read the full case studyA property-risk GIS platform delivered on Azure end to end — an AKS cluster running a satellite-imagery analysis pipeline with KEDA autoscaling and Databricks integration, with a 50-developer team led to delivery.
Serverless where it counts: Azure Durable Functions orchestrating long-running workflows on top of a legacy SQL estate for an oil & gas platform — modern elasticity without waiting for the full replatform.
At a national wealth-management and tax-advisory firm, Leopard Data built serverless account-maintenance workflows on AWS — Step Functions orchestrating Lambdas behind API Gateway, Cognito authorization scopes, and CloudFormation/Serverless-framework stacks — paired-tested with QA and delivered into UAT.
Lift-and-shift, serverless, Kubernetes, data, and security — on Azure, AWS, and Google Cloud. Leopard Data picks the right cloud for the workload and delivers it hands-on. Corp-to-Corp engagements out of Plano, TX.