"Sorry, We Don't Support That."
A system's implementation quirks might prompt verse
of migration blues
When migrating to a different system or platform,
theres usually something the vendor needs you to lose. But is
it essential business functionality, or just an implementation quirk
of your old system?
So now you are going to migrate. But which is it
going to be? The luxury option of a bespoke (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, but 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 cant say much about the first
two; that depends on your circumstances.
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 long memories may recall some of the early
packages being offered for the HP 3000, 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.
Thats the longer-term risk, then, for some
conversions with low short-term risk; youll be on the new
platform, certainly. But youll have something that plays like
the modern-day equivalent of having KSAM, when the smart money is on
However, if the cost and time objectives point this
way, how bad can it be? Anything short of a full ground-up rejig of
your application is going to be a compromise of some sort.
But 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, perhaps,
is to tap in to the upcoming generation of people who know their way
around them. But if its 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 the hybrid old/new system you are going
to 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 its a subsidiary app, perhaps, and this is a stopgap until
it dies or you replace it more fundamentally. But not if its a
key business app that needs to grow with your business going
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
cant 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.
Inadvertently exploiting the specific way VPlus works, we had an
application that let you put 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
relies 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 wed had the new handler from
If a conversion isnt the way you want to go,
then likely youll 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 youd
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
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 its 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 aint broke at the business level then fix it
only at the code level.
Not to say you cant save some money by looking
hard at the 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, its less likely to be
the latter that when considering packages, which Ill come to
later. And its 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
Im 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. On Usenet newsgroups, people
often ask How do I do x? where x is an attempted solution
they cant get working. Invariably, the response is Yes,
but whats 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. Youll get a much better answer.
If you have a package running on your HP 3000 which
you are happy with, and the vendor provides that same package, or
something very similar, on other platforms, then its likely
just a case of choosing which platform to go with.
Your vendor-supported migration path should be pretty
straightforward, and your hardest problem is going to be to decide
what to do with the crust of subsystems and reporting programs that
have built up, and which surround the package proper. If there are
some you cant do without, and the features arent provided
by the package anyway, on the new platform, this may be a good chance
to get to grips with the tools and utilities on the new platform, and
how things are done there.
But maybe you had a bespoke or home-grown application
on the HP 3000, in an area now covered by one or more packages on
other platforms, and it makes more sense to move onto a package now
than to go bespoke again?
In that case, you have a three-way analysis to do;
what does your existing system provide, what does the new package
provide, and what are your users looking for?
Im hearing the advice dont go for
customization, go for plain vanilla a lot these days. It
certainly gives cost and risk reduction, though perhaps at the
expense of business fit. I reckon that a shame; every company has
something that is its USP unique systems proposition
something in its IT that gives it its edge in its chosen business.
On the other hand, sometimes a company does things
differently because it was easier, or it was always done that
way. Those are things you shouldnt lose sleep over giving
A couple of concrete examples; firstly, meaningful
SKU numbers. Chances are your SKU numbers, or product codes, have a
structure you understand. If so your homegrown systems will likely
have dozens of places where a program takes a different path based on
what that SKU number is. A package is unlikely to support that; each
property needs an explicit flag on the Part Master, and the package
has to work off those.
This doesnt mean that you cant keep your
meaningful SKUs, where everyone in the business knows what they mean.
Just that the package wont know from the SKU, and so you will
need to set those flags for each one. And carefully too, or there
will be some real confusion.
Thats a case where you go with what the package
does. But in the system Ive just migrated, we had a critical
financial value, set against every order, in a complex and special
way that was important to the business. The old system calculated it.
The new system would accept a pre-calculated value as input, sure,
but it wouldnt do the calculation.
We could, I guess, have asked for it to be customized
in. In practice, we built an Excel spreadsheet as a preprocessor to
the package proper, and did the calculations there.
Theres still a little bit of me that says
moving stuff off the HP 3000 onto a spreadsheet is going backwards.
But then theres a bit of me that says that of moving anything
off the HP 3000.
This is the Rolls-Royce (or should I say Cadillac?)
option. But if your application is unique, so theres no chance
of a package solution, and if rewrite/code conversion doesnt
suit, possibly because of a pent-up backlog of business change
requests, or the knowledge that your business area is changing
radically, it can be the only sensible way to go.
And if so, you dont need a few thoughts and
observations about compromise; you need to know how to choose from
the myriad of possibilities out there. I only wish I knew myself
In your next NewsWire, back to hard information, with
Verse Three: Hey, look at this great stuff I can do with MS
Office!, or, data manipulation off of the HP 3000.
Roy Brown is CEO at Kelmscott Ltd., a developer and
consultant with more than 25 years experience on MPE and the HP