From monthly releases to daily ones at State Auto
State Auto wanted to operate like a technology company, not a traditional insurer. We rebuilt how their flagship application got to production and coached their team to run it without us.
wrangled from hand-rolled to fully automated environments.
State Auto Insurance (now part of Liberty Mutual)
A technology company that happened to sell insurance
State Auto, now part of Liberty Mutual, described itself as a 21st-century technology and transformation company rather than a traditional insurer, and they meant it. The company was nearly a century old, headquartered in Columbus, and writing billions in premiums across more than thirty states, so it had every excuse to move slowly. It didn’t want to. The Infrastructure and Operations team had already bought into DevOps in principle. What they wanted was to actually live it day to day.
They came to us because they wanted to move faster than their current setup allowed, not because anyone was forcing a migration on them. That difference matters more than almost anything else on a project. In our experience it tends to separate the work that sticks from the work that gets quietly abandoned a year later.
The bottleneck was bandwidth, not ambition
State Auto knew where they wanted to go. What they were short on was the room to get there. Cloud and DevOps talent was hard to hire, and the people they did have were busy keeping the existing system running.
The strain showed in their flagship Portal application. Releases went out on a cadence measured in months. Work sat in large branches for weeks or months before being merged and properly tested, so bugs surfaced late and took a long time to trace. Environments were cloned by hand and drifted out of sync, and deployments were ad-hoc scripts that altered live application servers in place. That is not a knock on their engineers. It is simply where a team ends up when every spare hour goes to keeping the lights on and none is left for changing how the work itself gets done. It is also a hard place to lead from when the whole strategy is to outpace your competitors.
What we actually did
We started the way we usually do, with a couple of weeks on-site, sitting with their I&O, app dev, and QA people to learn how code actually moved through the company before recommending that any of it change. Together we picked the Portal Rewrite as the pilot, since it was their highest-value application and proving the approach there would carry weight internally.
One of our first recommendations was also one of the least exciting: start in a brand-new AWS account instead of retrofitting the existing ones. Building on what is already there is always tempting, but a clean account let us apply good practices from the start rather than fight years of accumulated configuration, and it kept the blast radius small while the team was still learning. Calls like that are most of what the early work really consists of.
From there we rebuilt the path to production alongside their engineers:
- Git in place of Subversion, with a branching model suited to small, frequent merges rather than months-long ones.
- Infrastructure as code with CloudFormation, so environments became consistent and repeatable instead of hand-cloned and drifting.
- A Jenkins CI/CD pipeline with automated build and test, which replaced the ad-hoc deploy scripts and in-place server edits with tested, repeatable, immutable deployments.
- Ansible, Packer, and Docker to standardize configuration and turn out known-good, bootable artifacts.
- A custom interface on top of AWS Service Catalog that we wrote, so their teams could launch and manage environments with a button and never touch the underlying templates.
We worked through all of this next to their people rather than off in a corner. Knowledge transfer wasn’t a phase tacked on at the end; it ran through the whole engagement. When the project wrapped, State Auto asked us to extend it by a week, not to build anything more but to spend the extra time coaching, so their team would be fully comfortable running everything on their own. We took that request as the best sign we could have gotten.
What changed
The Portal team went from releasing in months to releasing in days. Work moved in small, continuously tested increments instead of giant branches that hid their bugs until late in the cycle. Environments that had been assembled by hand were defined in code and launched on demand. And because the whole thing had been built with their engineers rather than handed to them, the practices spread to other teams on their own, which was how we knew it had actually taken hold.
State Auto didn’t come out of the engagement depending on us. They came out of it able to keep going without us, which is what a project going well looks like to us.
Stack
Git · AWS CloudFormation · Jenkins · Ansible · Packer · Docker · AWS Service Catalog