Marxmeier Software Sponsor Message

May 2005

Paul Holland helps computer users get through their migration’s 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 didn’t 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 Holland’s 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.

Paul Holland CEO Transoft

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 Transoft’s experience.

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 he’s 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.

What’s the most common element in a migration, regardless of the platform a company is leaving?

The reality that we’ve seen in every migration market is that there’s 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 isn’t being presented with an end-of-life statement from the vendor.

What seems to set the 3000 market apart from the rest that you’ve 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. They’re a very self-sufficient breed, the HP 3000 community.

How important is explicit knowledge of MPE and IMAGE in a 3000 migration engagement?

There’s no doubt that expertise in the originating platform is very important. We’re lucky to have some great IMAGE and MPE experts on our staff. But that is not enough. I would argue that it’s very important to have a really good knowledge of the target environment.

It’s 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 technologies.

What’s been the biggest impediment for companies who are not yet migrating from the 3000? Do you encounter many?

There’s a common view that companies are not jumping on this problem as quickly as people had thought. The reassuring thing I’d say to the HP 3000 community is: Don’t feel bad. You’re no different that any other migration market we’ve 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 fore.

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.

You’ve guided owners of other business systems to new platforms, so which other platform’s issues are the most similar to the HP 3000’s?

The HP 3000 market is different in a couple of ways. There’s wide use of third party products. I don’t think we’ve done one HP project that hasn’t had some kind of third party product involved with it.

The other thing that’s noticeably different is the “we’ll 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 “do-it-yourself” mentality.

Does that strike you as a favorable comparison?

All credit to the HP 3000 platform. It is repeatedly used to drive large mission-critical applications with large user counts. In many respects it’s used like a mainframe. There’s 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 customers?

[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 it’s anything like other migration markets, they will revision-lock, and it won’t be a problem [to stay]. We’re talking about a very stable operating system.

Let me tell you, today we are still migrating Data General MV users. Those people haven’t had any manufacturer support on their platform for many, many years. If you’re 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 best?

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 you’re past the convenience of a familiar software interface, you’re 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 don’t 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 don’t 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, we’ve seen a large transition to Linux from other Unixes.

Does the market support for Itanium concern you when you consider the future of HP’s Unix?

I’m probably not the person to answer that, because I don’t 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 that’s still planning a migration?

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 EOL’s 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 weren’t 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, there’s 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 year.

Is that end of 2006 date a serious deadline for many of your customers?

I don’t think the market sees it like a Y2K problem. Users are not terrified that on Dec. 31 their systems will fall apart. People feel they’ve 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 don’t start until late this year or early next year. They’re starting to get the budgets aligned. It’s close enough now that it’s real.