Application Rewrites – Getting Started

Ugh. Imagine you are responsible for leading a project to replace a 15-year-old, complicated, internal business application. No one is happy with the status quo, and the complexity of the application makes this project seem intractable.

You ask yourself, “How did things get this bad? How am I going to get started?”

Acknowledge How You Got Here

Applications that are core to internal business processes usually get deprived of investment in holistic improvements because:

  • They maintain the status quo of operations by managing the expense side of the business or supporting existing revenue streams.
  • Using the applications is compulsory, unlike consumer-facing applications that need to be competitive.
  • Operations stability and uptime are critical. Application updates and technology upgrades are considered risky (especially if updates commonly result in unanticipated issues).
  • It can be human nature to focus on immediate needs and defer regular, sustaining maintenance until an acute issue focuses attention.

Sustained lack of regular maintenance and upgrades can eventually lead to the need for a full rewrite.

Recognize the Need for Change

Common reasons for considering an application rewrite include:

  • The original application was created using a technology that is no longer supported. Development tools are difficult to obtain, and the supplier of the tools won’t support any bugs or issues.
  • IT infrastructure or hardware for application hosting, distribution, and installation management is changing. Sometimes, old handheld hardware becomes impossible to obtain and forces a move to mobile or tablet devices. When infrastructure moves to the cloud and application installation management is streamlined, desktop applications get rewritten as web applications. (Once apps are deployed to the web, it’s easy for everyone to be on the same version.)
  • The business can’t hire or retain people who want to work on legacy technology. Hiring talented developers is hard enough given the current talent crunch. It’s even harder to find and retain people to work with outdated tools that make their day-to-day work cumbersome and won’t build their resumes.
  • Changes to the application commonly cause new, unanticipated bugs. Bugs resulting from fixes are usually a smell of high complexity, lack of quality assurance automation, and poor application design.

Evaluate the Risks

Rewrites can be hard to justify due to the significant risk and cost of rewriting complex, highly-integrated, internal applications. It’s easy to be attracted to the short-term option of living with the status quo and accepting future risk of inflexibility.

When considering whether it’s worth it to stick with the status quo, I recommend evaluating:

  • Risk and impact of business downtime if an issue occurs
  • Risk and impact of opportunity cost from not being able to extend the application to meet new business needs
  • Cost of time involved in managing and supporting the existing application (e.g. more time to update and release, more time supporting users, issue reporting and resolution, etc.)
  • Risk and cost of losing employees due to continued frustration using and maintaining cumbersome tools

Plan for Success

When a rewrite option is on the table, it’s common for business stakeholders to want a detailed project plan with high confidence in scope, cost, and schedule. Business stakeholders want confidence in the rewrite plan because rewrites are generally viewed as pure expenses to maintain the business and not generators of new revenue.

Due to the complexity, codebase size, integrations, and number of affected user groups, rewrites are extremely difficult to budget with high confidence. Comprehensive requirements and planning require significant effort. Here are some ways to find enough traction to move the project forward:

  • Stop thinking about the rewrite as a monolithic replacement, and start thinking about it as a series of partial replacements that deliver value early and build momentum for the project.
  • Pick the right team to plan and execute the rewrite project. The team should be experienced in software product development, not just operational IT updates and maintenance. The team should also have experience with application rewrites due to the special considerations inherent to rewrites.
  • Invest in a Research, Design, and Planning phase to understand and prioritize the needs of different user groups, integrations with other information systems or business processes, and a high-level inventory of features. Invest more time in scoping high-risk or high-value areas of the application, and only build a high-level understanding of the rest of the application.
  • Create a new software architecture plan that will allow you to release chunks of new software that partially replace the old application. This likely means parallel deployment of both the existing and new applications during a transition phase.
  • Through knowledge gained during RDP, create a high-level plan for the entire project and a detailed plan for delivering the first chunk. Align stakeholders on the investment strategy of updating the high-level plan as you incrementally deliver chunks of value. Decisions to continue funding can be made after each milestone is achieved and in the context of other options.

I hope these tips make a challenging project a little more approachable. What kinds of experiences have you had with rewrites?