State Farm’s ROSA migration traded a platform deadline for a product model

State Farm moved 1,500 workloads from Pivotal Cloud Foundry and VMware vSphere to Red Hat OpenShift Service on AWS in 10 months, according to a Red Hat account of the insurer’s Red Hat Summit 2026 presentation. The headline number is large, but the more reusable lesson is organizational: the team treated its application platform as a product, standardized the infrastructure it could standardize and pushed migration control closer to business units.

What changed

The migration began with a hard contract deadline and a portfolio that included older frameworks and internal systems using traditional HTTP clients. Red Hat says only 10% to 20% of the insurer’s software engineers had the infrastructure knowledge needed to manage AWS security groups, identity and access management, and related cloud plumbing.

The response was not to teach every application team the full infrastructure stack. State Farm built repeatable ROSA cluster blueprints that applied corporate compliance settings, network topology and baseline security during automated builds. It then gave dedicated clusters and cluster-administrator rights to enablement teams within business units, allowing those groups to sequence migrations and install required OpenShift operators without waiting on a central platform queue.

That distributed model was a deadline tactic, not necessarily the final architecture. Red Hat says the insurer’s roadmap now includes Red Hat Advanced Cluster Management and a shift toward a centralized shared-cluster fleet for more uniform governance.

Hosted control planes changed the economics

After the initial migration path was running, State Farm rebuilt 32 clusters on ROSA with hosted control planes. The company reported moving those clusters in four weeks without disrupting active services. According to the Red Hat post, the change reduced cluster build time from 75 minutes to 24 minutes—a 68% reduction—and cut costs by 30% compared with the classic architecture.

The same platform also supported a disaster-recovery exercise in which a GitOps traffic-routing design failed over 32 clusters in under four hours. Those figures are vendor-published customer results rather than independent benchmarks, but they identify the operational properties teams should measure in their own migrations: provisioning time, control-plane cost, recovery time and the amount of work held in a central queue.

What platform teams should take from it

A fixed migration deadline can justify temporary decentralization, but every delegated administrator and business-unit cluster creates a governance obligation. Standard blueprints need versioning, upgrade ownership and controls that prevent local changes from silently diverging from the baseline.

Teams considering the same path should inventory workload dependencies first, define the minimum compliant cluster blueprint and decide which operators local teams may install. They should also plan the consolidation phase before migration pressure subsides: determine which workloads truly require dedicated clusters, how GitOps will enforce common configuration and whether hosted control planes change account, network or incident-response assumptions.

The migration’s strongest point is not that a managed service removes platform engineering. It shows where that engineering can move—from repeated cluster plumbing toward maintained blueprints, paved migration paths and measurable recovery behavior.