HP's 3000 power supply persists in failure
Fred White, 1924-2014

Replacing rises as migrator's primary choice

Key_to_replacementIt's the end of 2014, just about. Plenty of IT shops have closed down changes for the calendar year. Many 2015 development budgets have been wrapped up, too. Among those HP 3000 operations which are still considering a strategy for transition, there's only one assured choice for most of who's left. They'll need to replace their application. Not many can rehost it.

We've heard this advice from both migration services partners as well as the providers of tools for making a migration. An HP 3000 is pretty likely to be running an application with extensive customization by this year. We've just now edged into the 14th year since HP announced a wrap-up of its interest in all things MPE/iX. Year One began in mid-November of 2011. After completing 13 years on watch during the Transition Era, there's a lot of migration best practices to report. More success has been posted, at a better price and on schedule, when a replacement app can be integrated along with a new server and computing environment.

Of course, massive applications have been moved. One of the largest was in the IT operations of the State of Washington Community College Computing Consortium. It was a project so large it was begun twice, over enough elapsed time that the organization changed its name. The second attempt better understood the nuances of VPlus user interface behaviors. There were 40 staffers and at least four vendor services groups working on the task.

One of the issues that's emerged for rehosting organizations is a reduction in MPE expertise. Companies can still engage some of the world's best developers, project managers, and rewriting wizards for MPE/iX. It's harder to assign enough expert human resources who know your company's business processes. That's why a top-down study of what your apps are doing is the sort of job that's been going out-of-house. By this year, it would be better to engage an outside company to replace what's been reliable. This hired expertise ensures a company doesn't lose any computing capability while it makes a transition.

You'll need the use of tools to manage data in a replacement, though. Everything else is likely to change, even in a replacement, except for the data. "Replacement requires reorganizing data," Birket Foster of MB Foster told us this summer. "You could start cleaning your data now." Foster is presenting a Webinar on the subject of the Three Rs -- Rehosting, Replacing, or Retiring -- tomorrow (Wednesday) at 2PM Eastern Time. 

A company making a transition to a replacement app needs to understand what data will be needed, at what detail level, and in what timeframe. The best answers to those questions might come from outside of the IT group. In face, Foster says they often do. A solid team of transition stakeholders always includes an important seat for a member from the business group.

Replacement of a 15- or 20-year MPE/iX app suite also might not be a favored choice in the IT group. That group includes the experts who know the programs best. Nothing seems like it will be a clean, quick fit for what's been running the company -- not at first. Replacing with a non-MPE version of the app sometimes leaves key integrated surround code at the curb, too. Replacing surround code is a good project for outside expertise. Companies which consult on that task have field experience on success to share.

The good news: replacing a business suite is not as dangerous as replacing a joint. You get to shop and specify and test for replacement software, even while the worn-down hip of the business suite continues to bear the weight of the company's enterprise. Backing out of a replacement -- replacing the replacement -- is just as extensive in software as it is in medicine. It's like doing it all over again. But replacing after an attempt at rehosting? That's the least effective strategy of all.

Comments