Strategizing a Legacy Software Overhaul: A Case Study on Modernizing and Rewriting Software

Mike bought a piece of legacy software. It was written with a general purpose CMS (think WordPress, Joomla!, etc) and grew quite complex over 15 years of existence.

A lot of systems were custom built, such as analytics, customer support, ticketing system, newsletter systems, and other miscellaneous features.

The sale came with an existing dev team, existing employees, and a considerable user base who know this application very well.

Mike’s idea after buying this was to make some changes, make it look prettier and more usable in order to improve conversions and sales.

After a couple of years he intends to flip it for $5mm-$8mm profit.

Here be dragons

However, it’s old and clunky. Some changes take a long time, but are not necessarily expensive with the rates he gets with the current dev team.

Mike starts to think about rewriting this in a modern stack.

Questions Mike considers:

1. Do I keep making changes to this old application?
2. Do I rewrite the whole application?
   1. One dev agency said to rewrite all at once
   2. Another dev agency suggested a step by step rewrite

Do I keep making changes to this old application?

Facts:

• The application has users and generates cash flow
• Some of the users have been around since the beginning
• There is significant ad-spend
• It’s hard to retain new users with its current UI/UX

Pros

1. You don’t make drastic changes that alienate current users
2. You let this application generate the cash it generates

Cons

1. You risk stagnating with outdated technology
2. The difficulty of implementing new features or updates could increase with time
3. Potential security risks due to obsolete software components
4. Losing competitive edge to more modern and user-friendly competitors
5. Increased maintenance costs over time

Do I rewrite the whole application in one go?

⚠️Big warning: I have NEVER seen a full one-go rewrite done right (on time or on budget). It’s very hard to do it right, as it has to be treated like an entirely new application.

The question of rewriting the entire application is a complex one and comes with its own set of advantages and challenges.

Pros

1. Modernization: Using up-to-date technologies and practices, the application could be faster, more secure, and more scalable.
2. Improved UI/UX: A full rewrite allows for a total redesign of the user interface, possibly improving user retention and satisfaction.
3. Potential for Growth: With a modern architecture, the application could more easily accommodate new features and integrations, keeping it competitive.
4. Long-term Maintenance: Modernized code would be easier to maintain, debug, and extend in the future, potentially saving costs in the long term.

Cons

1. Time-Consuming: A complete rewrite can take significant time, leaving the existing application to age further.
2. Expensive: Even with Mike’s considerable budget, a full rewrite could quickly become costly.
3. A complete rewrite means you now have two apps:
   1. The old application will need ongoing maintenance, potentially even new features here and there
   2. The new application will be in dev mode for months before a single user even sees it
   3. Are you going to pay for two teams?
4. Risk of Losing Current Users: Drastic changes might alienate the existing user base, especially those who have been around since the beginning.
5. Potential Loss of SEO Ranking: Redesigning the whole website might lead to a temporary loss in SEO ranking and organic traffic.

Step-by-Step Rewrite

A step-by-step rewrite, as suggested by another development agency, could offer a balance between these extremes.

Pros

1. Incremental Improvements: Users can benefit from gradual enhancements without being shocked by a complete overhaul.
2. Reduced Risk: By rewriting in stages, the team can assess the impact of each change, reducing the risk of a negative reaction from the existing user base.
3. Financial Flexibility: Spreading the rewrite over time might allow for better budget management.
4. Your software is always in a usable state: If you want to scale down IT costs to $0, you will always have a usable application. If you decide to rewrite in one-go, you could end up with half-baked stuff
5. Less waste: You build stuff and put it in front of users much faster; Instead of long-running development that nobody uses, which creates some dangers. See: ”Why you should expose your product to the market ASAP”

Cons

1. Long Timeline: While mitigating some risks, a gradual approach might extend the overall timeline
2. Compatibility Challenges: Ensuring that new components work seamlessly with legacy parts might prove to be technically challenging and time-consuming.

Conclusion

This is a lengthy process regardless of what you choose. I tend to recommend a gradual rewrite. It’s less risky and you can always stop if you see it’s not working out, or if you need to scale down development costs due to changes in revenue, etc.

It’s a sensitive subject and has to be taken on a case-by-case basis. The constraints and parameters of your specific case have to be carefully measured and assessed.

The more time and money you spend on research and discovery to map out what your current application truly is: The more likely a full rewrite is to succeed. Full-on discovery and full-on rewrite.

The less you spend on research and discovery: The more likely a gradual rewrite is to succeed. gradual means you discover as you go. Gradual discovery and gradual rewrite.

The worst is to go for a full one-go rewrite and gradual discovery. That’s a recipe for disaster. and sadly the one I see most dev agencies make. They sell you on a full one-go rewrite, but they don’t do the research to make it a success. The longer you’re with them the more they net! So the incentive is skewed.

A full rewrite is a big bet. A gradual rewrite is a series of small bets.

⚠️Big warning: I have NEVER seen a full one-go rewrite done right (on time or on budget) in an SMB. It’s very hard to do it right. It has to be treated like an entirely new application. Research must be done to dig into every little bit of functionality that has been made over potentially decades of development.

I’ve heard “Oh but we assumed […] many times”.

Some functionality can be outsourced and not built again, such as:

• newsletter system
• Customer support systems
• analytics
• ticket system
• Other systems that are not core to your business

You only get good at this when you’ve spent $1mm+ on mistakes doing it wrong. (ask how I know!)

Do you need to make this decision? I offer fractional CTO services for businesses like yours. If you have hard problems you want to tackle but feel your organization lacks the perspective to tackle fully, get in touch! I guarantee to ask very hard questions that lead to solving hard problems.

• Read next:

  Fractional CTO services for business owners

• Previous Article

  Test your revenue projections with this metric

• Next Article

  Startup Red Flags: An Engineer's Perspective