I have a rule – any conversion or upgrade will require the creation of a decommission plan. A decommission plan should include the following:
- A list and definition of each database, table and column (source and target).
- A list and definition of each of the current programs in use (you may want to include the ones that are not used).
- A list and definition of each report and interface from the current application.
Some companies may have a specific format to use for the decommission plan – if so. use it! I usually use spreadsheets for these lists, and leave plenty of room for analysis of what is salvageable. Really, why create new programs or reports, if we can repoint an old program and change some variables – right?
Some companies just create new applications with NO thought to decommission of older applications. This just creates more redundancy and confusion for the enterprise. One of the critical success factors for any conversion should be worded much like this – This application will be considered successful when _____________ application (including the database objects, programs and reports) can be turned off or decommissioned. The decision to decommission or not is based on corporate standards. If you don't have these, create them.
Decommissioning older applications also can regain space and resources. I know space is cheap, but if the old database and interfaces keep running it will just chew up processing time, and as time goes by, all the applications will run slower and slower.
So make a rule: NO DELETE – NO NEW APPLICATION!
