Imagine if Amazon did not evolve its technology to become the technology powerhouse they are today and instead kept it like it was in the 1990s. It would be a very interesting situation indeed, and likely, they would also have been long gone. Technology and business must evolve together!
Legacy is accumulated code and older platforms that have not properly evolved at the speed of technology to accommodate the changing business needs. The code that is written today eventually becomes a legacy. That’s a fact. At the current speed of technology, this happens sooner today than it did 10 or 20 years ago.
Legacy poses real risks for companies, notably visible with the increased cost of maintenance, inability to add customer value (e.g., features), and finding talent to maintain or evolve the software. However, even more importantly, legacy software can significantly limit the go-to-market speed and the ability of a company to compete.
A company with legacy software is effectively inviting competitors and disruptors to become a threat and risks eventual talent and customer attrition.
The bottom line is that software legacy can and will eventually get in the way of business, and a strategy must be developed to mitigate or decidedly choosing not to invest in certain situations.
In this blog, we will focus on defining what legacy means. How did it get there? And whether modernization is the right move. These are the three most difficult questions posed by executives and investors, and no two situations are alike.
3 Steps Playbook to Begin the Journey
There is no simple solution to legacy, but luckily there are some proven approaches from those who achieved success and best practices that can help mitigate legacy. Each can be appropriate depending on the situation. Here is the playbook:
Determine the Current State: Assess and understand the challenges and root-causes
Figure out the Future State: Start with the business rationale and decide to path
Make a Calculated Decision: Choose the best approach that has the least investment
Determine the Current State. Understand Root-Causes
To make the best decision about the future, one must first understand the current state.
Oftentimes, the root causes are a matter of complacency (i.e., cash cow syndrome), limited appetite/resistance for change and staying within the comfort zone, or the absence of strategic planning.
Many successful organizations find themselves in those situations. The most common root causes though are typically a broken strategic planning process, lack of alignment, limited proximity to end-users and market view, or a lack of technical leadership representation in the business strategy (i.e., no seat for technology at the table).
A company that builds software has to take into consideration a holistic “Engineering System” which comprises Strategy, People, Process, and Technology. Legacy situations are often a symptom of the strategy and organization rather than the technology itself.
The challenges with old, neglected code and platforms are many and situationally specific. Explore these common examples to help you identify the root causes.
The Quality of legacy code, especially if it has been around for years and maintained, is usually stable and most likely may be high-quality. While this is not always the case, it is more than often expected if it has been well-tested and cared for over the years. That does not guarantee the future though, but it could be the base of wrapping the legacy code and building modern services around.
Security is a massive risk. The reality is the world of technology is constantly moving, and legacy applications have to invest more just to keep up with security threats.
The Scenarios and Use Cases may be less relevant today than they were when the product was built. A product that was, for example, developed 15 years ago may very well have dead code and scenarios that are no longer applicable, but they are still alive in the code consuming regular investment and cost drain.
The Organization with a big legacy typically lacks fresh talent. Over the years, it was optimized for maintenance rather than building new products and new technologies, so these muscles were not well exercised. Maintenance mode vs. new product mode are two very different mindsets and often require different talents.
Leadership is also very different. We coined (or borrowed from the Godfather movie) the term war-time CTO vs. peace-time CTO as an analogy for a leader who is skilled at maintaining a product and incrementally evolving it vs. leadership who has transformation experience.
The Intellectual Property may have shifted. While the code itself may have once been the IP, that could have shifted to other aspects such as data, integrations ecosystem, or even the deployment approach. Intellectual property is not static!
Talent to maintain old technologies is scarce and increasingly difficult to recruit, and developers are cautious not to be stuck in legacy to avoid impacting their careers.
Companies often seek the help of a neutral third-party advisory to get a very crisp understanding of the current state and strategy. This exercise is not only useful to uncover hidden challenges but also is often useful to the team and provides alignment.
Figure Out the Future State and Business Rationale
Modernizations are often viewed as a distraction from the core business, and often they are, if not aligned with the business needs. Transformations are an investment that is difficult to justify to the board, investors, and executives.
Getting absolute clarity on the key business goals, rationale and taking a longer-term view is the only way to justify the investment.
As a person who has spent most of their life developing and managing large-scale software and teams, I will be the first to admit that software is ultimately a tool to support a business or a cause. It is not about perfection unless perhaps you are an academic research institution.
The tactics involved in dealing with legacy should focus on the minimum investment possible to be modern, reduce costs, stay efficient, and improve quality for the end-users. This mindset will guide you to the most suitable choice to deal with legacy.
All of those factors play into the decision to modernize. It’s ultimately the balance when the maintenance investment is no longer possible, or the opportunity loss cost from limited go-to-market ability is too great. This justifies a move to limit the negative return. Depending on the company size and stage, a good rule of thumb warning for an established business is when the yearly average maintenance R&D spend from revenue is broadly larger than 35%. It’s the red zone!
Decide. Choose the Approach with the Least Investment
Before deciding what to do, here are the top 10 questions and considerations that should be explored with the engineering team when deciding on the next steps.
Is this product core to the business strategy?
What percent of revenue does that product constitute for the business?
Will the product be alive for 3+ years?
Would the underlying technology be extinct in 5 years and difficult to recruit for?
What is the approximate percentage of dead or non-used code?
Is there a major risk of losing customers after an upgrade?
Any quality, performance, or scalability issues that cannot be easily fixed in the code?
Are there major go-to-market or efficiency gains achieved by modernization?
Are there open-source alternatives or 3rd party products that can be leveraged?
Would the modernization strategy reduce the total cost of ownership by 20%+ yearly?
After exploring the questions, you will have a better idea of the right path and have to decide between the four options.
Do Nothing: Resolve to maintain the product. This can be a business justification based on the return on investment. Note that it is not a technical question!
Keep, but Address Some Pain Points: Based on the strategy, the solution can often be a simpler one to just outline the key technical debt needed to address instead of a large investment. The R&D cost may remain higher than optimal, but it eliminates the risk of having to embark on a major risky transformation.
Keep and Build-Around: If the core of the code base is high quality, another option is to wrap the code and build modern services around it or modernize smaller parts of the platform or deployment (e.g., moving from bare-metal to VMs or Docker containers in the Cloud) to reduce costs, eliminate pain points of enabling new business scenarios.
Transform and Modernize: This is by far the riskiest option and requires yet another evaluation and another decision. Modernizations are risky and require staying the course with a long-term vision in mind. They require transformation-experienced leadership. Explore the various options to identify which is best for the situation. A word of caution is to decide whether it is an incremental or a big-bang format. In our experience, a big bang approach, while attractive at first sight and even logical, is often a bad idea and often results in failures. However, a small parallel effort can be successful if managed well and focused on the business priorities.
Transformations and dealing with legacy is one of the most difficult decisions made by businesses and governments today. Whether motivated by security, profits, or customer needs, the plan has to be well thought out, and the execution cannot be taken lightly.
About the Author
Hazem has been in the software and M&A industry for over 26 years. As a managing partner at RingStone, he works with private equity firms globally in an advisory capacity. Before RingStone, Hazem built and managed a global consultancy, coached high-profile executives, and conducted technical due diligence in hundreds of deals and transformation strategies. He spent 18 years at Microsoft in software development, incubations, M&A, and cross-company transformation initiatives. Before Microsoft, Hazem built several businesses with successful exits, namely in e-commerce, software, hospitality, and manufacturing. A multidisciplinary background in computer engineering, biological sciences, and business with a career spanning a global stage in the US, UK, and broadly across Europe, Russia, and Africa. He is a sought-after public speaker and mentor in software, M&A, innovation, and transformations. Contact Hazem at hazem@ringstonetech.com.