The desire to “rip and replace” legacy systems can fundamentally lead to catastrophic results. Eric Christiansen explains an important step to replacing legacy systems: understand what they do and how they do it first. Christiansen states in the article that legacy systems were “built on another planet”, or at least could have well been given the amount of changes between the time of their creation and today. Simply based on the fact that they are still working and operating today points to the fact that many legacy systems still have more right with them than wrong, and somehow still is exactly what the business needs. However, new technologists will explain how the legacy system is entirely wrong, leading to an attempted replacement: If a replacement effort is initiated in these all-too-common circumstances, the all-too-common result is failure. The replacement system might meet the official requirements, but it may not work in the business. With luck, initial failures can be labeled delays, and with enough trial and error, maybe the team can build a system that works at least partially. Often legacy systems are only partially replaced. For example, most departments can use the new system, but there are still a couple of departments that need to use the old system because some legacy feature or exception handling didn’t make it into the new system. This leads to the nightmare scenario where the organization has to continue to maintain both old and new systems. Christiansen explains that having at least one developer who is well versed in the old system be part of a new implementation is important (after all, they’ll know more about what the old system did than the users, allowing for a better new system implementation). He also suggests analyzing the legacy system to see what kind of exceptions were present and used often, and of course gathering as many requirements from the users as possible.