A legacy software application needs to be rewritten to improve performance. This software is used on an hourly basis to bring money to the business. Because of the nature of its importance to the business, the business wants to know what is the impact to the current systems if it is rewritten. They have a concern that if the new software application fails, the old system needs to be used.

What should I consider when I do the impact analysis? Is there a template that I can use to present the data to the business?

  • 2
    You need to build a business case. The questions your customer is asking are typically answered in a business case, which is then used to justify project investment. At the highest level, the case discusses the benefits of the change, costs to change, and risks with some high-level mitigation strategies. Commented Apr 4, 2022 at 12:42

3 Answers 3


You need to develop a case for change. You need to discuss:

  • Problem statement and the need for change
  • Current state with current business metrics such as revenue and profit over the past several quarters
  • Analysis of alternatives
  • For each alternative, provide:

Expected business value, both objective and subjective, with the predicted timeframe for each value; Penalty paid if this alternative is rejected; Cost of this alternative; Risks with this alternative with high-level mitigating strategies and exit strategies; and ROI with this alternative

  • Recommended decision
  • Estimated duration of the change

I confess that I'm not sure I understand the situation, so it is quite possible that what follows may not be answering the right question.

To my mind there are two critical questions

  1. Why are you switching to the new software? What is the performance case you're seeking? This is the key impact of the software, and this is the structure of your analysis. You say that the software application needs to be rewritten to improve performance. The impact to the current systems of the rewrite should be "X% improvement in performance"

  2. What are the requirements of the current software? (if there are none, this is an opportunity to reverse engineer the requirements and to attach them to stakeholder/owner/sponsors)

Obviously there are functional requirements: the software must perform the function accurately. I assume that there are a set of use cases that define "accurate", and if there are not, then this is an opportunity to document them. Software must comply with a set of legal regulations, accounting procedures, etc.

There are probably non-functional requirements - for example, security (software must not disclose confidential information, software must have an availability/ uptime of at least X%, software must create records that are stored correctly, software must correctly implement business procedures), user experience (for example, is it easier for the customer to use? Is it easier for the internal user to use?) There are probably some non-functional requirement opportunities. If the software experiences and error, it must fail gracefully to some form of manual intervention - how easy is that? Does it inform the right people (accountable, informed, people)? Does the failure mode make it easier to capture/document a new use case, or is every error effectively bespoke?

How is the software aligned with/connected with other business processes? Are there opportunities to more closely integrate the software with other business processes? Are there other revenue opportunities?

What is the cost to maintain? Does the software rely on outdated libraries or infrastructure? Is it maintained on-prem, or is it in the cloud? How does that align with corporate strategy?

Specifically with respect to management's apparent concern, is it possible to run the new software against 12 months of captured data? Is it possible to run the two software sets in parallel? Can you run the old software with the new software in the background for a month, then the new software with failover to the old for some period of time?

I'm a bit concerned that the question only considers the case where the rewritten software fails; there is also the possibility that the revised software will be more accurate, more capable, speedier, or easier to use. (in fact, this should be the most likely case).

I'm also not sure I understand management's concern; isn't failing over to the old software preferable to not bringing in revenue?


Without specific knowledge of the business and the application, it is unlikely that anyone can give you a definitive answer. However, there are principles that you can use to guide you:

  1. Don't try to do everything yourself. Use colleagues both in the business and in the technical teams to provide information on what they expect from the system, and the impact if these capabilities cannot be met.
  2. Think about both the project risks (i.e. what happens if the project doesn't deliver) AND the operational risks (i.e. what happens if the live system doesn't do as expected or fails in live operation). Be very careful that you don't confuse these different types of risk, as they are almost certainly owned and must be dealt with by different people.
  3. Consider the approach to delivering the system - do you need to deliver a "like for like" solution, or are there any "must have" add-ons, or are there any redundant features in the current solution that can be deleted? Does the full capability have to be there on day 1 of the new system, or can you survive with a limited feature set and develop the remainder in future iterations?
  4. Think about the impact and the likelihood of any issues, and combine them in a way that is meaningful to you to grade the risks associated with each. Then treat these risks in turn. Most risk analyses I have seen have been graded as "High", "Medium", "Low" on both axes, so you may have risks in each of the 9 categories "High / High", "High / Medium", etc, right down to "Low / Low". Get these signed off by the product owner / business owner of the system, and then address them.

In terms of business presentation, I suggest that you list the risks according to the groupings I have mentioned above: Project risks and Operational risks kept separately, then prioritised within each according to their position in the risk matrix with "High / High" at the top of the list. Your question really refers to the Operational risks more than the project risks, so perhaps that is the area to concentrate on first, but don't forget about the project risks entirely.

Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.