Squarespace cut a four-year Spring Boot upgrade to under a year.
Squarespace upgraded more than 200 backend services from Spring Boot 2.x to 3.3 in under a year with Moderne, compared with four years for its previous Spring Boot upgrade.
- Technology
- Industry
- 520
- Developers
- Java, Spring Boot, Gradle, and Tyson (an internal Spring Boot framework)
- Tech stack
Squarespace services now sit inside Tyson’s three-version support window for the first time.
Squarespace services run on Tyson, an internal framework built on Spring Boot. Instead of migrating every service itself, the platform team turned Tyson’s migration guidance into recipes that service teams run on their own.
The savings continued after the migration ended. In the eleven months that followed, with no large upgrade running, ordinary maintenance accounted for a further 3,000 developer hours across thousands of commits.
- The migration saved more than 1,100 developer hours, for a platform team supporting 520 developers.
- Moderne automated 50 to 60 percent of the steps in major Tyson and Spring Boot upgrades, and 60 to 70 percent in minor version bumps, cutting manual effort at least in half.
- The migration executed 3,741 transformation rules.
- DevCenter, Moderne’s dashboard for tracking migration progress across repositories, gave leadership the real-time view of adoption it had been asking for, so no one had to chase teams for status updates.
We have almost tripled our goal. This is our most ambitious change ever, and it is tracking like one of our minor upgrades. That is phenomenal.
Squarespace built one recipe from public upgrades and its own framework rules.
The platform team turned Tyson’s manual migration guides into a composite recipe. Engineers had been following those guides by hand, service by service, and no public recipe could replace them, because Tyson’s rules exist nowhere else.
The Tyson recipe combines Moderne’s Spring Boot recipe, which already has thousands of steps, with Tyson-specific rules and the Gradle and configuration changes that used to be applied one service at a time. The public catalog handles the part of the upgrade that is the same everywhere, and the Tyson rules handle the rest.
Because the Tyson rules now live in a recipe, a coding agent can apply them through Moderne without understanding Tyson.
Service teams ran the recipe through Moderne, which handled the execution, testing and validation across hundreds of repositories, work that had outgrown Squarespace’s internal tooling. Teams then reviewed the diffs and merged.
The same approach now covers Java, Gradle and JVM image improvements.
When we saw the demo, the team looked at me and said, ‘Now? Can we have it now?’ It was exactly what we needed.
A Tyson release no longer means coordinating the same changes across more than 200 services.
Tyson standardizes the patterns and safeguards Squarespace’s teams use to ship services, and every Tyson release carries a Spring Boot upgrade inside it. Each one meant repeated dependency updates, API refactoring and Gradle configuration changes across the whole service portfolio, and the coordination grew as the organization grew. Adoption of new Java and Spring Boot capabilities slowed, feature delivery suffered, and services drifted apart on versions, with no clear view for leadership of where any of it stood.
Teams now pick up each release by running a recipe, and the steps that used to get missed are built into it.
We would push out an update, and people would get a red PR. Then someone would miss a step, cause an incident, and everything slowed down. We needed a better solution and explored our options; nothing hit the mark until Moderne.
Related resources
See deterministic, estate-wide code change on your own repositories.