*This is the second of two blogs examining considerations for transitioning to a microservices-based architecture. For more information, check out our e-book *[*Blowing Up the Monolith: Adopting a Microservices-Based Architecture*](https://konghq.com/ebooks/adopting-microservices)*Blowing Up the Monolith: Adopting a Microservices-Based Architecture**. In our previous blog, we outlined the *[*five questions we must consider before making the transition to a microservices architecture*](https://konghq.com/blog/moving-to-microservices-five-questions)*five questions we must consider before making the transition to a microservices architecture**. *

Now that we have a better understanding of the benefits and challenges of a transition to [microservices](https://konghq.com/microservices)microservices, we need to understand how we make the transition from a technical perspective. There are three primary strategies we can adopt to transition to microservices - the **Ice Cream Scoop**, the **Lego**, and the **Nuclear Option**. Before we evaluate the pros and cons of each of these, we need to identify our boundaries and test. This process will be the same for any strategy we choose, but it's important not to overlook as it will fundamentally shape our success as we dive into the transition.

To identify the boundaries of our monolith, we must first figure out what services need to be created or broken out from the monolithic codebase. To do this, we can envision what our architecture will look like in a completed microservice architecture. This means understanding how big or how small we want our services to be and how they will be communicating with each other. A good place to start is by examining the boundaries that are most negatively impacted by the monolith, for example, those that we deploy, change or scale more often than the others.

Testing transitioning to microservices is effectively a refactoring, and we need to take all the regular precautions we would before a "regular" refactoring. A best practice here is that before attempting any change, a solid and reliable suite of integration and regression tests are put into place for the monolith. Some of these tests will likely fail along the way, but having well-tested functionality will help to track down what is not working as expected. With our testing and boundary identification completed, let's look at our **three strategies for transitioning to microservices.**

1. - **Ice Cream Scoop Strategy**
   This strategy implies a gradual transition from a monolithic application to a microservice architecture by "scooping out" different components within the monolith into separate services. Given the gradual nature of this strategy, there will be a period where monolith and microservices will exist simultaneously. The advantages of this are that our gradual migration reduces risk without impacting the uptime and end-user experience. This gradual transition, however, is also a drawback as the process will take longer to fully execute.
2. - **Lego Strategy**
   This strategy entails only building new features as microservices, and it is ideal for organizations that want to maintain their existing monolith. Using the Lego strategy will not resolve issues with our existing monolithic codebase, but it will fix problems for future expansions of the product. This option calls for stacking the monolithic and microservices on top of each other in a hybrid architecture. The primary advantages here are speed and reduced effort due to not needing to do much work on the monolith. The primary disadvantages are that the monolith will continue having its original problems and new APIs will likely need to be created to support the microservice-oriented features. This strategy can help buy time refactoring, but it ultimately risks adding more tech debt.
3. - **Nuclear Option Strategy**
   Our final option is rarely used. The Nuclear Option requires rewriting the entire monolithic application into microservices all at once. We may still support the old monolith with hotfixes and patches, but we would build every new feature in the new codebase. The main advantage is that this allows the organization to re-think how things are done and effectively rewrite the app from scratch. The disadvantage is that it requires rewriting the app from scratch, which could create unforeseen issues. The Nuclear Option may also inadvertently cause "second system syndrome" where end users will need to deal with a stalled monolith until the new architecture is ready for deployment.

While transitioning to microservices will always require substantial effort, choosing the correct strategy for your organization can substantially reduce friction during the process. No matter which strategy we choose to make the transition, it’s critical that we effectively communicate expectations and requirements to team members. With a clear strategy outlined and agreed upon, we are well on our way to blowing up our monolith and reaping the benefits of a microservices architecture.