New wine in old wineskins?

Have you ever had the feel that instead of maintaining the old code you should take a deep breath and write it new from the scratch? I don't know a single programmer who hasn't. It's the same with companies who decide to reconstruct an old product fully. The benefits are obvious; you can get away with the old crap, use your knowledge you have accumulated during the years and do the real thing. I have seen a couple of such efforts. Most did succeed some not but neither was an easy going.
Here is what can go wrong:

• Migrating the functionalities of the old system

In essence it's a normal expectation, because you want to keep the existing customer base. However  a new system can never be identical with the old one. That is rather a large scale refactoring or worse e.g.if  you want to transfer an old command line program to the Web. There maybe some political reason behind for example you are afraid to loose old customers, or somebody with enough power insists on it...People don't like change by default.

• Keeping the old system going

The expectation to keep the old system maintained is acceptable but it's often combined in new requirements. As a result resources get fragmented, and new functions in the old system must be ported in the new systems with old functions...

• Neglecting migration

Business and development forget to make a strategy of helping users of the new system to migrate to the new one. 

• Reach for  the sky

Sometimes the team wants to reach too much and the result is a long and painful development while the company and its customers are waiting patiently (or impatiently) for an update eventually for years.

• New wine in old wineskin 

A refresh which tries to look new but everything is the old stuff behind. It will most probably burst like the old wineskin..

What to do?

1. Have a long term and regularly updated wineskin (i.e. platform) development plan. It will help you to avoid surprises and extends the lifespan of your core framework/library/platform. You name it.
2. Be modular. Modules are easier to maintain and replace than an inter-wined, monolithic application.
3. Refactor, refactor and refactor. If something is problematic for any reason refactor it. It's almost natural at function level, a bit more difficult with modules and  not simple if you have to change something fundamental (e.g. move for Fortran to Java) however easier if you can do it by modules.
4. Have the best people around. That is trivial but will turn to be essential if you want to operate on a living system...
5. Manage the change.