The longer any technology remains 'locked' in superseded obsolescence the greater the risk of upgrading it to the latest version. Not only may the application fail, the hardware on which the legacy DB is running may not be able to cope with a new version and the additional load it imposes.

The trouble is that when the server hardware fails and a new one is installed, the old DB may not be compatible with the new OS version. The problem is exacerbated by the need to upgrade the front-end when a brand new version of the DB is installed. The old front-end technology may not be able to talk to the new DB.

A straight upgrade of a DB won't take advantage of any new features. In addition, the old design will have been adopted as a compromise of features that were available plus work arounds to deliver the required functionality at the time. Now with a the new DB and its enhanced feature set, these design decisions are no longer valid and may have a decremental affect on performance.

The move from SQL2000 to SQL2005 caused all sorts of problems not least with the lack of support for old style SQL Joins.

In many respects, unless a process of constant upgrade and enhancement is adopted, the application will require a complete re-write and re-design once the new technology has become available.