I saw Mahendra Mavani speak on Technology Refresh pitfalls at The Dallas Day of Dot Net convention this weekend.

By Technology Refresh (his term) what is meant is the rewrite of an existing application. To wit, the crafting of that would-be better version of that old application which has its kinks. Mahendra was a consistent presence on a project, from preplanning all the way to bug fixing long after rollout, which was supposed to be done in 2008 yet lingered for years afterwards. Both the cost and time as both estimated and originally allocated would prove to but a third of what was ultimately needed. In the end, and with some compromises, the users of the original system did indeed end up using the new system instead, but Mahendra was hesitant to call the project a success understandably. Bad goals which caused problems include:

1. Replace the whole system: The original application, a mainframe application which got replaced with an ASP.NET MVC application, had hundreds of users across seventy-four functional roles and ten departments within the greater entity using it. Just as you would not try to climb Mount Everest in a single bound, you should not attempt to replace something of this complexity all at once either. Target the real life group that is driving the effort and plan to replace their chunk first. That slice of the pie will not have seventy-four functional roles. Understand the real-life interaction between the target group, once it is established, and the other groups too.
2. Enhance while rewriting: There is the temptation for developers to try to do something "awesome" now that they have an opportunity to do some greenfield work. Fight it! In Mahendra's scenario the team looked at perceived holes in workflows and security that led to problems and tried to better workflows and security. Ideas that came out in the Agile process unfortunately reflected the wishes of the before-mentioned chunk of the seventy-four roles which was driving the development and not everyone. Mahendra forced users to log in and out every time they changed roles. Good security right? Users with profiles straddling numerous roles hated this. Just do a rewrite, not a rewrite plus.
3. Generalize for broader use: Remember YAGNI. (You ain't gonna need it.) The gold-plating may scare/intimidate users by making the new experience more confusing. How does the gold-plating happen? Various parties involved start speculating as to needs. They give their input and the scope just keeps growing. This bullet point is a sister to the one before it. On a tangent, Mahendra gave another example of where a typical Agile process and letting stakeholders drive requirements may undermine success and that lay in an inability to roll out a OLTP/OLAP divide. Instead of having records pushed to a denormalized schema perhaps daily on a nightly process, stakeholders are apt to just decide they have to have real-time reporting (which they don't) and refuse to indulge an OLAP-friendly model leading to extremely complicated queries being crafted for reporting, the kind of queries that cannot be seen on a monitor without scrolling. The technical debt this brings does not merit the "benefit" of accurate-to-the-last-second data.
4. Ceremonial switch over: Circling back to the first bullet point, a big bang go live in which everything changes for everyone overnight is bad. The go-live becomes a big event, the need for a backup plan just-in-case emerges, an off-peak hours deployment is proposed, the moment of the switch is tense, and then babysitting is needed. Mahendra suggested that if he were a civil engineer in charge of making Austin's roads better and he proposed just building a new Austin in some dead space just to the East of the existing Austin and then having everyone in Austin just move to the new Austin when it was done that no one would take him seriously. The better approach involves fixing one of Austin's roads standalone without forcing everyone tangentially involved into jumping through a bunch of hoops to accommodate something new. For an application you will have to figure out the boundaries between the first piece you are to replace and get users using and the rest of the application which is to be left, initially, untouched. This means you will have to understand the endpoints between the parts and if endpoints don't exist you will have to build them.
5. One-stop universal solution: This last bit went into "bounded context" as Eric Evans (who wrote Domain Driven Design) might define it. The concept of a "Product" might mean different things in the contexts of ecommerce, manufacturing, inventory, and fulfillment in a large system. If you are just replacing one of these, keep the scope of "Product" to the scope of your bounded context.