The Minimum Viable Replacement Modernization Framework
80% of modernizations fail!
Will yours be one of them?
  • Do you have hard deadlines, based on mushy data?
  • Is your project a watermelon, reporting green, but actually red on the inside?
  • Are you struggling to figure out how to slice the initiative into manageable chunks?
  • Are you being pushed for quick wins, irregardless of whether they result in slow death?
  • Are you planning to deliver an "MVP" without really understanding what's required to retire and migrate customers?
Fortunately, we offer the insights, tools, training, workshops, and coaching to help you succeed!
Why Traditional Approaches Fail
Wrong Frameworks
Use methodologies designed for startups, not for replacing mission-critical 10+ year-old systems!
Miss key risks until too late!
Most projects unknowingly backload all of their critical risks, only discovering them when it's too late!
Unrealistic Expectations
Underestimate cost, time, and complexity of work by 2 to 5X.
Encourage Watermelonitis
Despite showing green, projects are actually red, exploding at supposed end, when true status is revealed.
Ignore adoption barriers
While value is important, minimizing effort is even more so, as any additional work, leads to even greater reduction in adoption.
Focus on averages
Averages matter, but extremes matter more. In most organizations, a small sliver of customers and use cases drive overwhelming majority risk and work.
The MVR Modernization Framework helps organizations
Embrace uncertainty
Manage unpredictability in modernization initiatives.
Spot Risks Early
Identify, prioritize, mitigate and communicate overlooked risks.
Maximize Success
Create effective product and project plans and approaches.
Stay Aligned
Use common language and frameworks for clarity.
Avoid Pitfalls
Identify and common traps in replacing legacy systems.
Deliver Value Sooner
Set realistic expectations and drive customer uptake.
Why We Need a New Model
Most current methodologies—Waterfall, MVP, Agile, and Scaled Agile—fall short when it comes to modernizing complex legacy environments:
  • Waterfall assumes full knowledge upfront—unrealistic in complex, uncertain systems.
  • MVP prioritizes speed and simplicity, often ignoring high-impact edge cases.
  • Agile encourages momentum but may sacrifice architecture and planning.
  • Scaled Agile Framework adds process but lacks practical modernization guidance.
MVR fills the gap by focusing on what’s actually required to migrate existing systems—not just what can be built fast.
Core MVR Principle
Minimum Viable Replacement = All the capabilities, work, and experiences required to migrate users from one system to another.
This shift reframes the goal: from "What can we build?" to "What will it take to get people to actually switch?"
Examples of Where MVR Applies
  • Software Modernization – Replace legacy platforms without disrupting core business.
  • Supply Chain Transformation – Shift infrastructure while sustaining operations.
  • Vendor Displacement – Win over customers by replacing entrenched competitors.
  • AI & Robotics – Define the minimum capabilities to fully substitute existing workflows.
