Migrations probably begin with an application review that shows too much at stake to stay with MPE. It's not the OS of the 3000 that's found wanting, however. Usually there's a decline in support for a subsystem, or a development environment (think 4GLs). The 3000's databases have the same support ecosystem they've had for awhile: Third parties (indies) with database tools and expertise, or one company selling an IMAGE-compatible database for non-3000s. It's good to have the 3000's data structures known and emulated.

But migrations, once they're triggered by M&A or boardroom jitters or exiting 3000 staff, need a database. Here in the first week of March we're marking the one-year anniversary of the Oracle Stink Bomb. That's what the company threw at HP's enterprise customers who use Unix. Oracle won't develop for the HP-UX version of that database any longer. Your database choices in a migration have drifted away from the obvious.

While Oracle thinks that's a great way to turn HP's Unix customers into Sun Unix customers, the last year hasn't delivered the riches of database FUD to Oracle. Former HP CEO Mark Hurd has been explaining away a lack of Sun uptick at recent analyst meetings. Instead of Sun, HP's Unix users who wanted to migrate to a more stable DB environment are choosing IBM. Big Blue, after all, is still selling its iconic DB2 for Itanium servers.

It's worth noting that Speedware's legacy modernization services, and migration team, has been working with IBM customers for quite awhile. AS/400 accounts have been in that company's pipeline. DB2 has got to be familiar to one of the two remaining Platinum Migration Partners. A couple of research houses have whitepapers that report on IBM's success in taking away Oracle accounts. It's an odd mix but might be a potent one, if your migration budget is deep enough: HP's Unix, plus IBM's database.