Scala 2 to Scala 3 Migration: Should You Do It Now? (2026)
Scala 3 officially released on May 14, 2021. It's now June 2026, five years later, and a significant portion of production Scala codebases are still running on 2.13.
That's not surprising, and it's not necessarily negligence. Large systems don't migrate because a blog post told them to. They migrate when the risk-reward calculus tips, when the team has bandwidth, and when the blockers are gone. For many teams, one or more of those conditions still hasn't been met.
This post is a look at where things stand in 2026: why teams haven't moved yet, what the real blockers are, and how to decide whether now is the right time for your codebase.
Scala 3 is the present and future of the language. Scala 2.13 still works and still gets patches, but the ecosystem has moved on. The main migration blockers are macro incompatibility, unported dependencies, and a lack of engineering bandwidth. Not technical inferiority of Scala 3 itself. If your codebase has none of those blockers, there's no strong reason to wait. If it does, audit them first, then plan a phased migration. 2026, with Scala 3.9 LTS on the horizon, is a sensible window to get it done.
Five Years In, Why Are Teams Still on Scala 2
Some teams tried early and hit walls. One engineering team documented attempting the migration in April 2024, hitting macro incompatibilities and thousands of required code changes, and abandoning it after a week. They came back in early 2025 and succeeded, but only after finding workarounds for the specific libraries blocking them.
Others simply haven't had the space to do it. A migration on a production system isn't something you run over a weekend. It competes with feature work, incident response, and hiring pressure. When Scala 2.13 is still receiving maintenance releases and your system is stable, the urgency is hard to manufacture.
And for a subset of teams, the blockers are genuinely technical: macro-heavy codebases where the path forward requires either rewriting internals or waiting for upstream library maintainers to ship Scala 3 ports.
Know which one applies to your team before you do anything else.
What’s Changed Since Scala 3 Released in 2021
The Scala 3 that exists in 2026 is not the Scala 3 that shipped five years ago. The early versions had real rough edges. Most of them are gone.
Developer tooling works now. The IDE support that frustrated early adopters has matured significantly, and the broader development environment has stabilized. Teams report fewer of the workflow interruptions that made early Scala 3 adoption feel like a tax on productivity.
The library ecosystem has largely caught up. A 2026 survey put Scala 3 adoption at 92% among active users. The major libraries your team is likely already using all have solid Scala 3 support. There are still some older or more specialized libraries that haven't fully made the transition, but they're increasingly the exception.
Build times have improved. Early Scala 3 had slower compile cycles than Scala 2, which added friction to development workflows. That gap has narrowed materially with recent tooling releases.
The long-term support picture is also clearer now. Scala has an LTS release model, and a new LTS version is expected in mid-2026. If your team needs a stable, supported foundation before committing to a migration, that foundation exists.
What Blocks Teams From Migrating
Not all migration friction is the same. Some blockers are hard stops until something upstream changes. Others are just engineering work that needs time and a clear owner. Here's how to tell the difference.
Macro Incompatibility
This is the only true hard stop. Scala 3 redesigned a core part of the language that many libraries relied on internally. If any of your key third-party libraries haven't been updated to work with Scala 3, you can't complete the migration until they are, or until you replace them.
The practical implication: before your team estimates any timeline, someone needs to audit your dependencies and confirm none of them hit this wall. Some tools do this automatically. Don't commit to a migration schedule without running that check first.
Dependencies That Haven't Caught Up
Below the hard-stop threshold, there's a longer tail of libraries that technically support Scala 3 but whose ports are incomplete or require meaningful rework on your end. Teams migrating in 2024 and 2025 consistently ran into specific libraries where the Scala 3 version was missing features, or where the migration path required swapping in a different library entirely.
None of it is a deal-breaker, but each one adds scope. A migration your team estimates at two weeks can stretch if a handful of dependencies each need their own remediation step. Reports from large codebases show that dependency cleanup, not language syntax changes, is where most of the time actually goes.
Engineering Bandwidth
For stable, mature systems, this is often the real constraint. A focused migration effort takes real engineering time, typically measured in weeks for anything beyond a small service. That time competes with product work, hiring, and everything else on the roadmap. Unlike a bug fix, there's no immediate customer value visible on the other side.
This is why migrations that don't get scheduled tend not to happen. No one makes the call that the carrying cost of staying on Scala 2 justifies pulling engineers off other work. That's a leadership decision, not an engineering one. And for many teams, it's also a resourcing decision. If the internal capacity isn't there, the work doesn't have to wait for it to appear. Scala Teams works with engineering organizations on exactly this kind of engagement, bringing in experienced Scala developers to run the migration while your core team stays focused on product.
You Don't Have to Migrate Everything at Once
Scala 2 and Scala 3 can coexist in the same system during a migration. You can move services one at a time, keeping Scala 2 components in place while the rest of the codebase catches up. This makes the migration much more manageable for teams running multiple services, because you're not betting the whole system on a single cutover. It's harder if your codebase is a single large monorepo with deep internal dependencies, but for most architectures the incremental path is real.
Migrating to Scala 3 in 2026
The strongest argument for moving in 2026 is that the cost of staying on Scala 2 compounds over time.
Library authors are not going to keep publishing Scala 2 artifacts indefinitely. The active development energy in the ecosystem is on Scala 3. When a new library ships, or an existing library adds features, those changes go to Scala 3 first. Staying on Scala 2 increasingly means staying on older versions of your dependencies.
Hiring also factors in. Engineers entering the Scala ecosystem today are learning Scala 3. If your codebase is on Scala 2, you're asking new team members to work in a version of the language they didn't learn, and you're narrowing the pool of developers who feel comfortable contributing quickly.
Then there's Scala 3's actual language improvements. The new type system gives you stronger type inference and cleaner code. Extension methods replace implicit conversions in a way that's far easier to read and reason about. Union and intersection types open up patterns that were awkward or impossible in Scala 2. Given statements clean up the implicit system. These aren't cosmetic changes. They reduce the cognitive overhead of reading and maintaining Scala code.
And Scala 3's compatibility story within the 3.x line is genuinely better than Scala 2's was. Minor version upgrades are source-compatible, and the TASTy format ensures library compatibility across Scala 3 releases. The churn that characterized moving between Scala 2.11, 2.12, and 2.13 is not present in the Scala 3 release cadence.
When to Wait
There are legitimate reasons to hold off, and they deserve honest acknowledgment.
If you have macro-heavy internal libraries with no clear porting path, migrating now means taking on rewrite work that may be larger than the migration itself. It's worth auditing whether a third-party library (chimney, neotype, and others) already covers your use case before committing to a macro rewrite.
If a critical dependency still doesn't have a Scala 3 release, waiting for that upstream work to land is pragmatic. Watch the library's GitHub and subscribe to release notifications. Some libraries are close but have shipped incomplete ports. Check feature parity, not just version availability.
If your system is in a stability-critical phase (a major launch, an audit period, an acquisition integration), defer migration until the window opens. Adding compiler-level changes to an already-stressed codebase introduces unnecessary risk.
What's not a reason to wait: familiarity with Scala 2 syntax, general migration anxiety, or "it's working fine." Those are natural feelings, but they're not arguments. Every year on Scala 2 is another year of compounding ecosystem drift.
How to Approach the Migration
Your engineers have probably already looked at this. Maybe someone opened the migration guide, scanned the dependency list, and quietly closed the tab. That's normal. It's hard to know where to start when everything touches everything else.
The good news is that teams who've done this recently have documented it well. The failure modes are known, the tooling is real, and the sequence matters more than the speed. If you'd rather have someone run point on it who's done it before, that's also an option. Scala Teams brings in experienced Scala developers to handle the migration while your core team stays focused on product work.
Step One: Find Out What You're Actually Dealing With
Before any code changes, your team needs a clear picture of your dependency landscape. The goal is simple: identify anything in your current codebase that doesn't have a Scala 3-compatible version yet. This audit typically takes a few hours and is the single most important input to your planning. It's the difference between scoping a two-week project and a two-month one. Don't estimate the migration before you've done this.
Step Two: Fix the Dependencies Before Touching the Language Version
The most common mistake is trying to change everything at once. The right sequence is to get your dependencies sorted first, while your codebase is still running on Scala 2. Any internal libraries your team maintains should be updated to work with both versions during this phase. This keeps the migration incremental and makes it much easier to isolate problems when they come up.
Step Three: Make the Switch and Work Through the Errors
Once dependencies are in order, your engineers change the compiler version and run the test suite. Errors will surface in groups, and most of them are mechanical fixes rather than architectural changes. The practical advice from teams who've done this: don't try to modernize the codebase at the same time. Scala 3 accepts most Scala 2 syntax as-is, so there's no need to rewrite everything in one go. Get it compiling and passing tests first.
Step Four: Modernize on Your Own Schedule
Once the migration is complete, the codebase is on Scala 3 and the work is done. There's a separate and worthwhile effort to adopt Scala 3's newer language features (cleaner syntax, improved type handling, better abstractions), but that's not part of the migration. It can be scheduled, staffed, and prioritized like any other improvement work. The migration and the modernization are two different projects.
What This Means for Your Team
The question isn't whether to migrate to Scala 3. It's when, and with what preparation. If you audit your dependencies today and find no hard blockers, you can migrate on your schedule rather than being pushed into it later under less favorable conditions.
For teams managing Scala infrastructure, the migration decision also has workforce implications. Engineers who are fluent in Scala 3 patterns are increasingly what the market looks like. If your codebase is on Scala 2 and you're hiring externally or augmenting the team, consider what onboarding on a Scala 2 codebase means for a developer who hasn't worked in it.
Bandwidth is often the reason migrations stall, not a lack of willingness; just not enough people to do the work without pulling engineers off product. If that's where your team is, bringing in experienced Scala developers to run the migration is a practical option. It keeps your core team focused, and the work gets done by people who've done it before.
The ecosystem has landed. Scala 3 is no longer a new version with open questions. It is the language. The only question left for your team is the logistics of getting there.
Working through a Scala 3 migration decision?
We help engineering teams audit their Scala codebases, plan migrations, and staff the work with developers who've done it before. Talk to a Scala expert and get a clear picture of what your migration actually involves.
