Migration Patterns & Prioritization

The Folly of the "Big Bang"

Before we explore how to migrate, let's establish how not to. The temptation to plan a complete, ground-up rewrite of a monolithic system is strong. It feels clean and decisive. However, experience across the industry has shown this to be a perilous path. These projects often take years, drain resources, and fail to deliver value until the very end—if they deliver at all.

As a change leader, your first principle should be to de-risk the transformation. This means rejecting the big bang in favor of an incremental strategy that delivers value early and often, allowing the organization to learn and adapt as it goes.

Newman's core message is that microservices are not the goal in themselves; they are a means to an end. An incremental approach allows you to continuously validate that the changes are achieving your business objectives without betting the entire company on a single, massive project.

Pattern 1: The Strangler Fig

If we're not doing a big bang, how do we incrementally carve pieces out of the monolith? The most famous and widely used approach is the Strangler Fig Pattern. The name comes from a vine that wraps itself around a host tree, eventually replacing it.

In software, this pattern works by building a new service and gradually routing traffic to it, "strangling" the old monolithic functionality over time.

The key is to place a routing layer (often an API gateway or a proxy) in front of the monolith. This router initially passes all traffic to the monolith. Then, as you build a new microservice to replace a piece of functionality, you configure the router to send specific requests to the new service instead. The rest of the system, including the users, is unaware that the change is happening.

The Strangler Fig is powerful for a change leader because it:

• Minimizes Risk: You can test the new service with a small fraction of live traffic before a full switchover. If something goes wrong, you can instantly reroute traffic back to the monolith.
• Maintains Business Continuity: The system remains fully operational throughout the migration.
• Demonstrates Value Early: You can deliver a new, improved piece of functionality without waiting for the entire project to finish.

This pattern is ideal for functionality that can be easily intercepted at the "edge" of the system, such as user-facing features or API calls.

Pattern 2: Branch by Abstraction

What about functionality that's deeply embedded within the monolith, without a clear entry point to intercept? For these cases, another pattern called Branch by Abstraction is extremely useful.

This is a technique for making large-scale changes to a codebase inside the monolith in a safe, incremental way, preparing it for eventual extraction.

Here is the process at a high level:

1. Create an Abstraction: Identify the functionality you want to change and create a generic interface (an "abstraction") that represents it. Modify the existing code to use this new interface. This is a safe refactoring step.
2. Create a New Implementation: Build your new implementation of the functionality (which could, for example, call out to a future microservice) behind this same interface.
3. Switch Implementations: Use a "feature flag" to toggle between the old and new implementations. This allows you to deploy the new code to production but keep it inactive (a "dark launch").
4. Verify and Clean Up: You can then activate the new implementation for internal testers, or even run both implementations in parallel to compare their results. Once you are confident, you switch all traffic to the new implementation and can remove the old code.

From a change management perspective, Branch by Abstraction provides a structured and safe way to conduct major "surgery" inside the monolith, reducing the risk of breaking existing functionality while preparing for a future service extraction.

Developing Prioritization Criteria: Which Service Goes First?

Now that we know how to migrate a service, we face the crucial strategic question: which one should we migrate first? A haphazard approach can lead you to tackle something too complex too soon, or to spend effort on a change that delivers little value.

As a Product Manager, you're familiar with frameworks for prioritization. We can use a similar approach here. A Value vs. Complexity Matrix is an excellent tool for this.

Our task is to define what "Business Value" and "Complexity" mean in the context of a microservices migration.

Defining the Axes

Based on the expert advice in our resources, here are the key questions to ask when plotting a potential service on this matrix:

Business Value (High or Low?)

• Business Importance: How critical is this capability to our business strategy and customers? Does it differentiate us? (Source: Martin Fowler)
• Frequency of Change: How often do we need to modify this part of the system? Migrating frequently changing parts provides the biggest agility benefits. (Source: Martin Fowler)
• Unlocks New Capabilities: Will migrating this service enable us to do something new, like add AI features or scale to new markets?

Complexity / Risk (High or Low?)

• Technical Complexity: How entangled is this component with the rest of the monolith? How many other parts of the system depend on it? (Source: Sam Newman)
• Data Dependencies: Does it have its own data, or is it deeply tied to a shared database? Data migration is often the hardest part. (Source: Sam Newman, Martin Fowler)
• Team Readiness: Does the team have the skills (e.g., in the new programming language)? Do we have the necessary DevOps maturity (automated testing, CI/CD pipelines, monitoring) to support this service? (Source: Neontri, IT k Funde)

Practical Application

Let's put this framework into action.

Exercise (Approx. 10 minutes):

Consider your context of a B2B software company with a monolithic Loan Origination System. Imagine you are deciding between migrating two components:

1. "Document Management": A service that handles uploading, storing, and tagging supporting documents (pay stubs, ID cards, etc.). It changes infrequently but is a performance bottleneck.
2. "Credit Scoring Rules Engine": The core logic that evaluates loan applications. The business wants to update these rules weekly to respond to market conditions, but the current system only allows for quarterly updates. It is highly complex and integrated with many other parts of the monolith.

Using the Value vs. Complexity matrix and the criteria we've discussed:

1. Where would you place each of these two components on the matrix?
2. Write a brief (2-3 bullet points) justification for your placement of each one.
3. Which one would you recommend migrating first, and why?

This exercise will help you practice applying the strategic thinking required to build a viable migration roadmap.

Conclusion

Today, you've learned the fundamental strategies for planning an incremental microservices migration. You've moved beyond the why and into the practical how.

Key Takeaways:

• Embrace Incrementalism: Avoid "big bang" rewrites. Your goal is to deliver value in small, safe, and manageable steps.
• Use Proven Patterns: The Strangler Fig pattern is the primary tool for extracting services from the edge of the monolith, while Branch by Abstraction helps manage complex changes internally.
• Prioritize Strategically: Use a Value vs. Complexity Matrix to decide which services to migrate.
• Define Your Criteria: Assess potential migration candidates based on business value (importance, frequency of change) and complexity (technical, data, team readiness).
• Start with an Easy Win: Your first migration should ideally be a high-value, low-complexity service to build momentum, confidence, and organizational capability.

Preview of the Next Lesson

We now know how to migrate individual services and how to prioritize them. The next logical step is to assemble these decisions into a coherent plan. In our next lesson, we will focus on how to draft a high-level, phased migration roadmap sequencing the rollout and defining key business milestones. This will be the master plan that guides your transformation program.