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 the monolith stopped working

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.

The knowledge problem at the center of every monolith migration

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.

What AI changes about the economics

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.

The approach that reduces risk

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.