What Is Replatforming?

Replatforming Definition

Replatforming is an application migration strategy for transitioning an existing app from a legacy platform to a modern cloud platform to leverage the benefits of a cloud deployment model.

Overview of Replatforming

Gartner’s Migrating Applications to the Cloud is the seminal work of cloud migration strategies. It details the 5 Rs to cloud migration: rehost, refactor, revise, rebuild, and replace. In 2016, AWS built upon Gartner’s 5 Rs with its 6 Strategies for Migrating Applications to the Cloud (also known as the 6 Rs).

Replatforming helps enterprises strike a balance between simple rehosting and complex refactoring. Rehosting or “lift-and-shift” simply moves legacy monolithic apps to the cloud as-is. Since the underlying architecture is still monolithic, enterprises don’t get the cloud-native benefits a microservices architecture provides.

Conversely, refactoring a monolithic app can take years. As a result, the cost of refactoring can outweigh the benefits. Replatforming is a “lift-tinker-shift” approach that allows enterprises to capture the benefits of cloud-native while minimizing the time and complexity of migration.

Modular vs traditional e-commerce replatforming

In practice, traditional e-commerce replatforming often fell short of the ideals of “lift-tinker-shift.” That’s because, in the e-commerce space, replatforming usually meant moving from one monolithic app to another. For example, an enterprise that wants to migrate a legacy e-commerce app to Shopify Plus or Salesforce Commerce must move the entire app at once. This requires a “rip-and-replace” approach to replatforming that can be expensive, risky, and time-consuming.

Modular replatforming is a top-down approach that minimizes the risk and complexity of migration. It follows the strangler pattern to gradually transition from a monolithic app to a modern e-commerce platform. For example, suppose your CMS is your biggest performance bottleneck. You can first update your CMS while leaving the rest of your app alone. Then, over time you can replace the rest of the app piece-by-piece.

How Replatforming Works

The technical specifics of replatforming are different depending on your industry, application, and business needs. However, there is a general framework that replatforming projects should follow.

• Determine your needs: Every migration must focus on specific business needs. For example, an e-commerce business may move away from Shopify Plus due to its multi-store limitations.
• Identify a new platform that meets those needs: Many enterprises choose a headless e-commerce platform when Shopify isn’t big enough, or Salesforce isn’t fast enough.
• Modify: Do this to the infrastructure to accommodate the transition.
• Migrate: Once the infrastructure is in place, you can migrate to a staging app.
• Validate: Test the app before switching over to production.
• Transition to production: When validation is complete, you can transition from the old platform to the new one. Once the new app is live, you can monitor, test, and iterate it over time.

“Replatforming” from Monolith to Microservices

Microservices are decoupled and discrete pieces of functionality. Each service can leverage different programming languages, OS, and best-of-breed technologies. The modularity of each service eliminates the need to migrate an entire application when changing or replacing each microservice.

Creating microservices with small, autonomous functionality is important when designing a microservices-based ecosystem. This pattern decreases the chance of interdependency between other services. It also eliminates the need to swap out large sections of your application when making changes. Let’s look at some best practices for moving from a monolithic to a microservices architecture.

Approach the migration in phases

When migrating a large monolithic app to microservice components, we recommend planning the migration in phases. You should consider developing a facade layer that intercepts the requests between the frontend and backend systems.

As you create microservices to replace your legacy system, modify the facade to call the new services. Eventually, you can remove the facade once all phases of the migration are complete. This pattern will help mitigate risk during the migration effort.

Revisit your troubleshooting processes

Designing smaller discrete units of functionality is much easier than creating a tightly coupled monolithic application. When migrating from a monolith to microservices, you must revisit your logging, monitoring, and troubleshooting processes.

Generally, microservices are easier to debug than a complex monolithic application. Modifying your monitoring processes is a one-time event. Once you move to microservices, it is unnecessary to update these processes ever again.

Determine your scaling requirements

It is essential to identify scaling requirements for microservices during the design and eventual load testing of the services. Unlike a monolithic application, you can scale each microservice (or group of microservices) for performance. It frees you from the complexity of having to scale an entire platform.

Upgrade your CI/CD processes

When implementing a microservices platform, it is crucial to revisit your existing continuous integration (CI) and continuous deployment (CD) processes. With microservices, you can deploy each service (or group of services) separately without redeploying the entire application.

This isolation means you can implement a much more prolific CI/CD deployment schedule. You can also modify and deploy much smaller units of functionality with far less risk of downtime across the entire application.

Involve the entire business

When your company decides to migrate, you must involve the entire business, not just IT. For example, implementing microservices offers sales and marketing advantages over a single monolithic application. With service-oriented architecture, they can implement best-in-class third-party marketing solutions.

Example of Replatforming

Amazon’s bookstore

Today, Amazon is a prime example of the benefits of microservices. However, it wasn’t always that way. As Amazon’s CTO Werner Vogels says in this post and at HackFwd’s Build 0.7 event, Amazon’s “bookstore” changed a lot before becoming the e-commerce platform we know today.

Initially, the bookstore was a monolithic app with tightly coupled services: one front end was interfaced with multiple large databases. This was intentional as Amazon’s original focus was simply to “get big fast” and not worry about optimizing or future-proofing their architecture.

In 2001, Amazon realized its monolithic design and massive databases hindered its ability to scale. To break through the bottlenecks, Amazon came up with a service-oriented architecture based on: 1) looking for unique business logic 2) looking at the data the business logic operates on 3) combining the data and business logic into a single unit, and 4) exposing an API for other services to call.

By eliminating its large relational databases as bottlenecks and single points of failure, Amazon solved the biggest scalability challenges. Breaking the app down into microservices aligned with its “two-pizza teams” and “you build it, you run it” principles. Small and agile teams that own specific functionalities, like the “buy” button, can innovate and ship features. With standardized microservices in place, they can then iterate and automate their CI/CD workflows.

Replatforming FAQs

What are the business benefits of modular replatforming?

Compared to traditional “monolith to monolith” replatforming, using modular replatforming to migrate from monolith to microservices provides these benefits:

• Quicker implementations with a lower cost: In our experience, modular e-commerce replatforming can result in 10x faster implementation and 10x lower total cost of ownership (TCO). 

• Reduced risk: Migrating your app in phases reduces the risk of failure and lets you transition to a modern architecture over time seamlessly.

• Faster ROI: Modular replatforming lets you quickly replace specific areas of your app to see results faster.

• Better performance: Modular scaling and microservices that carry out specific functions generally perform significantly better than monolithic apps.

• Easier to maintain: Individual microservices can be updated, modified, or replaced without impacting the rest of your application.

How long does replatforming take?

Timelines vary depending on the size of your app and approach to replatforming. For example, with traditional e-commerce replatforming, the end-to-end process often takes 12-18 months. On the other hand, modular replatforming can take eight weeks or less.

What is the relationship between APIs, microservices, and modular replatforming?

Microservices is a modern approach to software design where multiple small services that perform specific functions work together to create an app. Compared to legacy monolithic apps, microservices-based apps tend to perform and scale better across distributed cloud platforms.

The services in a microservices architecture communicate using lightweight protocols and well-defined APIs. Modular replatforming allows you to transition from a legacy monolithic app to a more cloud-friendly scalable microservices-based app that uses APIs.

---