As the manager of a small software-reengineering company, I am continually confronted with the task of justifying reengineering. The user wants to know what the benefits are. Why reengineer old Cobol or Fortran when there are so many attractive fourth- generation and object-oriented languages on the market? That is why I have chosen to address business issues in this article -- not because the technical problems of transforming code and data structures are not important but because they may be irrelevant if you are not able to make a business case for solving them. There is nothing worse for a technician than to be working on a solution to some problem for years, only to discover that the problem was incorrectly stated from the beginning. I have developed a five- step reengineering planning process, starting with an analysis of the legacy system and ending with contract negotiation. The five major steps are project justification, portfolio analysis, cost estimation, cost-benefit analysis, and contracting.