This article is focused on business software. It might automate processes, integrate data from multiple sources, or provide dashboards / portals for access to information and insights.

This software is critical to running your day-to-day operations.

As such, changing this software can be disruptive.

This might cause you to want to hold on to the software as-is, past its prime.

The problem is that delaying a rewrite too long could result in:

1. loss of competitive advantages,
2. decreases in productivity, or
3. increased risk.

Identifying when to rewrite your software is important.

Common triggers for rewriting software.

Do you have any of these challenges with your current software?

1. Integrating with other internal or external (vendors, customers, third party providers) systems is challenging.
2. Security concerns – such as vulnerabilities in public-facing web applications or applications that must be run on out-of-date operating systems with known security exploitations.
3. Being technologically backed into a corner.  Your existing software is incompatible with newer operating systems or applications.
4. Accessibility.  Your application is not easily accessible outside the office.
5. Your application is frustrating to its users.
6. Your application requires more training to use than you’d like.
7. Your application requires more effort to use than you’d like (e.g. It seems like your team has to search within 5 different screens to find information that should all be readily available from one place).
8. The external appearance of your application is making you look bad as an organization.
9. Development stack vulnerabilities: Is the development stack of your legacy application secure?  Is it still being updated to protect against modern threats?
10. Development stack relevance: if your application was developed in an older platform, there may not be a large enough pool of developers or technical staff able to support it.

Definitions: rewrite vs migration vs modernization vs refactor

Defining adjacent terms can help clarify what we mean by rewrite.

Rewrite – a process where the old application is completely abandoned, and a new application is developed to replace the legacy application, often with enhanced capabilities

Migration – a process to slowly move the functionality from the legacy application over to the new application. This process is done in phases, where the legacy application is still responsible for certain aspects of operations, but that burden is gradually shifted from the old application to the new.

Modernization – a process of improving the UI and adding improved functionality to an application.  This option is only viable if the technology stack of the legacy application is supported, and the application is satisfactorily handling the majority of the organization’s needs.

Refactor – a process employed by developers to edit their code after the initial draft is functioning.  This involves renaming variables, improving efficiency, implementing error trapping and adding comments.

Gotchas / risks (and corresponding tips) when rewriting software

Underestimating the complexity of the legacy application

Users often become so accustomed to how an application functions, that they sum up its functionality in a few sentences.  The reality is that sometimes those sentences translate into days, weeks or months of development time.

Many of these complexities are brought to light once you get into the requirements collection phase of development. It‘s helpful to put together a comprehensive list of the functions your existing application performs to get a more complete picture of what it needs to do going forward.

A few questions to get you thinking:

1. How many user roles or types of user are there?  Different user roles use the system differently.  Identifying the necessary functions for all user roles is critical. 
2. How does the work of one user impact other users throughout the system?  For example: a system has to be designed to allow customer service to enter an order.  But how does that order impact the users in manufacturing?  In the warehouse? In shipping, etc.?
3. Reporting needs.  Reports are sometimes taken for granted.  What reports are needed to operate your organization?
4. System Integrations.  Is there data transferred between external systems like EDI (electronic Data Interchange), accounting, HR systems etc.?  Identifying what and how that data needs to be transferred is important.  Note: many times, this is an opportunity for improvement when modernizing a legacy system.

Data migration – cleansing

Data ages.  Over time the data collected can change.  More specific values can be captured now versus what could be captured in the past.  Mobile cell numbers, email addresses, more specific names can all be examples.  As a result, older records may lack the necessary information to be successfully migrated into a modern platform. 

The adage “garbage in… garbage out” comes into play here. 

It’s important to identify what data is best migrated to the new application.  You’ll want to identify how far back you want to transfer your data and then evaluate the quality of that data before moving forward with the migration. Being pragmatic about what can be migrated ahead of time will save time and headaches later.

Get buy-in. Don’t assume everyone’s onboard

Change (even for the better) can often be met with resistance. People tend to become comfortable with the way they do their jobs. Even if it involves needless extra steps. 

Staff buy-in to a new approach is important.

