Alliances alter mindsets about Mac
Micro Focus takes new step into computing clouds

Reasons to delay a migration

The economy's swoon has had an effect on spending everywhere. IT is no exception, and the impact manifests itself in scheduling and milestones. A project which was going to take 18 months is revised for twice as long, or a start date is pushed back by a year to use funds from a different and more robust fiscal period.

The good news is that a delay in a migration might not be such a bad idea, when you consider the value proposition. So long as that HP 3000 is still working well enough, then Micheal Anderson of J3K Solutions, another single-expert solutions and support provider, has made a case for later rather than sooner.

Anderson has been working on migrations for 3000 sites. But right away is not the right schedule for everybody, he said.

You could benefit from waiting to migrate if you are not dependent on a Application Software Vendor and all is running well, using third-party hardware and OS software support. Some argue that by saying; “The longer you wait, the less likely it will be to find the expertise to do your migration.” I think there will be less expensive solutions available down the road; Independent contractors like myself will most likely be able to do things with less overhead; and maybe even develop user friendly inexpensive software that will do most of the migration for you. I’ve already developed some of these tools for my own tool bag (aka Flash Memory) — they’re just not user-friendly right now.

Anderson has worked on a COBOL/View/IMAGE migration to HP-UX using AcuCobol, SP2 thin-client, and Eloquence. Given his own choices, rather than those of the customer's, he'd prefer Linux/Fujitsu COBOL, SP2 and Eloquence with supporting/optional technologies like C, Java, PHP, Perl, and MySQL.

The reasons for his personal choices lie in adhering to independence. "Migration plans should include applications built on technology that will run on any hardware, operating system, database, and one that will be available for decades to come. Look at technology that stands on its own, technology that can’t be taken out by one choice from one company."

His technology choices, once you do proceed to migration:

1. Posix/Unix type operating systems (Linux).
2. Hardware that is high quality and generic enough to be updated easily without needing to repurchase the entire machine.
3. Databases like Postgres, MySQL,  Oracle and Eloquence that will run on most anything.
4. Compilers/Languages: C will be around forever, but not a first choice for application coding. For applications, COBOL still fits into the “Run on any hardware, and will not be taken out” category. Java also is a great choice for new development. I would not rely on any of the “Visual” languages because they seem to tie you to one Integrated Development Environment.
5. The IDE should also be language independent and OS independent.