This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
At UDig, many of our customers rely on custom software to run some part of their business. We work with companies on all ends of the custom software spectrum. From those whose software originated in the 1980s, when buying an off–the–shelf product was not an option, to those who have grown their business in a modern SaaS environment and have written custom software to extend, enhance, or integrate the various platforms that they rely upon. Regardless of what mix of software your company uses, your organization has likely found itself, at some point, questioning whether it makes sense to replace or rewrite some part of that software. There is much debate around whether choosing to rewrite a piece of software is a good idea or not, but this article is not another attempt to weigh in on that decision. Instead, this article assumes you have already made that decision and are ready to embark on the journey of rewriting your software, so let’s dig into this software rewrite strategy.
If you are trying to decide if now is the right time to rewrite your software, check out this piece, “How Often Should You Replace Existing Technology?”
You can certainly expect some obstacles and bumps in the road on your software rewrite journey, but with proper planning and a disciplined approach to delivery, you can successfully rewrite even the most business–critical system. Far from speculation, this advice comes from personal experience as I have worked with multiple organizations to plan and deliver software rewrites for various reasons. Each of the rewrites I have been involved in have had a different business justification, used a different set of technologies, and each was with a different company in a different industry. However, the thing that every rewrite effort I have seen has had in common, is that they all took longer than the first pass estimate anticipated. Note that I said first pass, because it is common to be overly optimistic on the initial effort at sizing a software rewrite because you know so much about the system that it always seems, at least on the surface, easy.
Do not let this deter you from your decision to rewrite, in fact it should have the opposite effect because it should encourage you to take a deeper pass at estimating and planning. This deeper pass allowed each of the organizations I have worked with to better align stakeholder expectations and more importantly it allowed each client to recognize that at the end of their software rewrite journey, that the decision to rewrite was the right decision and that the business was not only presently better off but that they were also better positioned for the future. No matter your business or technical reasons for a rewrite, having a proper strategy in place is crucial to success. Hence, the remainder of this article focuses on some of the key components you should consider in developing your strategy to rewrite one of your existing software investments.
First, there is no one size fits all strategy when it comes to a software rewrite project. The following are some of the key focus areas and considerations when you are developing a rewrite strategy.
When you are investing in rewriting some existing software, make sure you thoroughly understand the scope. There are two extremes that you want to be aware of when scoping. On one end of the spectrum, avoid the temptation to say that the new system’s scope should be 1:1 with the old system. If this is how you scoped your system, I would strongly encourage you to ensure you are confident in the ROI for all the work you are about to take on. If the new system’s functionality is equivalent to the old, is it worth the investment? If you are already investing in rewriting the software, now is the time to consider potential tweaks to the business process that the software enables.
On the other end of the spectrum, you must also avoid the super loose, undefined, “we will figure it out as we build” version of agile. Agile and iterative software delivery approaches have proven to be a superior way to build software, but that does not mean you should skip some level of up-front scoping/planning. Obviously, the piece of software you are rewriting has been deemed to be of enough business value that you are willing to invest in rewriting it, so do not neglect to consider what it is about the existing software that makes it so valuable to your organization.
When it comes to scope, identify the key business and technical stakeholders, and ensure that everyone is aligned on the future state scope and agrees if the defined scope is delivered, the rewrite is a worthwhile investment.
As the famous software developer Benjamin Franklin once said, “If you fail to plan, you are planning to fail!” Alright, so he might not have been a software developer, but I do not doubt that if he were alive today, he would at least dabble in software and he would agree this statement applies to a large software project. Just as a greenfield software development project needs a plan, so does a software rewrite project, but there are some additional considerations with a rewrite project that go beyond your typical planning activities of organizing the work and identifying/mitigating risks.
First, make sure that you plan for how you will perform testing and cutover activities. Whether you are taking a big bang, weekend cutover approach or a more staggered, incremental rollout by feature or capability, a software rewrite must take extra care to ensure that as the future and legacy systems are in different states of transition, that business capabilities are not lost, duplicated, or out of sync. Second, make sure that you have accounted for how you will handle retaining the value that exists in the data. Whether you can simply keep the legacy data source around as a reference or need to transform/migrate it into your new system, you need to plan for how to retain (the value in the) data.
Most importantly, when it comes to data, know that where there is data, there is a story, so while planning for how to handle the data, be sure to consult with the business experts who are most intimate with the data.
Avoid simply relying on metrics and/or analysis performed by outsiders or individuals without a connection to the data and its history. Finally, when developing your plan, be sure to seek input, feedback, and validation before you commit. The fastest way to sink your project is by presenting a plan before you get buy-in on key plan elements such as the order in which business functionality is to be delivered, the time commitments needed from stakeholders, or how stakeholders will realize value from the rewrite.
Any new system, regardless of how intuitive it is, is going to require some investment in re-training of users. Humans can have a difficult time adjusting to change, especially if it is something that has an impact on their daily routine. Perhaps the new design follows all the latest and greatest usability trends and you managed to reduce the learning curve by orders of magnitude, those are great achievements and will likely improve your business, but none of that will matter if you do not get the daily users of the system to buy-in. Thus, it is crucial to design a training plan that incorporates business users early and often to not only help them learn the new software, but to also ensure they feel like a part of its development. Training should be engaging, it should seek feedback, and it should avoid being condescending. If you can effectively engage the system users and turn them into advocates for the system, you have a significantly higher chance of success.
These are just a few of the considerations, potential roadblocks, and questions you will encounter on a software rewrite effort. Consider that you will likely need to address other questions such as, how do you ensure that you select the best technologies to support your organization in the future? How much should you rely on referencing the legacy system/code when rebuilding? Or should I re-engineer my business processes as part of the rewrite?
At UDig, our consultants have experience delivering custom, enterprise–scale software solutions across industries and technologies. While a system rewrite may seem daunting, partnering with UDig early in the process to bring the right experience and discipline is a sure way to deliver success. If you are considering embarking on a software rewrite, please reach out via the UDig website, we’d would love to talk about your current challenges and the opportunity a software rewrite brings.