How Wise Spent Five Years Migrating a Monolith — and What a Faster Path Looks Like

Wise built a smart monolith. It worked perfectly — until it didn't. The five-year migration that followed was painful and expensive. Here is what a different approach could have looked like.

Wise did not set out to build a legacy system. Nobody does.

In the early days, a Groovy and Grails monolith was the right call. It was flexible, fast to build on, and well suited to a small team moving quickly. When you are trying to disrupt international money transfers, you do not optimize for the architecture you will need at ten million users. You optimize for the architecture you need today.

The problem is that today's right decision becomes tomorrow's constraint. And when it does, the cost of changing it is proportional to how much you built on top of it.

When does a monolith architecture stop working for growing companies?

A monolith stops working when team coordination costs exceed development velocity gains. This happens when deployments require cross-team synchronization, when scaling one feature requires scaling the entire application, when build times exceed 30 minutes, or when a single bug can bring down unrelated features.

Wise grew fast. Millions of users. Hundreds of engineers. Multi-region infrastructure. Payment corridors across dozens of currencies. Each new capability added weight to a system that was never designed to carry it.

The symptoms were familiar to anyone who has worked inside a scaling monolith. Deployments became dangerous. A change in one part of the system broke something in a part nobody expected. Build times stretched. The codebase became harder to navigate. New engineers took months to become productive because understanding any one piece required understanding all the other pieces it touched.

Wise eventually made the decision to migrate to microservices. It was the right decision. The execution took years, required significant engineering resources, and carried real risk throughout. Not because the engineers were not good. Because migrating a monolith at scale, while continuing to run the business on it, is genuinely hard.

What is the knowledge problem in monolith migration?

The knowledge problem is the challenge of understanding how thousands of code dependencies interact across a large codebase without documentation. Engineers must manually trace connections between modules, predict breaking changes, and identify safe service boundaries - a process that traditionally takes years and requires dedicated teams to map.

The hardest part of migrating a monolith is not the new architecture. It is understanding what the old one actually does.

In a system that has been evolving for years, business logic accumulates in ways that are rarely documented. A rule gets encoded in a stored procedure. An edge case gets handled in a conditional that nobody remembers adding. A calculation that looks simple turns out to depend on a value set three layers up in the call stack. None of this is in the design documents, because by the time anyone thought to write design documents, the codebase had already moved on.

When you extract a service from a monolith without fully understanding all the behavior it encodes, you introduce risk. The new service does most of what the old code did. Most is not enough when you are moving money across borders for millions of people.

This is why monolith migrations take years. Not because microservices are complicated to build. Because understanding what needs to be preserved is slow, careful, human work. Or it was, until recently.

How does AI change the economics of monolith migration?

AI transforms migration economics by automating dependency analysis that previously took years of manual work. It maps entire codebases in weeks, identifies optimal service boundaries through pattern recognition, predicts breaking changes before deployment, and reduces the team size needed from dozens to a small squad.

The analysis phase of a migration, the work of understanding what a legacy codebase actually does before you touch it, has historically been the slowest and most expensive part of the process. A team of senior engineers mapping a large codebase manually takes months. The findings are incomplete. The documentation is out of date before it is finished.

AI changes this. Not by replacing the judgment required to make architectural decisions, but by compressing the time it takes to develop the understanding those decisions need to be based on. A codebase that would take a team three months to map manually can be analyzed in days. Dependency graphs, implicit business rules, undocumented behavior, coupling between modules — all of it surfaced and organized before a single line of new code is written.

For a migration like Wise's, this matters enormously. The bottleneck was not writing new microservices. It was understanding the monolith well enough to extract them safely. Remove that bottleneck and the timeline compresses. Not to weeks, but from years to months. With significantly less risk, because the decisions are based on a more complete picture of what the system actually does.

What approach reduces risk in monolith migration?

The risk-reducing approach starts with AI-powered complete codebase analysis before any migration begins. It identifies cleanly bounded services for incremental extraction, validates each change against the full dependency graph, enables parallel feature development during migration, and allows rollback at any point without system-wide impact.

Understanding the system is the first step. The second is moving carefully.

Incremental extraction, one service at a time, with the monolith continuing to run alongside the new services, is slower than a big-bang rewrite on paper. In practice it is faster, because you catch problems at the module level rather than at the system level. A bug in one extracted service does not take down the whole platform. A rollback affects one capability, not everything.

Characterization tests, generated before any extraction begins, lock the existing behavior of each module. The new service must pass those tests before it replaces the old code. This gives engineering teams confidence that what they built does what the original did, including the edge cases nobody remembered to document.

This is not a theoretical approach. It is how large legacy systems get modernized safely, at speed, without stopping the business that runs on them.

Wise got there eventually. The path was longer and harder than it needed to be. Not because of any failure of engineering or leadership. Because the tools that make this kind of migration faster and safer did not exist at the scale required when they started. They do now.