LiveAndLetDie

PublicReengineering Wiki

Context

Your company is part of a group of companies. The group has a strategic IT policy, part of which prescribes the standard packages which business units should adopt. Your business unit has one or more legacy system which do not conform to the group's strategic preferences. It is difficult to migrate to the target systems due the legacies' data and/or functionality being incompatible with the target. Group predicts overall savings by moving to specific products, but you and your users may experience inconvenience during the change. Group understands that there are difficulties and expects migrations to take a number of years.

Problem

How do you move towards the corporate preferred packages?

Solution

Run the target and legacy in parallel for some time, letting the legacy gradually die. See Figure 1.

http://reengineering.ed.ac.uk/graphics/LiveLetDie.gif

Figure 1 - Moving to Corporate Preferred Packages, Letting Legacy Die

Consequences

You can conduct all new business on the target system, introducing training and interfaces as necessary, and handle referencing and existing contracts on the legacy. As old contracts come to an end, the legacy will fall into disuse and the target system will take over. Maintaining two systems which work in parallel, carry out the same function, but do not communicate, will increase running costs. A certain discipline will have to be applied to stop users falling back on the legacy with which they may have more familiarity and confidence - particularly in the beginning. This discipline could be brought about by identifying a specific date at which the legacy will no longer by accessible for editing (see Deprecation).

This solution may not be desirable for situations where legacy data needs to be maintained for a considerable time, for instance life insurance contracts. An alternative is to adopt SteppingStone. In addition, you may wish to consider rationalising the responsibilities of the legacy in which case DivideAndModernise and Middleware may be of interest.

Known uses

This pattern has been seen in a small business unit of a large manufacturing group. They possessed an ageing Computer-Aided Design (CAD) package which was no longer supported in terms of hardware or software. The data on this system could not be converted into a form which would allow its useful deployment on the group preferred CAD system. In this case, the company chose to run the two systems in parallel. The legacy gradually fell into disuse and now there is only one terminal left to access its data for reference purposes.


Related pages: ReengineeringPatterns

This page last edited on 5 January 2000
 
 
  • Search for: