Squarespace has a simple belief: anyone with an idea should have the tools to build something remarkable. Great design is their competitive edge—and they put that power in the hands of millions of businesses and entrepreneurs. From websites and storefronts to finance tools and marketing analytics, Squarespace delivers an all-in-one framework for launching and growing a modern business without barriers or complexity
Behind the Squarespace experience is an engineering organization moving just as fast as the customers they serve. Maintaining that level of “wow” means equipping teams with modern tooling that enables true invention, rapid iteration, and timely delivery. That pace is made possible by Tyson, their internal developer framework built on Spring Boot, which streamlines day-to-day development and delivery for engineering teams.
Read on to learn how Squarespace is using Moderne to streamline ongoing Tyson and Spring Boot updates, ensuring developers always have access to the most modern, secure, and performant foundation to build on.
Meet the Squarespace platform team and Tyson
Squarespace’s API & Service Frameworks team owns Tyson, the internal Spring Boot-based framework that underpins the company’s backend. Tyson gives engineering teams a consistent, fully equipped foundation for building and running services—removing boilerplate work, standardizing best practices, and accelerating delivery across more than 200 Java services.
At its core, Tyson is a custom Spring Boot wrapper with internal libraries and Gradle plugins that give every service automatic access to the capabilities developers would otherwise need to piece together manually. This includes wiring into observability, logging, configuration, security defaults, dependency management through an enforced BOM, and JVM tuning guidance—all built in, all maintained centrally.
By eliminating setup friction and providing “the front door to infrastructure,” Tyson ensures that teams never have to reinvent the wheel. Developers start with a fully configured, production-ready baseline that reflects Squarespace’s operational standards. This dramatically reduces overhead, keeps services aligned, and lets teams focus on delivering product features instead of maintaining framework glue
Edie Beer, Engineering Manager at Squarespace who oversees the API and Service Frameworks team, said “What we're really providing to folks is removing the boilerplate. There's so much everybody has to do to get going, and the more that we are able to cut out the overhead, teams can spend more time actually delivering features.”
The platform team continuously evolves Tyson—adding new capabilities, modernizing frameworks, and resolving edge cases. Their work allows Squarespace engineering to move faster, adopt new frameworks earlier, and stay ahead of security issues. But every improvement still needs to make its way into the hundreds of services that depend on Tyson—and that’s where the real upgrade challenge begins.
The bottleneck: Manual Tyson and Spring Boot upgrades across 200+ services
As Tyson grew, it became central to the developer experience and increasingly difficult to keep current. Every Tyson version bump set off a chain of required changes across more than 200 services. Some were simple. Many were not. Teams had to update code, dependencies, configurations, JVM settings, and service-specific edge cases. And despite the platform team’s best efforts, much of that work remained manual.
They tried to make upgrades easier: internal linting caught predictable issues, automated PRs pointed teams in the right direction, and OpenRewrite helped automate parts of the transformation work. But the limits showed up quickly. OpenRewrite could only handle slices of a Tyson or Spring Boot migration. Running full transformations across hundreds of repositories required more compute than Squarespace’s internal tooling could support.
This left developers facing long checklists and upgrade workflows filled with interpretation. Kehong You, a Senior Engineer on Beer’s team, focused on upgrades, migrations and integration work explained: “We have internal tooling that can push out upgrade PRs, but those PRs only contain two line changes—the version properties themselves. For a full upgrade, teams always need to make more changes than that. So we provide migration guides and ask teams to follow them to finish the migration themselves.”
The manual work that still needed to be completed could include:
- code rewrites
- dependency updates
- configuration changes
- JVM tuning
- service-specific edge cases
Developers described the work as painful because it derailed feature development and forced context switching at the worst possible times. Missing even a single step had immediate consequences: broken builds, instability, and incident risks.
Beer captured the cycle clearly: “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.”
“When we saw the [Moderne] demo, the team looked at me and said, ‘Now? Can we have it now?’ It was exactly what we needed.”
— Edie Beer, Engineering Manager, Squarespace
Transforming Tyson: Predictable, streamlined migration with Moderne
Once Squarespace adopted Moderne, the modernization process shifted almost immediately. Their multi-step, high-friction undertaking was transformed into something predictable and scalable. The platform team began translating Tyson’s upgrade logic, which had historically been scattered across migration guides, tribal knowledge, internal checks, and repeated one-off fixes, into automated, organization-wide recipes.
These were not simple scripts. For major Tyson and Spring Boot jumps, the composite recipes included more than 3,471 transformation rules. Moderne's Spring Boot 3.3 migration recipe alone handled nearly 3,000 of those transformations, providing the comprehensive foundation for the upgrade. The team then bundled in 48 additional recipes to handle everything from Tyson-specific conventions to Gradle updates, configuration shifts, and prerequisite steps. While these recipes can be written with OpenRewrite, executing and testing them at scale required the Moderne Platform to centralize, orchestrate, and validate the work consistently and fast.
Kehong, who had been part of the original OpenRewrite experimentation, described how Moderne allowed them to scale automation far beyond what their internal tooling could handle:
“We are able to create Tyson recipes to do upgrades. It is essentially a composite recipe with the Moderne Spring Boot recipes along with all of our internal stuff.”
— Kehong You, Senior Engineer, Squarespace
For the first time, the team could map each step of their migration guides to an automated transformation. When a major Tyson upgrade required adding a DSL or restructuring a config file, they wrote custom imperative recipes to handle those prerequisites. These were steps that once required repeated manual effort across dozens or sometimes hundreds of services.
But the shift wasn’t just technical. It was cultural and operational.
Building confidence with new self-service upgrades
Before Moderne, the platform team pushed Tyson and Spring Boot upgrades out to service owners and hoped teams had the time, context, and focus to work through them. The reality was far more complex. Teams were juggling competing priorities, upgrade checklists were long, and every missed step carried risk. Even small version bumps felt fragile.
With Moderne, the workflow flipped. Instead of pushing changes outward and disrupting teams, the platform group simply published upgrade recipes in the Moderne Platform—and service owners pulled them when they were ready. Each team ran the recipe, reviewed clean automated diffs, and merged with confidence. What had once been a high-coordination effort became a fully automated process, driven by deterministic recipes. The process fit naturally into existing engineering rhythms, removed guesswork, and eliminated the friction that had slowed upgrades for years.
And importantly, it restored confidence across the organization.
Developers trusted that the right transformations were being applied every time. They no longer had to dig through migration guides or wonder what they might be missing. The platform team stopped chasing slow adopters or repeating the same troubleshooting steps service by service. And leadership had the visibility they were looking for.
That visibility was transformative. Previously, when leaders wanted to know how specific domains were progressing, the platform team had to collect that information manually from hundreds of repositories.
“I would previously get from different leaders, ‘How is Commerce doing? How is Resellers doing?’ and I would have to figure it out manually. Now I can say, go look at the DevCenter.”
— Edie Beer, Engineering Manager, Squarespace
With the Moderne DevCenter, leaders could instantly see which services were up to date, which were within the three-version support window, how adoption was trending across business domains, and where bottlenecks existed. Modernization stopped being a dreaded project and became a routine activity. It became part of the company’s operating rhythm.
Developers gained clarity. The platform team gained leverage. Leadership gained real-time insight. And for the first time, keeping Tyson up to date felt not only possible, but sustainable.
Migration results: Faster modernization and dramatically reduced effort
The results were immediate and surpassed expectations. With more than 200 services and approximately 520 developers relying on Tyson, the scale of the challenge was significant. The team had set conservative adoption goals given the complexity of the multi-version jump from Spring Boot 2.x to Spring Boot 3.3, combined with major Tyson framework changes.
Moderne automated 50 to 60 percent of the migration steps required for major Tyson upgrades, and 60 to 70 percent for minor version bumps. “I think our estimates, when we looked at what it would take to do manually versus automated, we're cutting it in half or more,” Beer says.
The time savings were substantial and measurable. Across the Tyson migration, Squarespace saved an estimated 66,357 minutes—approximately 1,106 developer hours—that would have otherwise been spent on manual upgrade work. For a small platform team supporting over 500 developers, that’s the equivalent of freeing up more than half a developer for an entire year, or giving every service team back critical capacity to focus on feature development instead of framework maintenance.
The platform team now maintains a majority of services within Tyson's three-version support window—a milestone they had never previously achieved. Multi-year upgrade cycles are collapsing toward single-year timelines or less.
The developer response was immediate and enthusiastic, according to Beer:
“It was day two that this was out, and we had people in our Slack channel going, ‘This is sick.’”
The contrast with previous upgrade experiences was stark: no more complaints about 20-step manual processes, no more confusion about what needed to be done. Kehong emphasized the technical execution: “Everything was very smooth. Everything worked really fast. The recipes executed quickly.”
The success drove immediate expansion beyond the original scope. What began as a Tyson-specific initiative has grown to encompass all Java services at Squarespace, including approximately 50 vanilla Java services that don't use the Tyson framework. Leadership's reaction captured the momentum: asking how Moderne "can be used for everything."
Beer summed up the transformation perfectly:
“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.”
A long-term modernization engine for Squarespace
With a reliable modernization engine finally in place, Squarespace is naturally beginning to widen its use of Moderne beyond Tyson. The platform team is already accelerating upgrades across all Java services, smoothing out Gradle improvements, and standardizing JVM image updates. And because the early wins have built confidence across engineering, teams are starting to explore what modernization could look like in JavaScript and TypeScript. The work no longer feels like a heavy lift. It feels possible.
This shift is also changing the energy around upgrades themselves. Engineers who once dreaded version bumps are now genuinely looking forward to moving toward Java 17 and Java 21, and they are excited about what upcoming Spring Boot releases will unlock. What used to be weeks of manual cleanup and risk assessment has become a clean, automated workflow that fits naturally into how the organization already builds software. Teams can stay current with confidence and spend their time where they want to be: shipping new features, improving the platform, and pushing the product forward.
Want to learn more about how Moderne can assist with your code migrations (and so much more):
- Sign up for Preparing for Your Next Spring Boot Migration training.
- Check out our Spring Boot 4.0 migration guide.
- Contact us for a Moderne demo.
