Reasons to delay a migration
January 12, 2009
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.
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.