CASE STUDY 03 / CLOUD & DEVOPS · SOFTWARE ENGINEERING · SECOPS
Moving to Azure
without downtime.
A major Western U.S. building-materials producer with systems tracking hundreds of trucks.
CUTOVER READINESS / THREE CONNECTED DEPENDENCIES
Known infrastructure state
Application behavior addressed
Deployment testing & canaries
AWS → GitOps-led preparation → Azure cutover
Editorial illustration of the reported approach—not a recovered client architecture.
ENGAGEMENT FOCUS
AWS → Azure migration
GitOps & application changes
Release engineering & testing
Continuing security readiness
THE OBJECTIVE
Align the platform with an existing Microsoft environment and commercial agreements, while making the application easier to deploy.
THE CHALLENGE
A cloud move with operational constraints.
The Kubernetes platform on AWS was managed manually and imperatively, leaving its overall state difficult to understand. The business wanted to move to Azure, but infrastructure was only part of the problem.
Environment-specific database values, an old externally hosted database, and application startup and shutdown behavior complicated instance changes. The platform and the application both needed preparation.
Make the platform ready for change.
Capture a known state
The team converted the existing AWS environment to GitOps first, then operated it and documented behavior changes there before preparing the Azure cutover.
Address application behavior
The team addressed database-stored environment assumptions, connection behavior, and startup, shutdown, cleanup, and pruning problems. The external database itself was not replaced.
Practice the deployment
Stronger end-to-end testing and a QA-testable CI/CD pipeline supported staging previews, ephemeral environments, and canary deployments before the move.
DELIVERY & COLLABORATION
Across application and operations boundaries.
Approximately three months of development were followed by about a month preparing cutover and a couple of weeks of monitoring. Extensive deployment testing supported the team’s confidence in the move.
The delivery team handled GitOps conversion, application and configuration changes, release engineering, testing, migration, and initial monitoring. The client owned the existing product organization and operating context; the old database remained with its external provider.
CONTINUING SECOPS
Readiness, remediation, and ongoing operations.
The relationship continued beyond migration. Vanta setup, integrations, assessment, documented findings, and mitigation work supported SOC 2 Type I readiness. That implementation and evidence work is distinct from independent attestation; report completion is not established.
HolmesGPT was used in canary version-upgrade workflows supporting updates and security patching. The interview also described overnight job incidents repaired before manual DevOps intervention—a qualitative operational observation, not a measured recovery-time or security-incident result.
A new destination. A different release cadence.
0 reported downtime
The AWS-to-Azure cutover had no perceived interruption outside engineering, according to the interview.
Quarterly → weekly
From approximately once per quarter to multiple deployments per week after the delivery improvements.
Known platform state
GitOps, application changes, and deployment testing made the platform easier to reason about and release.
Source: project interview. Zero downtime is a reported migration outcome, not an availability SLA. Release cadence is an estimate. No realized Azure cost saving or measured impact on physical deliveries was supplied.
MORE CASE STUDIES
Making fragmented research data comparable →