Review current inefficiencies and work with the team to plan how to improve their processes. This can help get the team excited about the coming improvements.

You don’t want to roll out a process that’s a step backward for the team.

Same vs similar but better

When deciding to rewrite software it’s a common mistake to set out to develop the system to do exactly what the old system did.  While you certainly don’t want to leave out critical functionality, rewriting software is an opportunity to make improvements to the process, or user experience.

Modern platforms and techniques offer opportunities for automation, integration and analysis.  Looking at the process or problem with a fresh set of eyes can yield significantly better results.

It’s important to identify the functionality that needs to exist, but also look at its limitations. Consult your team for processes that just “don’t make sense”.  Some ideas may not be realistic, but many can be implemented in newer systems. This can result in significant efficiency and user satisfaction improvements.

Underestimating the time demand on staff.

The software dev team will need significant input and time from stakeholders in order to deliver a quality product. Some of the more common items that developers will need input from stakeholders on:

1. User Story or system requirements development.
2. Wish list: a list of functions the users would like to be included.  Another approach is to present the list of problems users are facing, with the goal of identifying an elegant software solution.
3. QA/UAT: Testing.  The development team can perform in-depth testing, but the users will need to participate and confirm that the application is ready to be deployed into a production environment.

It’s important to anticipate the time demand on your staff and adjust their daily burden to allow them to put the necessary time into working with the developers to build a quality solution.  When done well, this can yield a significant return.

When not to rewrite your software

The two main factors you’ll want to consider when deciding whether or not to rewrite your software are:

1. ROI
2. Risk

ROI

Software development is an intense, and sometimes time-consuming process.  Before making the investment, you want to identify the return and compare it to the investment.

Keep in mind the return on software can be justified in many ways such as:

• improved efficiencies that yield lower costs,
• improved customer experience, or
• improved analytics data.

If the software rewrite will only provide marginal return, it may not be worth it.

Risk

Legacy software can expose significant risks to an organization, such as:

• security vulnerabilities (viruses, hacks, etc.)
• ongoing support concerns (support has been sunset, or inability to run the application on newer platforms). 

A thorough evaluation of the risks of your application is important.

If your current system is functioning at a high level, has no security or feasibility concerns on the horizon, and will not provide significant benefits from new features, then the cost of a rewrite or migration may not be worth the investment. 

Alternatives to rewriting your software

Are the any useful alternatives to rewriting your software besides doing nothing?

Yes.

The main alternative is to evaluate off-the-shelf options. With enhancements in technology and the explosion of SaaS Solutions, there may be a viable solution that can be configured to meet most, or all, of your goals.

Primary cost drivers for software rewrites

The primary cost drivers for software rewrites include:

1. Lack of clear requirements
2. Data migration
3. Skilled labor

Lack of clear requirements for what the software needs to do

 It’s important to have a good understanding of how the application should behave. It may not be necessary to know all this before starting the project, but you’ll want to understand this before development of a particular function begins. Changing the desired functionality is like hitting a moving target. It can take multiple attempts to finally hit the mark, and that can be costly.

Data Migration

Many times, when an application is rewritten, the structure of that data changes. When this happens, mapping the data from the old application to the new can be challenging, but critical.  Factor in the reality that some old data may not be in the best shape, and that can increase time and cost.

Skilled labor

The old adage… “You get what you pay for” applies. Software development is a complex skill. As a result, the services of those who know how to do this work well can be expensive.

Software Rewrite project examples (case studies)

How to get started

1. Review your current system:
2. Find out if it, or its development stack and hosting platform are still being supported and if there are any announced sunsets scheduled.
3. Confirm that your system has the most recent updates.  How long ago were those updates released?  If it was quite a while ago (e.g. > ~2 years), that can be a red flag.
4. Start identifying what you’d like to be able to do:
5. Ask your staff if they find anything inefficient.  Are they maintaining spreadsheets to track additional data that their system does not?
6. Do you get complaints from outside customers / vendors?
7. Are there other systems that you would like to integrate with, but can’t?
8. Reach out if you’d like help rewriting your software or if you’d like help assessing your situation.