This article first ran in the opening month of the 3000's migration era. For the companies still working through a migration, most of the issues remain in play. More to the point for the homesteading 3000 site: These are high-level reasons why a migration isn't on the horizon.
By Curtis Stordahl
Well, the other shoe has dropped. Hewlett-Packard has given their HP 3000 customer base just five years to migrate to another platform. This is a daunting task that is full of risk.
The biggest migration risk factor is probably that the complexity of the applications on the HP 3000 may have been severely underestimated. These applications can be over 20 years old, and some have had scores of programmers continuously evolving the original application without any supporting documentation. Consequently, it is possible that nobody knows just how big and complex these applications are. Many migration projects are also led by personnel with no experience on the HP 3000 platform, who have a perception of it being something like an old dBase application on an IBM PC.
Many organizations will be lured by the “flavor of the month” technology and want to completely redevelop their HP 3000 applications accordingly. This is also full of hidden risks.
A major redevelopment is going to essentially have three project teams. The first project team is going to be responsible for the development of the new application. This team faces multiple risks: of underestimating the complexity of the legacy application they are replacing; or of completing the development only to find it does not meet the minimum requirements and cannot be implemented without extensive rework.
At that point, the team could then find it impossible to obtain the resources needed to complete the project. The technology they choose may not meet expectations and so will not satisfy the minimum requirements. If you go outside your organization for new application development, the vendor you contract to do the work could go bust.
A second project team needs to migrate the data to the new platform. A radical change in design could make this difficult if not impossible.
A third project team needs to provide ongoing support to the legacy application. A major redevelopment could be years in the making, and you can’t stop the business from evolving during that time. This introduces additional risk into both the development and migration project teams because they must aim at a moving target.
There is an overall risk that a migration project could fail, leaving you with no additional funding or time to recover from the failure.
Many organizations will be lured by the promises of packaged software vendors. A package reduces migration risk. But this isn’t like just plugging in a new e-mail package.
The biggest risk factor is going to be implementation. Instead of building an application to conform to your business, you must make now make your business conform to the application. Managers outside the IT organization must buy into this and revise policy and procedures accordingly. So much is needed outside the IT organization to make it work that it must be managed from the executive level. If there is insufficient commitment at the executive level, then the project is destined to fail.
Training users is another risk factor. If you train too early you risk losing them through attrition before you implement. If you train too late, they may not be able to retain and understand what is expected of them.