Cloud and infrastructure, move by move.
Data-center exits, VMware after Broadcom, landing zones rebuilt so the next team can find things. Each move here was run in waves, with rollback written before the first workload moved.
- Cloud landing zone and account vendingimplementation · delivered
- Data center exit to AWS or Azuremigration · delivered
- Hand-built cloud to Terraform or OpenTofumodernization · delivered
- Kubernetes, EKS and OpenShift version upgradesupgrade · delivered
- VMware exit after the Broadcom licensing changesmigration · delivered
- Windows Server 2016 and SQL Server 2016 end of supportupgrade · delivered
Cloud landing zone and account vending
Told without the client's name or anything that could identify them.
A media company's cloud team created accounts and subscriptions by hand, so each one arrived with different settings and new environments were a long wait. Logs lived in each account, guardrails were written in a wiki rather than enforced, and the Azure side still depended on Blueprints and the archived enterprise-scale module. We designed the organizational unit and management group hierarchy around environments and risk, federated access through Entra ID, and built central logging, security tooling and a hub network as code. Account Factory for Terraform on AWS and a subscription vending module on Azure now create environments from a pull request. Existing accounts were enrolled with guardrails in audit mode first, and Blueprint assignments were converted to deployment stacks.
what the client got- New environments come from a pull requestTeams request an account or subscription with owner, cost center and environment in a pull request, and vending applies the same baseline customizations every time.
- Guardrails are enforced, not documentedService control policies and Azure Policy deny effects apply by level of the hierarchy, and each control ran in audit mode against existing accounts before enforcement.
- Logs are in one placeWe set up organization-wide CloudTrail and activity log export into a central log archive. An incident no longer starts with asking each team for access.
All 6 in cloud and infrastructure
Read any of them and you get the story, the before-and-after architecture, the plan phase by phase and the results.
Cloud landing zone and account vending
AWS Control Tower with Account Factory for Terraform, or Azure landing zones on Azure Verified Modules, built as code with guardrails, logging and vending.
read the case studyData center exit to AWS or Azure
Leaving a colocation or owned data center for AWS or Azure in planned waves, with dependencies mapped, licences checked and every server given an owner.
read the case studyHand-built cloud to Terraform or OpenTofu
Bringing console-built AWS, Azure and Google Cloud resources under Terraform or OpenTofu with import blocks, clean state and pipelines, without rebuilding.
read the case studyKubernetes, EKS and OpenShift version upgrades
Keeping EKS, AKS and OpenShift clusters on supported Kubernetes minors, and dealing with deprecated APIs, add-ons and node pools before each upgrade.
read the case studyVMware exit after the Broadcom licensing changes
Planning a VMware exit now that Broadcom sells only VCF and VVF subscriptions, to OpenShift Virtualization, Azure VMware Solution or native cloud.
read the case studyWindows Server 2016 and SQL Server 2016 end of support
SQL Server 2016 left extended support in July 2026 and Windows Server 2016 follows in January 2027. We upgrade, migrate or buy ESUs, server by server.
read the case studyRisks that keep coming up
One risk from each of these moves, and the case study that shows how we handled it when it hit.
-
Guardrails that block real work ↗
Switch a deny policy on without an audit period and deployments break. Each control runs in audit mode against existing accounts first.
-
Hidden dependencies ↗
Licence servers, file shares, mainframe links and partner SFTP endpoints break quietly after cut-over. Flow data plus owner interviews catch most of them before the wave, not after.
-
Import that quietly changes resources ↗
One wrong default in a generated config and the first apply replaces your database. That's why each import finishes with a zero-change plan that a person reads.
-
Removed APIs in old charts ↗
Charts pinned years ago will break on install once an API is removed. That's why the scan covers every repo, plus the live objects in the cluster.
-
Tooling that assumes vCenter ↗
Backup agents, monitoring, DR orchestration and provisioning scripts often call vCenter APIs. Each one needs a replacement on the new platform before its VMs move.
-
ESUs used as a plan instead of a bridge ↗
ESUs cover critical security fixes only, for three years at most. Buy them without an end date and teams tend to keep renewing until the last year.
Platforms and services across these moves
Ordered by how often they appear in this area's case studies.
01Should we use Control Tower or build our own on AWS?
Usually Control Tower with Account Factory for Terraform. AWS keeps the core controls maintained and AFT gives you GitOps vending. A custom build only earns its keep when you need controls or account structures that Control Tower can't express.
02AWS or Azure?
That depends on where your licences, identity and skills already are. A big Microsoft estate with Entra ID and SQL Server often lands more cheaply in Azure. Teams with AWS skills, or mostly Linux workloads, often prefer AWS. We price both against your real inventory, and some clients end up using both.
03Terraform or OpenTofu?
It depends on your legal team's view of the Business Source License and whether you rely on HCP Terraform or the newest Terraform-only features. Most code moves between them with small changes. We review your usage and tooling before recommending either.
04Can we skip minors on EKS?
No. An EKS control plane moves one minor per upgrade. Nodes are allowed to lag by up to three minors, though we keep them close. Even OpenShift EUS-to-EUS updates take the control plane through the odd minor in between.
05Should we move to OpenShift Virtualization, AVS or native cloud?
Usually a mix. AVS is fastest because VMs move without conversion, but you still pay for VCF through Broadcom. OpenShift Virtualization suits teams that already run Kubernetes and want one platform. Native cloud fits workloads that can be resized or moved to managed services. We decide per workload, not per estate.
More case studies by area
The same approach, applied to other parts of the estate.
f80afa3a - 01Microsoft Learn: Azure Blueprints overview and retirementlearn.microsoft.com ↗
- 02GitHub: terraform-azurerm-caf-enterprise-scale (archived 15 Sep 2026)github.com ↗
- 03AWS: Account Factory for Terraform overviewdocs.aws.amazon.com ↗
- 04VMware blog: End of availability of perpetual licensing and SaaS services (22 Jan 2024)blogs.vmware.com ↗
- 05Microsoft Lifecycle: SQL Server 2016learn.microsoft.com ↗
- 06Microsoft Lifecycle: Windows Server 2016learn.microsoft.com ↗
- 07AWS Transformaws.amazon.com ↗
- 08GitHub: Terraform v1.16.0 releasegithub.com ↗
Facing one of these moves?
Tell us what you're on now and where you need to be. We'll come back with how we'd run the move.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it