BY Kevin Mireles ON APRIL 8, 2021

Are you engaged in a digital transformation initiative, working to retire systems as part of a merger and integration project, or sunsetting a legacy product? If so, then take a moment to learn about a new concept, the Minimum Viable Replacement before you potentially waste thousands of hours and millions of dollars pursuing the wrong strategy for retiring and replacing existing systems.

I developed the concept after three incredibly painful years of stumbling through a multimillion integration and retirement project of a product used by hundreds of thousands of users around the globe.

New to agile, we embraced the MVP gospel being preached by our consultants, only to discover that retirement and replacement projects are the absolute opposite of an MVP, and require an entirely different approach.

Minimum Viable Replacement to the rescue

The Minimum Viable Replacement framework addresses two key challenges that plague people who attempt to retire legacy systems and migrate their existing customers onto new products or platforms:

It stops the confusion caused by trying to apply the Minimum Viable Product (MVP) concept to retiring systems. Conflating the retirement of an entire system with an MVP is the same as conflating a brick with a finished house or a bike with a car — or a slice of a pie with the whole pie. There are similarities between the two, but good luck convincing your car, home, and pie owners to trade them for a brick, bicycle, or slice of pie.

It provides a framework for architects, UXers, product, and project managers, to tackle the difficult problem of replacing systems that serve all sizes of customers in multiple geographies across multiple markets.

What is it good for?

In the world of agile, everyone talks about MVPs, the smallest set of capabilities required to meet a segment of your customers’ needs. The concept popularized by Eric Reis in the book Lean Startup is great for companies entering an entirely new market where they lack existing products and customers.

An MVP is simply a validated hypothesis that explains that a certain minimum level of functionality is enough to meet a specific market segment need.

An example of utilising an MVP (Image: Kevin Mireles)

The key to a successful MVP is to solve a specific market segment challenge first, instead of trying to solve multiple needs across multiple markets:

The problem: Replacing an existing system is the exact opposite of an MVP

If you’re trying to retire a legacy platform — instead of having the luxury of just solving very specific customer segment needs — you need to solve the needs for every customer segment using your software!

Imagine your company started 20 years ago serving a few small customers in one specific market segment and one country. Now you’re serving multiple different industry segments, across multiple countries.

To top it off, about 100 (or .01%) of your customers drive the majority of your revenue from a scalability and functionality standpoint.

Instead of trying to solve the needs of just one small segment, you now have to deliver 20 years worth of software development for thousands of customers across multiple countries and segments to retire the system — the exact opposite of an MVP. The classic agile product-development concept of building a skateboard, bike, car analogy of product development completely falls apart. Since the majority of your customers are already paying you for a car, they aren’t about to trade down for a skateboard.

As you’re trying to replace your old systems, customer, regulatory, and competitive demands are forcing you to enhance the existing systems as you’re trying to replace them. Consequently, delivering an MVR is typically more complex, costly and risky than launching an MVP. You can destroy your company if not done right.

Comparison between MVP & MVR

MVP Focus= Acquire New Customers

MVR Focus= Avoid Breakage 1st, Acquire new customers 2nd

The comparison between an MVP and MVR framework (Image: Kevin Mireles)

The Solution: Use the Minimum Viable Replacement Framework

Embracing an MVR won’t make the process easy or guarantee success, but it points you in the right direction. Simply put, an MVR is the total of all the MVPs required to migrate existing customers to the new system with minimum breakage and retire the old version.

Successfully executing an MVR requires:

1. Replacing or enhancing all of the existing features/capabilities required to retain your existing customers.
2. Providing the capabilities, support structures and inducements required to migrate all of your customers to the new platform, plus any additional work required to retire the system. Migrating customers to the new platform can take many times as long, and cost much more than the new platform.

Replacing and retiring systems requires different approaches

When you’re dealing with an MVR, you already know there’s a market. The question is, does your new product meet and exceed the value delivered by the old product? This requires different approaches.

Imagine you’re a car manufacturer. You know electric vehicles are the future, and gas-powered vehicles are on the way out. You don’t want to wind up like Kodak, especially as you see Tesla grow from a pipsqueak into a global giant. The faster you make the transition to another technology, the better because you’re having to invest in both technologies in the interim. The question is how? What combination of technologies, product, ecosystems and inducements will be required to migrate as many customers as possible so that you can shut down your legacy systems.

