The Minimum Viable Replacement Modernization Framework
80% of modernizations fail!
Why?
Because 1% of your customers drive the overwhelming majority of the work and risk!
And you can't replace critical infrastructure with MVPs!
Fortunately, the Minimum Viable Replacement Framework can help you succeed and avoid career-wrecking surprises!
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 is often interpreted to mean skip planning, resulting in teams wasting time building the wrong things.
- 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
Embrace the Technology Adoption Model
While value is important, minimizing the work required to adopt is even more so.
The Technology Adoption Model states that adoption is driven by two things:
Potential Value - Perceived Work
And that the perceived work weighs much more heavily on adoption than value.
Why?
Because there are an infinite number of things we can and should do, but our time, money, and energy is extremely finite, so the less effort the better.
Because there are an infinite number of things we can and should do, but our time, money, and energy is extremely finite, so the less effort the better.
So focus not just on value, but how you can help people be lazy and successful, by stripping away as much initial and ongoing effort to use as possible.
Remember, easier almost always beats better!
Understand Augmentation vs. Replacement
Augmenting is low risk, because you can always use the old system if the new one doesn't work.
Sure, it costs extra to have two systems versus one, but if the extra benefit is worth it, then so be it, which is why we have both a laptop/desktop and smartphone, despite the overlap in capabilities.
Replacing eliminates the cost of owning two separate but overlapping systems, but on the flip side, the risk of value destruction skyrockets.
Why?
Replacing eliminates the ongoing cost of maintaining two systems, but it adds a new variable, the risk of breaking the existing system.
That fear makes us hesitant to change, and value what we have much more than what we might get
The greater the risk for breakage, the more the downside looms and the less important the potential upside.
So remember, how you approach augmentation and replacement are wildly different!
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:
- Expand your MVR to incorporate the requirements to replace everything.
- 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
- Define the different capabilities handled by the existing system
- Score them based on their difficulty.
- Identify user segments based on the capabilities they require.
- Design solutions that address specific slices completely.
- Solve for the easiest segments first.
- Create bridges between phases to maintain momentum.
- Tackle ever more complex segments.
- 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.
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.
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:
- 👉🏽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!
- 👉🏽 Risk Management Guides: For many of the questions, you get a simple explainer outlining why the risk is important, and potential mitigation options.
- 👉🏽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
🎉 "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
Loading...
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.
The Minimum Viable Replacement Modernization Framework
80% of modernizations fail!
Why?
Because they try applying concepts designed for startups to enterprise systems!
So stop trying to replace your critical infrastructure with MVPs!
Instead, embrace the Minimum Viable Replacement Framework!
Read on to learn how to avoid nasty surprises and deliver value sooner!
Why We Need a New Model
Most current methodologies—Waterfall, MVP, Startup 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
Embrace the Technology Adoption Model
While value is important, minimizing the work required to adopt is even more so.
The Technology Adoption Model states that adoption is driven by two things:
Potential Value - Perceived Work
And that the perceived work weighs much more heavily on adoption than value.
Why?
Because there are an infinite number of things we can and should do, but our time, money, and energy is extremely finite, so the less effort the better.
Because there are an infinite number of things we can and should do, but our time, money, and energy is extremely finite, so the less effort the better.
So focus not just on value, but how you can help people be lazy and successful, by stripping away as much initial and ongoing effort to use as possible.
Remember, easier almost always beats better!
Understand Augmentation vs. Replacement
Augmenting is low risk, because you can always use the old system if the new one doesn't work.
Sure, it costs extra to have two systems versus one, but if the extra benefit is worth it, then so be it, which is why we have both a laptop/desktop and smartphone, despite the overlap in capabilities.
Replacing eliminates the cost of owning two separate but overlapping systems, but on the flip side, the risk of value destruction skyrockets.
Why?
Replacing eliminates the ongoing cost of maintaining two systems, but it adds a new variable, the risk of breaking the existing system.
That fear makes us hesitant to change, and value what we have much more than what we might get
The greater the risk for breakage, the more the downside looms and the less important the potential upside.
So remember, how you approach augmentation and replacement are wildly different!
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:
- Expand your MVR to incorporate the requirements to replace everything.
- 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
- Define the different capabilities handled by the existing system
- Score them based on their difficulty.
- Identify user segments based on the capabilities they require.
- Design solutions that address specific slices completely.
- Solve for the easiest segments first.
- Create bridges between phases to maintain momentum.
- Tackle ever more complex segments.
- 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.