The wisdom of a minimum viable product (MVP) is well established in technical circles.
When building a product, we all know we should remain agile and launch something small and simple to start. Then over time, we can make that product more nuanced by adding more features over time as previous features prove their value.
Unfortunately, the same process wreaks havoc when it comes to modernizing an existing system. At first, the reason why is not intuitive. In theory, the same principles should apply: Start with small and simple use cases to upgrade and build upon your success. Certainly it’s true that 10-year migration plans never work out well, but defaulting to an agile MVP can bring just as much bad luck to a project as traditional waterfall development.
Product Development vs. Modernization
The difference between product development and modernization is the hypothesis you need to prove from sprint to sprint.
With product development, you’re trying to prove that people will use the technology. With modernization people are already using the system, and often have no choice about it. Legacy systems are, after all, successful systems — and successful systems tend to alter the process and environments they’re built for so that we retire the old ways of doing things and become dependent on them.
Instead, the hypothesis we’re trying to prove when we’re modernizing a system is that the updated technology will do a better job than the old version we’re leaving behind. There are a lot of reasons why that might not be the case.
3 Cases When Modernizing Your System Might Not Be an Upgrade
- There might be some complex flow or requirement that the new technology has no solution for.
- The new technology might be optimized for different priorities and we might find ourselves on the wrong side of a trade off with security, performance or consistency.
- Our use of the technology might reveal an edge case the industry hasn’t seen yet and trigger undesirable outcomes.
The use cases that seem like the simplest and the most likely to be identified as MVPs are also the parts of the system that no one cares about. We don’t modernize systems that aren’t being used. We turn them off.
The problem is, modernizing systems that are being used is pretty hard. So when people are asked to think about an MVP for a modernization, the challenge of migrating a set of functionality to new technology without complications or downtime is perceived as part of the scope in determining the minimum.
When Validating Migration, Raise the Stakes
I’ve seen many companies start a migration to Kubernetes by migrating their documentation sites, then act surprised when that success does not inspire enough confidence for critical business systems to sign up to move over.
Putting the least important set of functionality on a new technology violates the spirit of an MVP. It does not validate that the modernization effort can add value. It would be the equivalent of a product-development effort deciding their MVP was the login page. Sure, your team might be able to successfully launch it, but did we learn anything about whether the project itself is valuable?
The beginning of a modernization effort is a precious period, so don’t waste it. This is the time when the team has the most excitement, the most momentum, the greatest level of stakeholder buy-in and the most money and staff. When people conflate minimum with simple, they squander a critical stage of the effort.
Migrating part of an active system that isn’t important or that fewer people are using is definitely simpler than migrating a critical part of the same system, but the rationale behind MVPs is that they should validate the benefits of the product being developed. If you start with the simplest parts of a migration, you haven’t validated that the migration will behave correctly on the parts of the system that are actually important.
That’s why I tend to gravitate toward starting migrations with the harder parts of the system. It’s a more challenging project, yes — but you will never have more resources and more support for a modernization effort than you do in the very beginning. The hard bits won’t be any easier months or years later.
Build the Right Staging Environment
When you successfully migrate a hard part of the system, you’ve proven that the modernization itself can add value in the same way a MVP validates the effort of building something new.
Conquering a hard part of the system tends to inspire stakeholders, especially if other modernization efforts have failed in the past. Sometimes this enthusiasm takes the form of increased moral support for the team, but it can also lead to more resources and more favorable prioritization.
Of course, in order to start with something hard right away, I need to have the right environment. When a new system goes live, it’s normal for there to be small bugs that pop up as the gears turn for the first time. I need a staging environment that’s as close to a carbon copy of production as possible.
I also need an engineering team that embraces thorough and comprehensive testing practices. They should write integration tests, yes. They should write unit tests when appropriate, yes. But they should also be prepared to figure out what parts of the system should be tested with the assistance of a fuzzer. They should do live failure tests, particularly around the migration plan itself.
If we can’t do these things, then by taking on a hard part of the system we are forcing ourselves to tackle both the simple bugs that are found the first time a system runs and the complex bugs found when making changes to interactions with a lot of downstream dependents at the same time.
We need to feel confident that we can eliminate as many of the first-attempt bugs as possible through testing before we green light the actual migration on production. If we can’t do that, then we should migrate an easy part of the system first in order to get through the bugs and tackle the hard parts as soon as we can.
The Takeaway
A modernization project hasn’t proven its value until it has successfully migrated the important (read: hard) parts. MVPs are useful because they validate that a project is worth doing before we’ve wasted a lot of time and money on it.
For that reason, the right MVP for a modernization effort is often a complex part of the system. If you pick an easier part, you will waste time, money and political capital doing work that does not prove to the organization that this new technology can be trusted with their most critical business functions.
