MB Foster has spent every other Wednesday teaching the principles of HP 3000 data management, best practices which customers are still using to structure their IT transitions. At a webinar this spring, one attendee said his company has been talking about migrating from the 3000 "ever since I've been here, 13 years," he said. "From our standpoint, the first decision that has to be made is, 'What platform?' "
That the kind of approach that flows from in-house apps, where doing a lift and shift onto another system means not purchasing a replacement software suite. Only 15 percent of customers are migrating code, while even fewer build a new system to replace what's on the 3000. MB Foster's Birket Foster said the decision to buy rather than build makes sense only to a company which has the resources needed to do the work.
"We look at whether customers should build, buy or migrate," Foster said, "and most of the time people buy. These days most folks don’t have the skill set to build. Only in a totally unique business will you get some competitive advantage from building the application. Otherwise, you should really consider buying something off the shelf."
Foster said that following a three-phased approach ensures the fewest risks. First you assess, then plan, then implement. Migration might not be the end of what you're going to do, he said in the 45-minute webinar. "It might be the first stage, to integrate better into the company's operations. While HP 3000 migrations have come into sharp focus during the last 10 years, MB Foster's got 25 years' experience migrating data. That data is the fuel that drives any migration.
You'll be waiting for data, he adds, because "All applications have some bad data. You need extract, transform and load -- or extract, clean, transform and load tools in place. You need to do this early. When we get into these, we find people start looking to learn what their history policy ought to be."
One customer in the webinar said his company using MANMAN had narrowed the target applications to SAP and Oracle, but had also started to contemplate when to begin migrating work. Foster said the more important question to ask is when you want to be finished.
The customer said, "We've been hearing 'by the middle of next year,' but we've been hearing that from our senior management for 13 years now." In that case, he added, "it means they should have started more than a year ago. But it's hard to commit when we don't know what we're moving to, or when."
Buying a replacement application means "you'll probably look at three to seven packages to find the correct application," Foster said. "You also have to understand any reengineering tasks involved. That's the hard part, the things that take users through a lot of pain, because they have to re-learn the way they do things. Plus with SAP, "Most of what you need to do is understand what the business re-engineering piece will be."
Building an assessment report identifies all the tasks to be completed, organized in order of magnitude. One choice that shouldn't consume much time is deciding which platform to migrate toward.
"It doesn't matter," Foster said. "The only thing that counts, to tell you the truth, is something that your team will be able to support for a 3-5-year period. They all perform about the same, they're all starting to cost about the same. The cost is much less than it used to be. You'll probably spend between six and 24 months doing this process. Once you've got everything ready to go, you have to figure out how to do the cutover."
10 other systems surround the customer's MANMAN system, with the 3000 feeding data to all of them. There's plenty of chatter but no movement yet, a logjam that could be broken with an assessment. "You need to determine time, and the big thing people underestimate drastically is the amount of testing you need to do before you go live. Typically, people estimate about one-third of the time it really takes."
Migrating companies should not rely on doing their own work with existing staff. "You want to make sure the project is staffed properly: that you're not trying to take full time people and leave them on their job, plus make them do this migration as well," Foster said. "You can do that for a week or two, maybe, but it gets old after six months."
The bedrock best practice is knowing what's to be done through an assessment that leads to a plan. If you don't do the planning, "you'll end up with a stalled project," Foster said as he wrapped up the webinar. And even the best planning needs to have people with experience and a great project manager running it. Planning solves the problems with applications and making sure you've mapped all the functionality, the problems with mapping data, and makes sure you have the right skills on the other side of the migration when you need them."