Paul Holland helps computer users get through their
migrations muck. The CEO of Transoft leads a company which has
offered application transformation tools to HP 3000 sites since 1999.
Then it expanded its MPE/iX offerings in the early fall of 2001, a
time when few 3000 customers had any migration experience
nearly all of whom didnt think they would need it.
That all changed after the events of November, 2001 set
a migration diaspora from the MPE homeland into motion. Transoft has
moved to bring this market its experience in migrating Data General,
NCR, Bull, IBM, and Digital customers. The company built up its MPE
migration rule set in an array of engagements, including the port of
the Amisys healthcare solution to HP-UX. This month Hollands
company enters the 3000 migration tool sales market for the first
time, after its years of service work. But his firm approaches the
3000 customer from a different perspective: A provider of migration
and evolution products since the late 1980s.
Holland got his start in the business a few years
before that by taking his computer science degree into the field
in a very literal way in the UK. As the only sales rep for an
agricultural software company, Holland carted a computer and software
into farmers home offices to demonstrate a farm management app,
wearing high boots and carrying an Apple personal computer through
what I hoped was mud.
He slogged through more sterile markets such as
banking, developing a mutual fund app for NatWest Bank, before
joining Transoft in 1987. After Transoft got into the COBOL app
migration business in 1993, the company did its first HP 3000
migrations in the late 1990s. But like many other companies, Transoft
saw its migration business head into a trough after Y2K. The company
looked for a new opportunity and selected the 3000 market, rich with
the COBOL code that matched up with Transofts
Holland has impressed us with an articulate voice of
that migration experience understanding the angst as well as
the advances when a customer is forced to move off a working
platform. We wanted to ask him how the 3000 users experience
compares to others hes seen. [In a separate front page article, he explains why
the company is turning to software as a new 3000-related revenue
stream.] We spoke in late April by telephone, just before HP gave an
update on its MPE improvement process.
Whats the most common element in a
migration, regardless of the platform a company is leaving?
The reality that weve seen in every migration market
is that theres a certain type of organization that jumps on
this problem early but by far, the majority of the market
hangs on. Ten percent is the natural, organic migration rate for a
market that isnt being presented with an end-of-life statement
from the vendor.
What seems to set the 3000 market apart from the
rest that youve entered?
There is more of a do-it-yourself mentality. Not just
do it yourself in terms of migration in terms of everything.
These people just like to program. Theyre a very
self-sufficient breed, the HP 3000 community.
How important is explicit knowledge of MPE and
IMAGE in a 3000 migration engagement?
Theres no doubt that expertise in the
originating platform is very important. Were lucky to have some
great IMAGE and MPE experts on our staff. But that is not enough. I
would argue that its very important to have a really good
knowledge of the target environment.
Its also equally important to understand the
process of taking the programming language and data entities from one
environment and converting them to the target environment. You really
need all three.
As well as MPE, VPLUS and IMAGE a typical migration will
involve relational databases, korn shell or VB Script,and browser
front-ends. You need to understand the whole gamut of
Whats been the biggest impediment for
companies who are not yet migrating from the 3000? Do you encounter
Theres a common view that companies are not
jumping on this problem as quickly as people had thought. The
reassuring thing Id say to the HP 3000 community is: Dont
feel bad. Youre no different that any other migration market
weve ever seen. The reality is that people hate having change
pushed on them, particularly when they assume there is little ROI for
what they have to do to solve the problem.
People easily fall into the trap of thinking this is
all cost and no benefit. I argue that this is a great opportunity to
address some significant business benefit requirements. Our approach
is to try to use the migration project as a means of delivering new
functionality to the business.
I do wonder how many CEOs know today that some of
their core mission-critical applications are going to be running on a
platform that will no longer be supported by the manufacturer at the
end of next year. You wonder if the CIOs have brought that to the
Manpower bandwidth is about to become an issue
when picking a migration consultant: True or false, and why?
Inevitably there will be a squeeze, a little like
Y2K. I also believe that with the right tooling, you can mitigate
that problem quite a lot. Our decision to bring our migration
products to this market will give people options. They can be in
control of their own destiny, not dependent on finding resource from
a consulting firm.
However, even within our consulting engine, the
tooling gives us a great deal of productivity. A migration project is
not a very large headcount project for us. The actual migrating of
the code does not require a lot of people. What requires the people
is the testing and the managing and interaction with the partners and
the clients. Those kinds of skills are less resource-limited.
Youve guided owners of other business
systems to new platforms, so which other platforms issues are
the most similar to the HP 3000s?
The HP 3000 market is different in a couple of ways.
Theres wide use of third party products. I dont think
weve done one HP project that hasnt had some kind of
third party product involved with it.
The other thing thats noticeably different is
the well do it ourselves point of view. We like it
that our engagements are partnerships. Frankly, that is the secret to
a successful migration: partnership of the customer with the people
who have the expertise delivering the migration.
The market that seems to be similar to the HP 3000
market is the IBM mainframe market. It too has a large number of
third party products, a fair share of intrinsics, and a similar
Does that strike you as a favorable
All credit to the HP 3000 platform. It is repeatedly
used to drive large mission-critical applications with large user
counts. In many respects its used like a mainframe.
Theres no doubt, that like the IBM mainframe, the HP 3000, has
had a hell of a good run.
Is it important for HP to license its source code
after its end of support date? Can it help migrating
[Chuckles] Obviously, Transoft would like everybody
to get off of MPE. But the reality of the situation is that people
will be on MPE for years and years to come. My guess is that if
its anything like other migration markets, they will
revision-lock, and it wont be a problem [to stay]. Were
talking about a very stable operating system.
Let me tell you, today we are still migrating Data
General MV users. Those people havent had any manufacturer
support on their platform for many, many years. If youre
willing to run your business that way, fair enough. I suspect making
the MPE source available to another organization will not yield the
benefit that people think it will. I wonder about another
organization truly wanting to pick up that responsibility.
PA-RISC emulator versus software emulation on
Unix/Windows: What situations do each of these tools match up with
Hardware emulation has never really taken off in any
of these migration markets. Software emulation is really only about
providing a familiar API or interface. Once youre past the
convenience of a familiar software interface, youre dealing
with native systems.
We support the VPLUS, IMAGE interfaces and offer
emulation as well as conversion in the JCL space. However, one of the
advantages of moving onto a new platform is a superior COBOL
development environment. But you need to get into that environment.
Some organizations say they dont want any emulation, and then
we get into a discussion of whether our intrinsics library is
emulation. It is, but what are you going to do? You dont want
to hard-code and reproduce all those intrinsics in COBOL. That would
be a very long-winded way of doing it.
Does Linux look like a likely migration target for
many HP 3000 shops? Is it ready for big-time IT yet?
We have no problem migrating people to Linux. It
comes up in discussions, and people do consider it as an option in
the HP 3000 market, but to date, no one has asked us to do it. In our
ISV community, however, weve seen a large transition to Linux
from other Unixes.
Does the market support for Itanium concern you
when you consider the future of HPs Unix?
Im probably not the person to answer that,
because I dont really have any view on it. We migrate people to
a wide variety of Unix and Linux platforms, and rarely get concerned
about particular platforms.
What information and help does HP still need to
deliver to the 3000 marketplace thats still planning a
Compared to other migration markets we have been in,
I believe HP has done an outstanding job. I know the 3000 users may
not feel that way, but let me tell you, there have been platform
EOLs where the vendor did very little to communicate options
and information. HP has at least tried to do that.
Unfortunately, perhaps at the time that communication
fell on deaf ears. Because of the early inertia in the market, people
werent listening. They might go back and start that process
again, because as time has gone by people are listening more.
Is the iSeries a serious target for 3000 shops, or
just another vendor-locked platform waiting to decay?
When we first got into the HP 3000 market in a big
way, we thought that people might naturally go to the iSeries.
Perhaps because of some sort of empathy; HP 3000 users felt they were
the AS/400 of HP. Certainly technically, theres very little
difficulty in migrating someone to the iSeries. I can only say that
no 3000 customer has asked us to do that.
Is it too late now to start a migration and still
hope to finish by end of 2006?
The obvious answer is that it depends. On an average
size system, if you get started between now and summer, you stand a
fairly good chance of getting the thing done by the end of next
Is that end of 2006 date a serious deadline for
many of your customers?
I dont think the market sees it like a Y2K
problem. Users are not terrified that on Dec. 31 their systems will
fall apart. People feel theyve got some leeway. It runs now,
and it will run in January, 2007.
But I think what we are seeing is
organizations are now really getting down to the planning, even if
they dont start until late this year or early next year.
Theyre starting to get the budgets aligned. Its close
enough now that its real.