MVR Modernization Framework: A Few Key Concepts
Adopt the Modified Technology Adoption Model
Traditionally, most product developers focus on the value a new solution will deliver, and overlook the expected work/cost to adopt beyond the listed price.
Instead of focusing on minimizing the perceived work, risks, and costs of adopting a new solution, we invest more into adding incremental value.
In reality, when we as individuals or organizations look at adopting a new solution, while we definitely pay attention to the value, we tend to focus even more on the potential work and cost.
The Model:
Adoption Rate = (Potential Value - Potential Work & Cost)
+/- Power, Cultural, & Other Dynamics
Why Work & Cost Loom Large
After all, we live in a world of incredible opportunity, where there are thousands of things we can and should do to improve ourselves, our families, and organizations. But we are incredibly constrained by the time, money, and resources we have to adopt new things.
As a result, the potential work and cost looms much larger in our decision making, since we have a very finite amount of time, energy, money, etc. to invest in change. This includes the potential risk of failure, so more often than not we will choose minimizing downside risk over upside opportunity.
And as most of us have painfully learned, everything takes twice as long or costs three times as much as originally envisioned. So we may also multiply the potential work and cost in our heads or in Excel to take into account the uncertainty.
External Dynamics That Matter
Finally, there are a wide variety of external and internal factors that may hinder or aid adoption.
Power: Who has the power in the relationship? Is an outside entity, e.g. your largest customer or employer, in a position to mandate adoption? Or are you a small commodity supplier to Walmart, and therefore not in a position to push change, since you have zero leverage?
Cultural: Is the organization open to change or very conservative? Oftentimes, change is generational and requires new blood to drive change, or a crisis.
Other Dynamics: Are there regulatory drivers or other preventers or drivers of change?
Recommendation: While delivering value is important, focus even more effort on reducing the potential cost of adoption.
A simpler, easier-to-adopt solution, will almost always beat a "better" but more complex product in the market. And every additional perceived effort/cost required to adopt has an exponentially negative effect on adoption.
Understand Augmentation vs. Replacement
Remember when you first got a cellphone?
You looked at whether you could afford both a landline and a cellphone, whether it delivered enough upside value to make the investment worth it.
Did you immediately turn off your landline?
No, instead your cellphone augmented the landline. It gave you new capabilities that the landline lacked, the freedom to call from almost anywhere, but at the same time, it wasn't always reliable.
If you called 911, the police wouldn't automatically be able to identify the associated address to come to in an emergency.
As a result, most people kept their landlines for years because they were concerned about losing capabilities they had, even if they rarely/never used them. Instead the land line acted as an insurance policy, to address the what if situation.
Only after people felt comfortable enough or had enough financial pressure did they transition from the cellphone augmenting their landline to replacing it.
This distinction is crucial for sustainability transitions.
Augmentation Economics
Augmentation Value = (New Solution Benefits)
- (New Solution Costs + Old Solution Maintenance Costs)
Augmenting requires having the capacity to adopt and support two or more similar solutions at the same time.
Either:
  1. The adopting party is wealthy enough that the incremental cost isn't as important as the incremental value, i.e. the wealthier you are the more things you can augment.
  1. Or in a more resource constrained environment, that the value delivered from the new solution exceeds the costs of supporting two solutions.
