Minimum Viable Replacement: A New Approach to Modernizing Legacy Solutions

Minimal Viable Products (MVPs) have become the sole defacto way of building software. If you are not taking an MVP approach, you may get strange looks nowadays.

It has been proven time and time again as an effective way to quickly test a market hypothesis or build a proof of concept to test the technical feasibility of a solution. But what happens when you are not building a new solution and instead you are modernizing or replacing an existing one?

If you are using an MVP approach in this scenario, you will be in for a rude awakening in the form of wasted time, money, and unhappy customers.

Don’t worry… there is a better way. The Minimal Viable Replacement (MVR).

Minimum Viable Replacement: A New Approach to Modernizing Legacy Solutions.

What is a Minimal Viable Replacement (MVR)?

A Minimal Viable Replacement (MVR) is an approach, popularized by Kevin Mireles, to replace a legacy solution that has an existing base of users or customers.

These modernization or replacement projects are often labeled with the overused term, Digital Transformation. No matter what you call it, they all have one thing in common.


With an MVR, you already know a market exists for your solution. The question becomes, can your new solution meet and exceed the value delivered by your old product?

The approach focuses on decomposing the needs of the new system(s) into a clearly defined roadmap. This roadmap focuses on delivering valuable chunks of functionality into the hands of real users as soon as possible with minimal impact on their existing work.

Essentially, an MVR is the culmination of all the MVPs required to migrate existing customers to your new solution with minimal loss of existing customers.

Why the MVP doesn’t work when replacing an existing solution

By now, we have all seen this age-old MVP metaphor.
A diagram illustrating why incremental progress doesn't cut it for modernizing legacy solutions.

The goal of an MVP is to provide end-to-end value in an incremental fashion. In this example, the desired outcome is to get from point A to point B, and the first iteration of the solution, the skateboard, accomplishes that right off the bat.

The problem is, your existing customers are not willing to trade down to a skateboard when they are currently driving a car with a leather interior, air conditioning, and Bluetooth. Oh, and a few of those other important features like seat belts, airbags, and brakes…

To make this real, picture handing your existing customers a skateboard and asking them to test it out riding down the highway. That is a sure recipe for disaster and guaranteed loss of revenue.

Aerial photo of a busy freeway.

The major differences between an MVP and an MVR

Primary goal: validate a market or product hypothesis
Primary goal: migrate existing customers to the new modern system with minimal churn allowing for more agility
No existing customers
Existing customer base
Focused on attracting new customers
More focused on retaining existing customers than attracting new ones
Competing against other companies or existing behaviors
Competing against your existing solution
Deeper research required to vet the viability of the solution
Minimal research required as the solution has already been proven to have market fit
Focused on a very small set of target customers and use cases to prove out the product’s value proposition
Focused on identifying the most valuable and sometimes extreme use cases for your most valuable customer segments among the many existing customer segments
Focused on new functionality
Focused on improving existing functionality first, and typically new capabilities second
Targeted few specific workflows
Many existing workflows exist with existing users typically creating their own a-typical process within your system
Leverage new technology
Have to account for existing legacy technology
Ability to create new processes with a greenfield project
Must account for existing organizational norms, process, and culture

Why an MVR is unique

The typical approach for an MVP leverages the 80/20 rule, which in essence states that 20% of the functionality will serve 80% of the needs of your users. So therefore you should focus on that 20%.

With an MVR it is not that simple…

With an MVR, you have multiple customer segments you must satisfy in order to successfully replace a legacy solution. On top of that, those customers represent different value to your business, typically in the form of revenue or profitability.

Surprise, surprise – your larger, higher value customers typically require more extensive and complex functionality compared to 90% of your typical users.

This is why in an MVR you must consider the edge cases of your most valuable customers.

On top of having to consider edge cases (usually a ‘no no’ with MVPs), there are also two core psychological phenomena at play in an MVR.

Endowment effect: People are more likely to retain an object they own rather than acquire a similar object (either in value or appearance). In essence, people feel a sense of ownership over the systems and technology they currently use and are not typically gung-ho about giving it up.

Loss aversion: People value losses more than they value potential gains. Not just by a little either. They tend to value it by 2 to 4 times more. Anything less than that is likely to be perceived as incredibly negative. In essence, a bird in the hand is worth two in the bush.

We are ultimately creatures of habit, which makes an MVR unique.

A metaphor fitting for an MVR

Picture a 100-story condo. Let’s say you built the first 99 floors in a relatively standard fashion with 12-foot ceilings, standard bathrooms, and fixtures. They each pay $2K a month in rent.

Then you get to the last floor. The penthouse.

This is just one tenant, but they pay $30K per month.

They also have different requirements such as a swimming pool, 30-foot ceilings, and a helipad. If you didn’t account for this upfront, your architecture and design likely won’t support it.

So how do you approach an MVR to ensure you aren’t doing more harm than good?

The MVR approach

The goal of an MVR should be to meet and exceed the value delivered by your old solution without losing your existing customers in the process.

The approach focuses on decomposing the needs of the new system(s) into a clearly defined roadmap that focuses on delivering valuable chunks of functionality into the hands of users as soon as possible with minimal impact on their existing work. The roadmap should show them they don’t have to fear a loss of functionality because you have clearly communicated and mapped out when the functionality will be delivered.

There are 3 standard approaches to the MVR when considering how to develop your roadmap and define key milestones.

Functional Approach: If there is little overlap in functionality between end-user segments, you can structure your roadmap based on the specific functional needs of those different customer segments.

Diagram of a functional approach.
Process Approach: If your system covers long processes with no clear delineation by customer segments you can approach structuring your roadmap by the different processes and workflows within the system. Look for a natural break in the process to define replacement points where you can take segments of the process and replace them with the new system.
Diagram of a MVR process approach.
Add-On Approach: If you are looking to go after a new market or customer segment this is a good approach allowing you to create a newer leaner system focused on first adding that new target market or customer base. Then as the functionality builds up, you can migrate your existing customers to the new solution. This can be packaged as an add-on to your existing solution so as to not disrupt existing users, or make them feel like they are loosing their existing legacy solution in the process.
Diagram of a MVR add-on approach.
Below are some key elements to consider when taking on an MVR:
  1. Identify, define, and prioritize your different customer segments based on required functionality and value to your business
  2. Identify the edge cases your highest value customers must have to switch
  3. Align on if you are building the replacement solution for a new customer segment you are targeting in the market, and identify if this shift in strategy will result in churn of existing customer segments.
  4. Identify instances of customers using your solution in unintended ways (note: these are opportunity areas to build functionality to make these workarounds easier)
  5. Determine all the downstream applications and organizations using your systems inside and outside of the company
  6. Understand how users and organizations are using your solution and its data.
  7. Identify any regulatory or compliance-related requirements
  8. Determine if the new solution can start as an extension of the legacy one and sold as an add-on to start. Then, integrate the core functionality as part of your replacement strategy.
  9. Identify if there are any underserved customer segments that are not currently using your solution and would be happy with a true MVP
  10. Define your roadmap by breaking up the project into mini MVPs defined by functionality and customer segment served


At the end of the day, it is not a question of if you will need to replace legacy solutions. It is a matter of when.

While legacy solutions, processes, and technical debt have a knack for slowing down progress, you can’t let them hold you hostage.

Leverage an MVR approach to enable agility and innovation in your organization so you can continue to deliver value for your customers and your business.

Getting Started with HatchWorks Is Easy

Want to learn more about how we deliver solutions that are valuable, usable, feasible, and viable through our integrated US and Nearshore delivery model? No matter what phase you are at in your software solution journey, HatchWorks can help you create a user experience your customers will love.