In the world of software development, the topic of end-of-life scenarios often remains overlooked. Personal experiences of grappling with closing down products have revealed a stark absence of guidance of case studies to navigate such situations effectively. This series of blog posts aims to fill this gap, drawing from my own real-world experiences across various companies.
Software End of Life Part 1: The Journey to Closing Down a Legacy Product delves into managing a legacy software product closure, navigating challenges and strategies to retire outdated systems and transition to modern solutions.
Software End of Life Part 2: Overcoming Tech Debt With a Complete Rebuild looks at what to do when the burden of tech debt becomes so overwhelming that a complete product rebuild becomes the only viable solution.
Software End of Life Part 3: From Abandonment to Open Source Revival outlines the transformative journey of leveraging open source to breathe new life and opportunity into a product acquired and later abandoned by its new owners.
The persistence of legacy products
Several companies I have worked at had legacy versions of their flagship products that just wouldn’t die. One of these was a learning platform product built in the 1990s on what was then one of the most popular web development frameworks, Coldfusion. It was a profitable product: clients purchased a site, we’d spin up a new instance on the server, apply customer branding and launch it. But the framework didn’t keep pace with the fast moving web development game. Full stack web development moved towards the SQL Server/ASP or MySQL/PHP stacks and it became increasingly difficult to find Coldfusion developers; the few that eventually remained in the market were able to charge a premium which gradually eroded profits on the product line. Open source and SaaS platforms also ate into the market, at which point it became increasingly difficult to sell.
The company decided to bite the bullet at this point and hired me with the task of relaunching the learning platforms business around a newer open source product, while the legacy product would eventually be wound down as contracts expired.
A later company I worked at had built its own web application which eventually evolved into a new version. However many sites were allowed to remain on the old version because not all customers wanted to pay to migrate, and the business wanted to retain those clients because they also purchased other valuable services. So we ended up with a twin track of the product, one in active development and one in keep-alive mode.
Common themes to both of these situations.
Both business invested in building new products, but didn’t really understand the full costs of maintaining the legacy product, such as server infrastructure, specialist staff, training up of system administrators and support work.
The old products were allowed to continue in ‘maintenance mode’, meaning feature development stopped but bugs would be fixed and new browser versions supported. Clients continued to pay annual subscription fees for the legacy product and were encouraged to migrate to the new platform, but this was a cost that they often could not justify spending when they perceived no real value in doing so.
As product team members changed over time, knowledge of the old products was lost, especially relating to the codebase. In both cases we ended up with a single developer with in-depth knowledge of the old system, which was a single point of failure and a huge risk to the business and its customers.
Developers hired to work on the newer flagship platform would inevitably get asked to troubleshoot the legacy platform to keep customers happy. You’d end up with a PHP developer trying to unpick Coldfusion code, or an ASP.NET developer unpicking unfamiliar ASP v1 code. This meant that relatively simple fixes were time consuming and expensive to resolve, not to mention the motivational issues among developers given the crappy task of reverse-engineering and refactoring decade-old code that was not built to modern standards. Nobody wanted to work on this stuff.
So how do you kill that legacy product?
In both of these cases the businesses were obsessed with keeping customers happy, which is no bad thing in itself. But the legacy products were kept alive for far too long. There’s a point at which you need to decide that losing a few customers is a worthwhile thing, to the greater cause of focusing all effort on the new product which will result in greater sales.
There will likely be pushback from influential stakeholders within the business to keep the legacy product going. You can talk about developer motivation and old code until you’re blue in the face, but you’re unlikely to get a decision to kill the legacy product without some cold, hard numbers.
Calculate the costs of keeping the old product alive.
Items will include server infrastructure and developer time spent on bug fixes and maintenance releases. Don’t underestimate the cost of developers having to reverse engineer very old code. Plus you have the cost of training developers, testers, customer support, account managers and other staff on two platforms, as well as time spent negotiating with customers to convince them to move to the new version.
Define the risks to the business.
Point out the single point of failure if only one developer has a deep knowledge of the code base. Old code that is not well supported or maintained will also become a significant security risk over time.
Determine a closure strategy.
The easiest way is to simply not allow customers to renew contracts on that platform, which also allows you to stagger migrations to the new platform rather than migrate everyone at once.
Eventually your business will have to bite the bullet and discontinue the old product. Don’t wait until things reach crisis point, instead push hard to perform this in a planned and graceful manner.