This article is focused on business software — the kind that automates processes, integrates data from multiple sources, or provides dashboards and portals that give your team access to information and insights.
Software like this is critical to running your day-to-day operations. That also means changing it can be disruptive — and the fear of disruption can tempt you to hold on to the software as-is, well past its prime.
The problem is that delaying a rewrite too long can lead to:
- Loss of competitive advantages
- Decreases in productivity
- Increased risk
That’s why knowing when to rewrite your software matters.
Common triggers for rewriting software
Do you recognize any of these challenges in your current software?
- Difficult integrations. Connecting with other internal or external systems (vendors, customers, third-party providers) is a struggle.
- Security concerns. Vulnerabilities in public-facing web applications, or applications that must run on out-of-date operating systems with known security exploitations.
- Being technologically backed into a corner. Your existing software is incompatible with newer operating systems or applications.
- Limited accessibility. Your application is not easily accessible outside the office.
- User frustration. Your application is frustrating for the people who use it every day.
- Heavy training burden. The application requires more training to use than you’d like.
- Too much effort to use. For example, your team has to search across five different screens to find information that should all be available in one place.
- A dated appearance. The external look of your application is making your organization look bad.
- Development stack vulnerabilities. Is the development stack behind your legacy application secure? Is it still being updated to protect against modern threats?
- Development stack relevance. If your application was built on 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 a few adjacent terms helps clarify what we mean by a rewrite.
Rewrite — the old application is completely abandoned, and a new application is developed to replace it, often with enhanced capabilities.
Migration — functionality is moved from the legacy application to the new one gradually, in phases. The legacy application remains responsible for certain aspects of operations while that burden steadily shifts to the new system.
Modernization — the UI is improved and enhanced functionality is added to the existing application. This option is only viable if the legacy application’s technology stack is still supported and the application is satisfactorily handling the majority of the organization’s needs.
Refactor — a process developers use to clean up their code after the initial draft is working: 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 works that they can sum up its functionality in a few sentences. In reality, those few sentences can translate into days, weeks, or months of development time. Many of these hidden complexities only surface during the requirements collection phase. It helps to put together a comprehensive list of the functions your existing application performs so you get a complete picture of what the new system needs to do.
A few questions to get you thinking:
- How many user roles or types of user are there? Different roles use the system differently, and identifying the necessary functions for every role is critical.
- How does one user’s work impact other users throughout the system? For example, a system must let customer service enter an order — but how does that order affect the users in manufacturing? In the warehouse? In shipping?
- What are your reporting needs? Reports are sometimes taken for granted. Which reports do you actually need to operate your organization?
- What system integrations exist? Is data transferred between external systems such as EDI (Electronic Data Interchange), accounting, or HR systems? Identifying what data needs to move and how is important — and this is often an opportunity for improvement when modernizing a legacy system.
Data migration – cleansing
Data ages. Over time, the data you collect changes: more specific values can be captured now than in the past — mobile numbers, email addresses, more precise names. As a result, older records may lack the information needed to migrate successfully into a modern platform.
The old adage “garbage in, garbage out” applies here.
It’s important to identify which data is worth migrating to the new application. Decide how far back you want to transfer your data, then evaluate the quality of that data before moving forward. Being pragmatic about what can be migrated ahead of time saves time and headaches later.
Get buy-in. Don’t assume everyone’s onboard
Change — even change for the better — is often met with resistance. People get comfortable with the way they do their jobs, even when 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 their processes will improve. This helps get the team genuinely excited about what’s coming. The last thing you want is to roll out a process that feels like a step backward for the people using it.
Same vs similar but better
A common mistake when rewriting software is setting out to build a system that does exactly what the old one did. You certainly don’t want to leave out critical functionality — but a rewrite is also an opportunity to improve the process and the user experience.
Modern platforms and techniques open up opportunities for automation, integration, and analysis. Looking at the problem with a fresh set of eyes can yield significantly better results.
Identify the functionality that must exist, but also examine its limitations. Ask your team about processes that just “don’t make sense.” Some ideas won’t be realistic, but many can be implemented in newer systems — often resulting in significant gains in efficiency and user satisfaction.
Underestimating the time demand on staff
The development team will need significant input and time from your stakeholders to deliver a quality product. Some of the more common items developers need stakeholder input on:
- User stories or system requirements. Developing and refining what the system must do.
- The wish list. A list of functions users would like to see included. Another approach is to present the list of problems users are facing, with the goal of identifying an elegant software solution.
- QA/UAT testing. The development team can perform in-depth testing, but users need to participate and confirm the application is ready to be deployed to production.
Anticipate the time demand on your staff and adjust their daily workload so they can put in the time needed to work with the developers on a quality solution. Done well, this yields a significant return.
When not to rewrite your software
The two main factors to consider when deciding whether or not to rewrite your software are:
- ROI
- Risk
ROI
Software development is an intense, sometimes time-consuming process. Before making the investment, identify the return and compare it to the cost.
Keep in mind that the return on software can be justified in many ways, such as:
- Improved efficiencies that lower costs
- An improved customer experience
- Improved analytics data
If a rewrite will only provide marginal return, it may not be worth it.
Risk
Legacy software can expose an organization to significant risks, such as:
- Security vulnerabilities (viruses, hacks, and similar threats)
- Ongoing support concerns (support has been sunset, or the application can’t run on newer platforms)
A thorough evaluation of your application’s risks is important.
If your current system is functioning at a high level, has no security or feasibility concerns on the horizon, and won’t gain 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 there useful alternatives to rewriting your software, besides doing nothing?
Yes.
The main alternative is to evaluate off-the-shelf options. With advances in technology and the explosion of SaaS solutions, there may be a viable product 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 are:
- Lack of clear requirements
- Data migration
- Skilled labor
Lack of clear requirements for what the software needs to do
It’s important to have a solid understanding of how the application should behave. You may not need to know everything before the project starts, but you do want clarity before development of a particular function begins. Changing the desired functionality mid-stream is like hitting a moving target — it can take multiple attempts to finally hit the mark, and that gets costly.
Data migration
When an application is rewritten, the structure of its data often changes. Mapping data from the old application to the new one can be challenging, but it’s critical. Factor in the reality that some old data may not be in the best shape, and time and cost both go up.
Skilled labor
The old adage “you get what you pay for” applies. Software development is a complex skill, and the services of people who do this work well can be expensive.
Software Rewrite project examples (case studies)
Custom Web App facilitates design process — legacy software migration collaboration
Legacy Software Update — support, then full rewrite — auditing software
Custom Legacy Software Update — support, then modernize in-place
Custom Business Process Automation Software — time tracking and reporting
You can browse these and other projects on our case studies page.
How to get started
Review your current system:
- Find out if the system — or its development stack and hosting platform — is still being supported, and whether any sunsets have been announced.
- Confirm your system has the most recent updates. How long ago were those updates released? If it was quite a while ago (more than roughly two years), that’s a red flag.
Start identifying what you’d like to be able to do:
- Ask your staff what they find inefficient. Are they maintaining spreadsheets to track data their system doesn’t?
- Do you get complaints from outside customers or vendors?
- Are there other systems you’d like to integrate with, but can’t?
Reach out if you’d like help rewriting your software or help assessing your situation.
Ready to move off of Access? Check out these Access Conversion Case Studies
If you’re considering a move away from Microsoft Access, our MS Access conversions service covers the full process. Related reading: