To one extent or another, I've been involved with many projects whose goal was to replace an existing system while adding some new features. On the surface, these sound like rather straightforward efforts. After all, the existing system is the source for all your legacy system replacement requirements, right? Unfortunately, these projects often struggle and many are never deployed. Why? Because they don't start with something new.

In my experience, legacy replacement projects first focus on supplanting the features of the old system rather than building new capabilities. In many cases, the legacy system was built over a period of years where new features were continually added and refined. However, new development efforts are rarely given years to write replacement software for the legacy system. The result is usually an initial version that doesn't even provide the same capabilities as the old application and adds little or nothing new. Why would a busy user spend their valuable time to learn a new system that provides less functionality than what they have today? In many cases they don't and the system is labeled a failure before it even gets rolling.

Why not start by building the new features first? Hook your users with new capabilities they don't have today and slowly replace the legacy features until the existing system is no longer needed or used. As a side benefit, your users may decide they don't need certain features of the legacy system anymore or that they should work differently based on their experiences with the new capabilities you've given them. At the end of the day, I think you'll end up with a more successful application that better addresses users' current needs.