When companies decide their HP 3000 will not serve the same role as it has for many years, there's a decommissioning along that path. MB Foster's latest webinar took note of the two types of pulling a 3000's contribution offline. The most obvious one, and perhaps the hardest, is hardware decommissioning. Everything must be moved away by the time the plug gets pulled and a reseller or recycler is located.
But a preliminary decommissioning is a much more common occurance. It's also a step that doesn't signal the total shutdown of a 3000, although it can contribute to that. MB Foster calls this application data decommissioning. The company's UDA Central product can help. But that's information MB Foster only shared after a half-hour of discussing the issues everybody needs to be aware of, regardless of tools used.
Data decommissioning typically occurs when
• An application is being replaced – by a new application or an upgrade.
• Hardware or an application no longer has support
• When a OS vendor obsoletes a platform or chipset
• When an operating system has reached its usable lifecycle
• When a company has a change in status – being merged into or acquired, or an insolvency — and the application will no longer be used.
During this ID phase, understand that data is indelible. "They say there are two things to count on, death and taxes," Foster said. "Now there are three -- let's add data to the list." When you plan to migrate data to the new app as required, you separate data into transaction categories. For active data, figure out a data migration. For inactive data, determine a historic data plan. A single plan doesn't fit both types of data very well.
Because the company has specialized in data and reports for so many years, MB Foster reminds managers that reporting requirements are a key element of both kinds of plan. Longer-term reporting requirements are often not considered during a data decommissioning process. When you need that kind of information, how will it be presented back to the users who need it? One best practice is collecting line of business and departmental-level reporting requirements -- before you decommission legacy applications and data. The apps and platform may change, but the reporting needs are likely to remain the same.
In some cases, HP 3000 apps are part of a larger, global IT structure. It's a good idea to document corporate data retention policies with the global perspective as a guide. Factor in rules according to individual countries, and remember that specific industries will sometimes dictate compliance policies. It's possible to reach out to corporate internal resources which deal with records management to address their policies.
Once the policies and processes have been established, it's time to standardize on an archiving system. This is the time to work on unifying data and content. That's a process that will proceed smoothly if you can provide a complete view of the archiving system to the data stakeholders and departments. Rules for access to the data will include the issues of security, privacy, and compliance with regulations such as HIPAA for health care, or PCI credit card transactions.
A plan and schedule for decommission will impact plenty of departments and people. When presenting the plan, be prepared to address questions such as "Where will the information go once it's decommissioned?" and "What new application replaces the legacy system?" You'll want ask questions, too, like "What is an acceptable decommissioning timeframe?"
Like any good project that impacts a company asset like data, yours will demand that you create a plan for data integrity validation and auditing. Articulate what quality data means, and share it across the enterprise
"The integrity of your data is vital," Foster said, and there are many threats to data quality." For example there are hardware problems, old tape archive issues, data entry errors or carelessness.
Decommissioning legacy data often must consider who owns it. Issues of regulatory and governace have got to be met, including access to historic data over required periods of time. Some alternatives in these instances include moving the data, providing searchable formatted data, and having an auditable instance for the "system of record" -- the retiring HP 3000 application or server.
MB Foster's interest in this, apart from serving its customers, is the Extract, Cleanse, Transform and Load abilities of UDA Central. The software does ECTL to and from Sybase, Ingres, Informix, Oracle, DB2, MySQL, SQL Server, Progress, PostgreSQL, CACHE, Eloquence and MPE. There's a success story online, the company adds, that outlines data decommissioning at the Health Plan San Mateo, where the 3000 systems have moved offline.