Since electric cars are cars, you don’t have to prove their value. You just need to prove that the electric technology works as well as, or better than gas-powered technology to switch. While there are many downsides to gas-powered cars, they do a lot of things well. We’re already comfortable with them and have built a system that enables us to drive as far as we want.

Consequently, we need to prove that the new technology matches or exceeds the value of the old technology for our existing customer base.

If the goal is to retire a system, focus on your extreme/edge case first

Especially if you’re in the B2B market, you can’t underestimate the importance of designing for extreme use cases. This is because of loss aversion — the concept that shows people tend to fear a loss twice as much as they are likely to welcome an equivalent gain.

Replacing gas-powered cars with electric ones highlights the challenge of overcoming loss aversion. For example, while most of us drive less than 100 miles per day 95% of the time, we still want a car that’s able to drive 500+ miles in a day to support the few times a year for long road trips. Even though the electric car is overall better, the chances we’ll switch are low, because we fear the loss of freedom.

Moreover, those edge use cases are often critical for your largest customers; the 1% who drive 40-90% of your revenue, and who drive 90% of your complexity. If you design for 99%, it’s a possibility that your solution won’t scale to support your most impactful customers.

Let’s think about a 100-story condo. The “regular” folk live on the first 99 floors with 12-foot ceilings, fairly standard bathrooms, etc. and pay $10k in rent annually. The 1% live on the 100th floor with their swimming pools, helipads, 40-foot ceilings, and pay $5 million annually. If you design for the first 99 floors initially, and then get to the last floor, only to discover that a 40-foot ceiling and helipad are critical requirements, what’s the probability your design and architecture will support these “crazy” use cases?

Each of your largest customers — especially if you’ve done a lot of customizations —may need to be treated as its segment with an associated MVP to successfully meet their needs.

You may decide to have two entirely separate approaches. Standard architecture and design for the 99% and custom solutions for the 1%, but that leverage shared services whenever possible.

Retiring systems takes longer and costs more than your executives want to hear

Typically, most companies underestimate just how complex it is to support their largest customers, and just how little concern they have for your desires to retire your systems. This leads to massively underestimating both the amount of work and time required to get their largest customers to transition.

Replacing gas-powered cars with electric cars provides a similar challenge. While it’s easy to build an electric car that can travel 100 miles on a single charge, building an infrastructure to support driving 500+ miles in a single day is a harder nut to crack. If the goal is to eliminate gas-powered cars, the challenge is much harder than just attempting to grab a slice of the market.

Unfortunately, the MVP approach almost guarantees that organizations will underestimate the amount of work required to replace core technologies. The entire concept of an MVP is about doing the least work possible, not all the work required.

As long as you embrace the fact that it takes years to replace decades of development — not months or days — then you can plan for the unexpected, and take advantage of opportunities as you implement new components.

A few questions to kickstart your Minimum Viable Replacement strategy

Below are just a few questions you’ll want to ask as you plot your replacement strategy:

1. How much revenue comes from the top 1% of our customers?
2. Do we understand the edge use cases, e.g. how the system is used to close the books at the end of the year, or when there is a regulatory audit?
3. Who are our top customers, and what types of customizations have we done for them?
4. How deeply integrated are our systems integrated into theirs? And how difficult will it be for them to adopt our new systems?
5. What are all the downstream applications and organizations using our systems, inside and outside our company?
6. How are these individuals and organizations using our systems and the data they produce?
7. Can we segment our customer base by capability requirement? If so, can we Identify MVR requirements for each segment?
8. Are there new underserved segments that don’t currently use our existing product because they can’t afford it, implementation complexity or because it’s not available on X platform, e.g. mobile, that would be happy with a true MVP?
9. Is the new product an extension of the old and should be initially sold as an add on or is it a true replacement? Sometimes you can start by offering an enhancement that can be sold as an add on and then later integrate core replacement functionality.
10. Is it better to piss off your existing user base or potential users? Oftentimes, we build functionality for a specific niche or customer and have to make hard choices about whether it’s worth supporting existing customers vs. serving a broader set of new customers. Just be prepared for the blowback as what makes sense on paper to you may not make sense to the VP of sales or service dealing with irate customers or trying to hit their quarterly targets.

Good luck!

Replacing existing systems is incredibly difficult, given the many complexities and competing demands. While I could write many more words about the many challenges, tips, and tricks I’ve learned over the years, that would result in a book. In the meantime, I hope this article has been helpful to you.

Explore more content