« Emulation leader hires ex-HP legacy expert | Main | Aspects to Ponder in Package Replacements »

April 06, 2018

How to Measure Aspects of Migrations

Newswire Classic
By Roy Brown

GemSo you are going to migrate. When migrating to a different system or platform, there’s usually something the vendor needs you to lose. But is it essential business functionality, or just an implementation quirk of your old system?

Which migration are you going to have? The luxury option of a custom replacement of your old system? To a package on a new platform, maybe a version of a package you had before, or one new to you? Perhaps the rewrite option, where a team of programmers, possibly offshore, re-implement your system in a whole new environment, while keeping the existing functionality. Or will it be a conversion, where your existing system is transferred to a new platform using automated tools?

Each has its advocates, and each has its pros and cons. Chances are, your constraints are going to be cost, time, and risk. Probably in that order. I can’t say much about the first two; that depends on your circumstances.

Code Conversion

But risk comes in two timescales; immediate risk – “Can we do this? Can we get onto the new platform?” – and the longer-term risk that you are maybe painting your company into a corner by accepting some compromises now that later will turn into shackles.

Those with very long memories may recall some of the early packages being offered for the HP 3000, the apps with KSAM file structures, not IMAGE ones. You just knew they had been ported from elsewhere, not written native on the HP 3000. And if you could find what you wanted, on IMAGE, you were surely glad.

That’s the longer-term risk, then, for some conversions with low short-term risk; you’ll be on the new platform, certainly. But you may have something that plays like the modern-day equivalent of having KSAM, when the smart money is on IMAGE.

Look hard at where you are going to be after a tools-based conversion; will you be fully on the new platform with all-independent code, or will you be running in an environment provided by your conversion specialists? If the latter – and these can indeed lead to faster, cheaper, lower-risk conversions – treat your supplier as a package implementer that you are in with for the long haul, and judge them accordingly.

Likewise, what about ongoing, internal support? One of the reasons to move to new platforms and new paradigms is to tap in to the new generation of people who know their way around them. But if it’s hard to see how you are going to get ongoing support for your HP 3000 apps, how much harder will it be to find people who can support a hybrid old/new system you might wind up with?

Finally, and on the same note, how maintainable is the migrated system going to be? You need to ensure that the generated code is going to be something that a human can easily work with – and likewise the environment the code runs in – or you are going to be effectively frozen in the converted state. Fine if it’s a subsidiary app, perhaps, and this is a stopgap until it dies or you replace it more fundamentally. But not if it’s a key business app that needs to grow with your business going forward.

All this is assuming the conversion is feasible. Hopefully, in the average application suite, you are not going to have done too many unusual things that the automated conversion can’t cope with; maybe some system-y job and user status calls that are done differently on the new platform, and other corner cases, but nothing fundamental.

But sometimes the gotchas can be quite widespread. While inadvertently exploiting the specific way VPlus works, we once had an application that let you put in a partial key and a question mark, hit f2, and go to a lookup screen where you could review matching keys, and select the exact one you wanted.

This was used across quite a range of screens, and relied on VPlus not trying to validate the partial key when you went that route. But move to a screen handler that works rather differently, and you may lose that option. Nothing insurmountable; we just needed to change things so the partial key was entered in the lookup itself, with a code to say what sort of key it was. But this small inconvenience for the user was surely also a bypass of nicer techniques we could have used if we’d had the new handler from scratch.


If a conversion isn’t the way you want to go, then likely you’ll be offered a rewrite. This can be more flexible than a code conversion (though you can bet the conversion team will be using some internal tools for the straightforward bits). And you should wind up with an app that is fully and independently implemented on the new platform, dispensing with any helper environments. Likely, though, it will not quite be what you’d have got starting from a zero base on the new platform – it will retain a few traces of its HP 3000 origins. But hey, is that such a bad thing?

Here again, you need to make sure that you can work with the resulting code going forward, to keep on track with your business needs. But the main issue is what shape is the application you are migrating.

One way of looking at a rewrite is that it’s a full custom conversion—but the results of the business analysis, instead of being expressed as use cases in UML, or whatever, are being presented in “HP 3000 Modeling Language.”

So if you are really happy with how your HP 3000 app fits the business – and if your users are — this can be a better way to go than embarking on a needless rediscovery process. If it ain’t broke – at the business level – then fix it only at the code level.

Not to say you can’t save some money by looking hard at the 3000 app, and maybe trimming out some dead wood – old functionality that is no longer used, and that thus does not need conversion. But do try – at least in the first go-round – not to request new features. Else your rewrite starts creeping towards being a new custom implementation, thus losing you the best of both approaches.

But even with a rewrite, perhaps there will be a few things the rewrite team will balk at, or instances where you will find that the cost of keeping them in is likely to be disproportionately high. Maybe they will come up with an alternative approach, or maybe you will.

But if not, consider what you are losing. A nice-to-have, but which you use once in a blue moon? Or something integral to your business? On a rewrite, it’s less likely to be the latter that when considering packages, which I’ll come to later. And it’s likely to be something system-y again, albeit at the user level, where they interact with job streams, or print queues, or whatever.

Maybe something in the user interface? Though I’m always pleased to see how closely forms on the web follow the VPlus paradigm of fill in all the data, press Enter, get it validated, go forward if okay.

But you do need to be as flexible as possible about doing things a new way on a new platform. People often ask “How do I do x?” where x is an attempted solution they can’t get working. Invariably, the response is “Yes, but what’s the actual problem you are trying to solve?” And the answer turns out to be quite different from x.

Adopt that precept here; go right back to the problem you are trying to solve, and not how to get an envisaged solution working. You’ll get a much better answer.

Roy Brown is CEO at Kelmscott Ltd., and a developer and consultant with more than 35 years’ experience on MPE and the HP 3000

06:08 PM in Migration | Permalink

Bookmark and Share

Use our search engine to find 20 years
of HP 3000 news and articles



Post a comment