I've been involved in several projects that tried to break down a legacy monolith. Some were successful, but most were not. Even those moderately successful had a common, painful experience. I burned my fingers and saw other teams struggle with this challenge. Not because they lacked skills, but often because their approach was too ambitious.

After recently discussing monolith-to-microservices migrations, I decided to let you learn from my and other people’s mistakes. And spare you some unwanted fun.

Let me share what I've seen work and learned. That’s my experience, so filter that through yours, but I hope this will be a good thought for thoughts.

Be Realistic About What Stays in the Monolith

Yes, that’s the title, and it is not a mistake. If you believe you’ll be able to rewrite everything, I’m sorry, but you’re probably wrong. I was wrong like that multiple times.

It’s anecdotal evidence, but I haven't seen a complete monolith migration succeed. Most were left in the middle of transition after going far above the planned time for rewrite.

Some finished the migration, but replaced the old legacy with the new legacy after rushing the deadline.

Some didn’t even manage those phases, as they sunk product and budget and were thrown away.

So, the safe assumption is that some part of the old system will remain and continue running.

And that's perfectly fine. The goal shouldn't be completely eliminating the monolith, but extracting the parts that benefit from independence.

Consider a video editing suite with project management, rendering pipeline, effects processing, and asset management. After extracting the performance-critical rendering pipeline and the frequently updated effects processing, you might find the core project management and stable asset management work perfectly fine in the original monolith. Keeping them there could save significant effort without compromising the migration's benefits.

When to Keep Functionality in the Monolith

Sometimes it makes sense to keep certain functionality in the monolith when:

• It rarely changes (like so authentication logic that follows well-established standards)

• It's deeply connected to other monolith components (like a complex pricing engine with many internal dependencies)

• The extraction cost exceeds the benefits (like a reporting module used by only a few internal users)

• The team lacks experience with distributed systems (like a team of domain experts who primarily work with business logic)

A financial system might benefit from extracting the high-volume transaction processing and notification services while keeping the complex compliance and audit engines in the monolith because they are computationally intensive and tightly coupled.

Focus on Business Value First

I think that when planning migrations, we should start by talking with product people to identify which parts of the system deliver the most value or cause the most pain. We should follow the money. As cynical as it may seem, finding out who’ll be paying us money is as helpful. That’s critical in selecting the right tradeoffs. Example?

Let’s say that we’re maintaining a SaaS platform like Shopify:

• Who’s our customer? A shop that’ll be paying for our subscriptions.

• Who will use our platform the most? People who will buy goods in online shops. Will they be paying us? No, our customer.

• Who should we optimise for? Our clients, so subscription payers.

We should ask ourselves questions when discussing our features:

• When will our customer be sad?

• When will our user be sad?

• Will the fact that our user is sad eventually make our customer sad?

• Will that be more disappointment, sadness or despair?

Of course, we should try to make both users and customers happy. Still, we need to fulfil the needs of our customers first, then do that for other users. That may sound cynical, but it’s not. If we don’t satisfy our paying customers, then we won’t make our work sustainable, and other users will eventually be also harmed by that.

So I suggest focusing on business value for our customers and thus the money-flow for us:

1. Pick a specific functionality that gives clear business value

2. Get it to production relatively quickly

3. Learn from that real-world experience

4. Adjust further plans based on what they learned

For example, consider a team initially planning to extract the user management component because it seems technically straightforward. However, after discussions with the business, they might discover that improving the order processing system would deliver more immediate value to customers experiencing delays. By pivoting to that area, they could show benefits much faster and build momentum for the broader migration.

This iterative approach works better than those "grand migration" plans that extend for years without delivering interim value.

Define Specific, Measurable Metrics (Not Just Goals)

Teams that succeed in migrations typically align with business stakeholders on specific, measurable metrics before starting - not just vague goals. There's a critical difference here that's often overlooked.

For instance, teams might start with business goals like:

For a game development studio, improving the player matchmaking experience

For a video streaming platform like Netflix, handling traffic spikes during new releases

For a photo sharing app like Instagram, enhancing content moderation effectiveness

But these aren't measurable metrics - they're aspirational goals. To drive effective decision-making, you need to translate these into concrete, measurable metrics:

Instead of "improving matchmaking experience", use: "Reduce matchmaking wait time from 45 seconds to under 15 seconds" and "Increase matchmaking accuracy (players of similar skill) by 20%",

Instead of "handling traffic spikes", use: "Maintain 99.99% availability during 3x normal traffic events" and "Keep response time under 200ms during peak load".

Instead of "enhancing content moderation", use: "Reduce time-to-detection for policy violations from 30 minutes to under 5 minutes" and "Decrease false positive rate from 8% to under 3%".

Connect Metrics to Business Impact - With Evidence

Even more important: for each metric, you must clearly articulate WHY achieving this target matters to the business. Without this connection, you're just chasing numbers for their own sake...