In either case, the adopting party needs to have the capacity to support multiple overlapping solutions. So while an e-bike may eliminate fuel costs for shorter trips in warmer weather, unless you can get rid of your existing car, the overall cost will exceed the cost reductions, therefore making them too expensive for most households.
So, with augmentation, you need to target customers that can afford to support multiple solutions, or figure out a model that lowers the cost of adoption. E.g. offer e-bikes as an on-demand rental service.
Replacement Economics
Replacement Value = (New Solution Benefits + Old System Elimination) - (New Solution Costs + System Breakage Risk)
Replacing eliminates the ongoing cost of maintaining two systems, but it adds a new variable, the risk of breaking the existing system.
What if the new thing doesn't work? What if for that rare event, we really need that one capability, is it worth the risk?
What if I need you to pick the kids up in an emergency, and all you have is an e-bike? What if we want to drive to the mountains on vacation, and there aren't chargers, will we need to rent a car instead, or worse we get stuck in the middle of nowhere?
What if we rely on wind and solar and the sun stops shining and the wind stops blowing for not just a few hours, but a few days or weeks, what then?
The capability we are replacing may be only needed once a year, decade, or maybe never, but if the perceived downside is great enough, then the expectation for the replacement is that it will at least match what the old system had, or that there is a potential backup solution that reduces the risk.
Loss Aversion needs to be factored into the equation as well.
Loss Aversion is the concept whereby people value what they already have twice as much as what they might get in the future. So even if something has little "actual" value, e.g. my four-wheel drive which I never used but imagined one-day using, we are still loath to swap it for something that may have actual ongoing value, e.g. a two-wheel drive car with better gas mileage.
And what defines a "catastrophic" risk is in the eye of the beholder, so what might be a perfectly acceptable risk for one party, might be a "you're absolutely crazy" for another.
Recommendation: Understand the very different risk and financial implications of augmenting vs. replacing as how you develop and market each will be wildly different.
When augmenting, you are both adding capabilities and overall costs, but the downside risks are fairly limited. E.g. the money spent on an e-bike is wasted, but since you still have your car, if the e-bike doesn't work, it doesn't prevent you from getting where you want to go.
When replacing, while the total cost will theoretically be lower, the risk of breaking the system and not meeting expectations is much greater. So for critical applications the likelihood of adoption will actually be much lower. E.g. in a single-car family, if I have to choose between an EV and a gas-powered car, if I'm worried that the EV won't work for the infrequent but important vacation drives, then I still won't switch, even if the cost of the EV is much lower.
MVPs are for net new products, not replacing 10+ year-old systems
Users and customers are rarely willing to trade their car for a bike or a skateboard. They want what they had, and will be unhappy if you take things away from them, even if they rarely used the feature.
After all, how often do we buy and keep things just in case we might need that random kitchen utensil, the extra bedroom, or the third-row in the car.
In the B2B world, your largest customers are the most demanding and have the most power, and they certainly won't except an 80% product, so be prepared to give them what they want, or else!
1% of your customers and uses case drive majority of work and risk
A tiny fraction of customers (often <1%) drive the majority of revenue, complexity, and risk. These enterprise "icebergs" require dedicated strategies.
Design for the 1%, Deliver for the 80%
Start by architecting for your most complex scenarios—then deliver early wins to the majority. Don't ignore edge cases just because they're rare.
Treat each of your largest customers as a segment of one
Given the size and complexity of your largest customers or value chain partners, you need to treat each of them as a segment of one!
While it's easy to lump them all into the large category, typically they will have so many customizations and revenue, etc. associated with each one, that they needed to be treated as individual segments, so instead of thinking of them as just 10, 20, or 30 customers, they are 10, 20, or 30 unique "segments" that need to be addressed individually.
Once you think of them as segments, then it makes it easier to understand why migrating them will take so long.
Factor in Adoption Timelines
Development is fast. Migration and adoption are not. Large customers may take years to fully switch—plan accordingly.
Prepare for Tradeoffs
You’ll need to balance maintaining legacy systems with developing net-new capabilities. Governance is key.
Segment and slice your way to success
When replacing an existing system, you can either:
  1. Expand your MVR to incorporate the requirements to replace everything.
  1. Slice the replacement into multiple smaller MVRs/digestible chunks to deliver value sooner.
Rather than try to solve for replacing the entire legacy process out of the gate, it's usually better to shrink the problem space into manageable chunks so you can avoid the explosion of edge cases that arise when you replace an entire system.
The key is to focus not just on the technology you are developing, but holistically about all the capabilities, work, and experiences required to migrate users from one system to another.
The Process
  1. Define the different capabilities handled by the existing system
  1. Score them based on their difficulty.
  1. Identify user segments based on the capabilities they require.
  1. Design solutions that address specific slices completely.
  1. Solve for the easiest segments first.
  1. Create bridges between phases to maintain momentum.
  1. Tackle ever more complex segments.
  1. Measure progress toward full replacement goals.
Identify and mitigate risks early
While it's impossible to mitigate all risks early in the development lifecycle, many common risks that most people overlook are easy to find if you know where to look. The Watermelon Preventer helps teams quickly identify, prioritize, begin mitigating and communicating risks early, when it's much cheaper and easier to deal.
Avoid the Trap of Quick Wins
Quick wins are great if they accelerate learning, development, and adoption. Unfortunately, most quick wins deliver little actual value, and more often lead to slow death, as the teams deal with shoddy architecture and code that slows their ability to deliver ongoing value.
Unlike startups, enterprises need to focus not just on usability, value, and viability, but scale. If it can't scale, it will faillso focus on foundational architectural work to avoid degradation.
Embrace Uncertainty: Start modernizations out "red" or "gray", not "green"
Any time you have high uncertainty and complexity, your ability to predict the future goes to zero.
And the beginning of an initiative is when you have the greatest uncertainty and complexity, so how can you call something green when you really have no idea what it will take to successfully modernize a system, and basic probability prevents any level of confidence.
Instead, call it red if you have a fixed scope and date, or gray if you are flexible, and only change to yellow and green as you reduce uncertainty and uncertainty.
What we offer!

