Software modernization projects often start with good intentions, but they can pose surprising (and expensive) risks to software companies. While it might make good business sense to update and improve a legacy software product, your team needs to be careful to keep your next modernization project from going sideways.
Software modernization projects often originate in an older, legacy product that’s been identified as having some perceived limitations. These issues usually include:
- Complaints from customers that the product looks old or doesn’t have modern capabilities.
- Complaints from software company management that “our competition has something more modern and sexy.”
- Complaints from the software development team that don’t want to work on the old stuff anymore; it gets boring. The technology team is often motivated to modernize software so they can have a second chance to “do it right” and make things better.
So with all these good intentions, why do so many software modernization projects go sideways?
Your product modernization strategy–fundamentally how you approach the project as a whole–has a massive impact on whether you succeed or fail. Sadly, most of the time when these projects fail, it’s because the tech team is focused on doing a complete rewrite.
The engineering team is excited: “Great, this is our chance to rewrite and build the product the right way!”
The company rallies around the rewrite, and makes big promises to customers to deliver new, modern bells and whistles: “We understand your requests for enhancements, we’re going to solve this in our next-gen project.”
Then the question comes from customers and company investors: “Great! When is this next-gen product going to be ready?”
And for many of these next-generation software development projects, the answer, unfortunately, is “Never.”
By trying to deliver a complete rewrite of a legacy product, too many development teams get overly ambitious and unfocused, run into unexpected challenges, and ultimately fail to achieve their goals. They miss deadlines and burn through budgets, and the company’s customers never see the modernized product.
Let’s look at a better way to approach software modernization projects, and how your company can deliver value in a more consistent, reliable way.
Speed: The #1 Key to Successful Software Modernization Projects
The biggest success criterion for a modernization project is speed. How rapidly can you deliver value to customers and the marketplace? Speed should be your measure for how you determine how successful any software development effort is. Whether it’s modernization or green field development, measure the rate at which you’ve delivered value to the customers.
Unfortunately, most software modernization efforts don’t deliver new value to customers for years. What happens over those years? Customers have been asking for fixes and enhancements, and they keep hearing from your company: “We’ll fix this in next-gen.”
If it takes so long to deliver, the customer will never see next-gen become a reality andyou will lose them to the competition. Their problems need solving now. Too often, during modernization projects, customers start to feel like you are always saying “No” to them.
“Last year you told us next-gen would be done this year, now you’re saying next year.”
Unless your modernization project is rapidly delivering value to customers, and not just adding more promises to the to-do list, you’re going to run the risk of customer attrition. Customers will walk away.
The “Dirty Snowball” Effect: Escalating Complexity and Risk of Projects that Don’t Deliver
If your software modernization project is not well thought out and set up with a reliable cadence to quickly deliver value, you run the risk of having the project become a “dirty snowball.”
What do we mean by that? Sometimes in software development, as demands keep coming, the project scope keeps increasing. Pressure builds on the dev team. Suddenly, you reach a breaking point where you realize, “We can’t do this. We’re not going to get it done.”
I’ve seen companies light tens of millions of dollars on fire with software modernization projects that go nowhere, and that ultimately have to be shelved. If your team has been working on a rewrite for three years, and it’s not done yet, you have accumulated more technical debt during that time. The stuff you were working on three years ago now needs to be changed. The needs of the market have likely changed. Some things in the back end of your product might have broken.
It’s sad to see, but this is normally what happens with large modernization efforts. Projects can go on for years, and never gain traction in a way that delivers value for customers. The messes, complications, and risks build upon themselves, like a dirty snowball rolling around in the mud.
Don’t let the risks of your software modernization project snowball out of control. There’s a better approach.
Software Modernization Built With Focus, Discipline, and Astute Product Management
When software modernization efforts are successful, they are driven by an absolute laser focus on value delivery. A good project shouldn’t take years; it should deliver incremental value to your customer base or new market segment once a quarter. If you can’t do that, the project is going to fail.
How can you make this a reality? Use an approach based on timeless principles of product management strategy and focused engineering discipline.
Let’s look at an example from the fundamentals of manufacturing physical products. I’ve found that looking at the physical world and understanding what it takes to design, develop, and deliver a product to a market should be where software companies are truly focused. The software world needs to study manufacturing because the basic aspects of product development and delivery aren’t forgotten.
If you’re building a car and it takes five years to build:
- Will the product still be competitive in the market at the end of the five years?
- Will competitors produce a rival product in half the time?
- What if you spend five years engineering a car, pouring a lot of resources into it, paying for lots of skilled labor, and the product has such serious quality problems that when you sell it, it gets returned to you?
- What if you build a car that’s not competitive with other cars on the market?
- What if you build a product and it’s not priced for profitability?
There are huge risks in product development and product engineering. You need to de-risk everything from the pricing model to the amount of money invested, so you don’t over-invest. What if you invest $10 million in a new product and it’s producing $0.5 million per year: should you have done it?
This is not a complicated concept. But sometimes in the software world, these basics of product development get thrown in a memory hole. Everyone in the software world is smart, motivated, and working very hard, but usually, there’s not an end-to-end feedback loop that helps to make sure you’re calibrating the amount of effort and investment as you modernize software.
Here are some product development and product engineering questions that you should ask before you start your next modernization project:
- Are you “putting lipstick on a pig” – updating an old product with modern features? And if so how are you going to monetize that? Note: sometimes this is exactly the right thing to do–sometimes it’s not.
- What’s the net impact on your customer base–what’s the value you’re trying to deliver? Is it a sexy new user interface, API, or more competitive features?
- Think about your end user personas and the different types of user experiences each should have. Does it matter that a low-level hourly data entry person has to work with a less-than-beautiful screen? Do you have to modernize the whole thing, or can you augment what you have and deliver more narrow modern experiences to different people like managers, executives, and stakeholders?
- What should you invest in? You have to put that “investor” lens on when looking at product modernization.
Modularis has a client that is a leading aggregator that buys lots of software companies, and they have a formula for looking at everything through an investor lens. Their conclusion: there’s rarely a solid business case for rewriting a commercial product. Why? The amount of investment it takes, and the amount of risk involved, are not commensurate with the potential upside.
That’s the right approach: think like an investor. If you invest a dollar in software modernization in one quarter, show how it’s creating value for customers the next quarter. For most next-gen projects, if it’s a wholesale rewrite, you have to ask hard questions: “Where is the value in next-gen?” You’ve got to make the economics work. Either get hyper-efficient at the engineering level, to reduce upfront investment in doing this. Or take an incremental modernization approach.
To sharpen your focus on all of this: commit to delivering value to your customer base and the market every quarter. You can’t wait a year or even six months. Now you can say, “Fine, do we have to modernize the whole thing? Maybe a piece at a time.”
Ask yourself:
- What can we deliver in six months?
- What’s going to drive the most revenue?
- Is adding a mobile experience to this legacy application going to give my customers what they want? What about a web experience or a RESTful API?
- Can I make the product more sticky, or more competitive?
- Am I going to put mobile solutions in the hands of workers who mainly do data entry? Probably not, unless it’s for a field like insurance and you need a mobile data solution.
Think it through, and pick off the right pieces for an incremental modernization effort. And remember, if you’re doing a modernization effort, that usually means it’s being done for a legacy product. The legacy product has been successful enough to afford modernization efforts. Maybe it’s your flagship product and it’s solid, but it’s showing its age. The risks of rewriting a flagship product often outweigh the rewards. Don’t be quick to kill the golden goose.
Think Like an Investor: Boost Efficiency of Your Software Development Team
If you look at the total amount of labor you’re investing in software development, most software companies view their software development team as a fixed cost. (“Ah, I already paid their salaries.”) This is absolutely the wrong idea! Your team is not a fixed cost. You should value every engineering hour that someone puts in, whether they’re an employee or contractor. And you should want to get the best labor efficiency out of your labor costs.
If you look at your total software R&D spend: 95% is going to be labor. How much of that engineering time, investment, and budget is going toward innovation (new value, features) vs. keeping the lights on (maintenance)? Mostly we discover that 80% of that time is spent on maintenance, and 20% is spent on innovation. This is the “innovation fraction.” We find, on average, only 20 cents out of every dollar spent on software development is delivering net new value to your customers and driving new revenue.
If you’re spending 80% of your time on maintenance, you have to ask why. This is part of the modernization discussion: sometimes people assume that “the next-gen will be easier to maintain.” Yes and no. It’s too simple to say that the new thing will be easier to maintain.
How much of that 80% maintenance is truly necessary? Of course, some maintenance is normal. But your target should be 20%. Then you can swing a good chunk of that maintenance effort to innovation by using low-code software development, and by making the choice to build new features on new technologies and integrating those new technologies with your existing technology stack.
No Purity Tests: How to Build New Features in a Modernization Project
One challenge for modernization projects is that engineering teams sometimes impose “purity tests” on the development approach. If you want to build a new feature, your engineering team might say, “We’re going to build this new thing in the context of rebuilding everything. We’re going to build a whole new foundation and put the new feature in there.” That’s the type of all-in, next-gen project that’s likely to fail.
Or you can say: “We’re going to build this new screen/feature/API in the old technology.” With any legacy product, no matter how well written, parts of it will turn into technology debt. This technical debt is not a bad thing in itself, but it has to be managed and “refinanced.”
There are typically two options that teams use to decide how to tackle a modernization project:
- Option A: Rebuild the whole thing – and then put new features in.
- Option B: Work within the constraints that you have – and implement new features in the old technology stack. This option usually takes longer. There’s more technical debt involved as it adds to the old technology assets and becomes something that you later have to modernize further. It potentially adds to the technical debt. But at least you don’t have to wait for the ‘next-gen’ project to be complete before giving it to your customers.
Don’t have a purity mindset. Purity doesn’t equal financial success in a modernization effort. Instead, be pragmatic. Choose to build new features in new technologies (and still be ready to do some maintenance in the existing technology set).
Be flexible on a case-by-case basis. Don’t be a purist about it. It depends on the situation. If you need a new screen, interface, dashboard, or API, there are modern ways of getting there that allow you to make use of the strengths of your legacy application, but pivot to new stuff in a new technology stack and link it to your legacy tech stack.
This pragmatic approach helps you increase your development efficiency and velocity – engineers can work faster in a new technology stack. And this is the key to delivering incremental value to customers. You’re no longer having to tell customers that they have to wait till the next-gen is ready; instead, you can slot it into your product roadmap, and say, “It’ll be ready in Q3.”
Don’t take a Big Bang approach. Instead, take an incremental approach. This will help you take a lot of risk out of the software modernization project and drive more net new revenue faster, by delivering value incrementally at a faster rate.
Step back: why did you start the modernization effort? The legacy product didn’t do everything customers wanted, didn’t have a mobile version, didn’t have an API easy to access, etc. You can fill these gaps incrementally. Even if you leave your legacy product alone, maybe it looks old. Often, these flagship products might look a little old, but they’re highly effective and efficient, and customers like them just fine. Now you’ve added to it these modern elements – mobile, web, portals, APIs, integrations – and you can do it one piece at a time, without the risks of a rewrite.
If you step back and look at the surface area provided by all these capabilities: the portion of that picture that looks “old” has gotten pretty small. It solves the perception problem about your product without having to rewrite the whole thing, without having to take a lot of risk, and without having to endure customer attrition.
That’s the right way to think about modernization efforts. It’s about choosing to build new capabilities in new technologies. You don’t have to reinvent your legacy product, and you don’t have to try to make your legacy tech stack do too much. Next time you’re considering a software modernization project, choose the path of less risk, and a faster cadence and frequency of value delivery.
Find out if you’re ready to tackle your next software modernization project
Try our free Tech 360 self-assessment to see if your existing team and tech stack are ready to tackle your software modernization project! This tool has helped countless businesses turn their software R&D bench into a revenue-generating engine, and it can do the same for you. Schedule a 1:1 with our CEO, A.J. Singh to see how you can unlock 80% more innovation in software development and get the workbook for free.