The Situation

Board mandate to cut infrastructure costs. But how?

A mid-Atlantic insurance carrier with 2,200 employees was running almost entirely on-premises. Aging data centers, hardware contracts expiring, no cloud operating model in place, and the board had set an aggressive target: reduce infrastructure costs by 30% in three years.

What we found in the current state

The client had invested heavily in on-premises infrastructure but faced rising operational costs, aging equipment, and limited scalability. No unified view of total cost of ownership, and IT leaders disagreed on whether cloud would actually save money or just shift costs.

  • Infrastructure footprint. Three aging data centers across the region, each with separate teams and tools.
  • Cost visibility. IT spent 60% of budget on infrastructure operations, but no detailed chargeback model.
  • Licensing spread. VMware, SQL Server, and storage licenses scattered across teams with no optimization.
  • Staffing burden. 45 FTE dedicated to infrastructure maintenance, with recruitment pressure for cloud skills.
  • No cloud strategy. Pockets of AWS and Azure use in departments, but no enterprise-wide architecture.
How We Built the Strategy

Eight weeks of structured discovery and modeling

01
Infrastructure Inventory & TCO Baseline
Comprehensive scan of all systems, applications, and dependencies across three data centers. Built a detailed TCO model for the current state, factoring in personnel, licensing, facilities, and hardware refresh cycles.
Week 1-2Assessment
02
Workload Classification & Cloud Fit Analysis
Evaluated 180+ workloads against a cloud-readiness matrix: cloud-native (microservices, greenfield), lift-and-shift (rehost to VM), refactor-and-move (moderate rework), and stay-on-premises (compliance, performance). Applied financial impact for each category.
Week 2-3Analysis
03
Cloud Operating Model Design
Designed governance, security, cost management (FinOps), and organizational structure for cloud. Addressed identity, compliance, networking, and cost allocation. Defined roles, approval workflows, and tagging standards.
Week 3-5Strategy
04
Provider Selection & Recommendation
Evaluated AWS, Azure, and GCP against security, cost, existing tool integrations, and capability maturity. AWS selected as primary for compute and data; Azure recommended for M365 integration and identity consistency.
Week 5Evaluation
05
3-Year Roadmap & Financial Model
Phased migration plan with wave timing, resource requirements, and detailed cost projections. Conservative assumptions on savings, effort, and risk. Included contingency for workload discovery and technical challenges.
Week 6-8Roadmap
What We Delivered

The numbers that made the board commit

$4.2M
Projected 3-year savings
vs. continuing on-premises baseline. Conservative modeling with 18-month payoff for migration investment. Includes personnel redeployment, license optimization, and infrastructure elimination.
65%
Workloads cloud-ready
In first wave (Year 1). Remaining 25% deferred to Year 2-3 pending rearchitecture. 10% recommended to stay on-premises for regulatory and performance reasons.
45 FTE
Infrastructure team redeployment
From data center maintenance to cloud operations, modernization, and application development. Upskilling plan included AWS and Azure certifications for 30 team members.
Why It Worked

Clear trade-offs, owned by leadership

The strategy was actionable because it was grounded in real infrastructure data, not cloud vendor promises. The board approved the roadmap without pushback because the financial model was conservative and the phasing reduced execution risk.

Credibility came from detailed workload analysis

Rather than a top-down "move everything to cloud," we classified each workload individually. That meant some systems stayed on-premises. The board appreciated the honesty, and teams were more willing to commit because their specific systems had been analyzed, not just guessed at.

  • Workload-specific TCO. Each migration path (rehost, refactor, retire) had its own cost model and timeline.
  • Operating model first. Before moving a single workload, governance, security, and cost control were designed to scale.
  • Team alignment. CIO, CFO, and business unit leaders all reviewed and approved the strategy in parallel.
  • Phased execution. Waves were sized to allow learning and adjustment without high-stakes all-or-nothing risk.
  • Build vs. buy clarity. We recommended existing tools (Terraform, AWS Config) for infrastructure and cost automation, reducing custom development.
Technology Stack

Tools chosen for scale and cost control

AWS
Primary cloud platform for compute, data, and analytics workloads. EC2, RDS, S3, Lambda for core services.
Azure
Secondary for M365 integration, identity (Azure AD), and workloads with strong Windows/SQL Server dependencies.
Terraform
Infrastructure as code for reproducible, auditable cloud deployments. GitOps workflow for change management.
Cloud Operating Model
Custom governance framework with tagging standards, cost allocation, and security baseline configurations.
Start a conversation

Tell us what's worth doing.

// 30 minutes โ†’ a written brief.

Bring the problem. We'll come back with a written brief: what to build, what to defer, and where AI actually moves the number. No deck pitches.

Emailconnect@ingressits.com
GSA MAS#47QTCA26D000K
Reply< 24 hrs