Framework and Tools
Designed specifically to address the challenges of modernizing legacy technologies, not for early-stage Silicon Valley startups!
  • The Minimum Viable Replacement Framework
  • The Watermelon Preventer
Training and Workshops
Surface common risks and drive alignment across key stakeholders early in the process to avoid disastrous outcomes later!
Ongoing Coaching
Get the help you need from modernization veterans who have been there, done that - so you can learn from their mistakes and avoid making them yourself!
🚀 Minimum Viable Replacement (MVR) Roadmapping & Risk Mitigation Workshop
The MVR Roadmapping Workshop equips your team with the strategies, tools, and frameworks to replace legacy systems without breaking the business or your biggest customers.
✅ What You’ll Learn
  • Why most modernization efforts fail—and how to avoid disaster
  • The difference between MVPs and MVRs (and why it matters)
  • How to segment customers and map capabilities for smarter planning
  • How to identify high-risk dependencies and simplify complex transitions
  • How to architect for your most demanding customers while delivering early wins
  • Where key risks are hiding and how to address them sooner than later
🧠 What You’ll Do
  • Map your customer and feature base
  • Apply the KUCI model (Key Uncertainty, Complexity, Impact)
  • Design a phased modernization roadmap
  • Balance trade-offs between retiring old systems and building new capabilities
  • Create timelines and an actionable modernization plan
  • Identify, prioritize, and begin mitigating key risks
👥 Who It’s For
CIOs, Product Leaders, Architects, Engineering Managers, and Transformation Teams
🕒 Workshop Format
  • Half-Day (3.5 hrs), Full-Day (6 hrs), or Two-Day (12 hrs)
  • Virtual or in-person
  • Interactive, hands-on, and tailored to your organization’s reality
🎯 Deliverables
  • Risk-prioritized customer segmentation
  • MVR modernization roadmap
  • Trade-off framework for new vs. replacement functionality
  • Clear action plan and alignment
The subscription includes:
  1. 👉🏽The Watermelon Preventer: A Worksheet with 60+ Questions across 7 categories that enables you to uncover, track, and communicate common modernization risks. Depending upon how you answer, it will highlight whether something is a high, medium, or low risk, so you can take action before it's too late!
  1. 👉🏽 Risk Management Guides: For many of the questions, you get a simple explainer outlining why the risk is important, and potential mitigation options.
  1. 👉🏽Weekly Newsletter: Get the latest insights into how you can reduce your risks and increase your successes.
Feedback
Global Head of Product
Project Manager
👉 "I wish I had your framework when I first inherited the project, it would have helped identify issues and have the hard conversations much earlier." - Senior PM on a project two+ years behind schedule.
Analyst at Giant Consulting Firm
😮 "The Watermelon Preventer would have helped identify issues and avoided us signing a fixed-price contract for a project, originally projected to be six months and is now 18 months behind schedule."
MVR Framework Presentation Feedback
✅ Average rating for talks = 4.5 out of 5
🎉 “Beginning to end, this session was phenomenal! Material was well researched, presented, and executed, and I am confident I can glean tons of value by applying the data and concepts provided. Aside from the material itself, the presenter made potentially dry topics actually ENGAGING and (dare I say) ENTERTAINING.” – Music City Agile Attendee
🎉 "I don’t know how it could have been better!" - IT Application Delivery Manager AEP
🎉 "No improvements needed for this talk unless you can find a silver bullet to tackle replacement projects ;-)"- Director Software Development
🎉"The topic was so relevant to business analysts"
🎉"The pictures were great! Great presentation! I really enjoyed it" - Software engineer
Presentations and Publications

Mind the Product

Minimum Viable Replacement: A New Framework for Retiring Old Systems

Take 10 minutes 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.

Mind the Product

Integrating social responsibility into product development

In a world facing catastrophic climate chaos and economic inequality, we need to explicitly design social responsibility into product.