Danish(DK)English (United Kingdom)
Devil #1: Migration of systems


I bet you do keep your warehouse tidy - as well as the office and you home - but how regularly do you clean up your IT systems?

Research suggests that over 250 billion lines of COBOL source code is still in production.

And often obsolete code entails large problems and costs.
  • Do you run obsolete code on obsolete equipment with major costs associated?
  • Do you find it difficult to retain or hire new employees?
  • Is it increasingly difficult to fix bugs or introduce necessary changes?
  • Are you forced to use an obsolete infrastructure?
  • Are you fully aware that the oil IS running out - but find it difficult to take the necessary steps?

It is not for everyone to be at the cutting edge of new ideas. But many use that as an excuse not to plan for the future until it actually happens.

What can you do?

This depends on where you are, and where you want to go.

Here I can help with my very broad knowledge, and my extreemely good memory. I know many different technologies - both current and historic - and their strengths and weaknesses. I have solid experience analyzing an IT landscape, og giving a concise description followed by pragmatic recommendations.

And when you have decided where you want to go? Then you need to consider your migration strategy.

You have several options:
  • "the lazy" - buy a commercial-off-the-shelf packaged system, and migrate to that
  • "the dramatic" - rewrite the whole system
  • "the elegant" - convert code and data to new technology
  • "the fatalistic" - do nothing, and hope the problem solves itself

Every method has its advantages and disadvantages.

"The fatalistic" is clearly the cheapest and easiest in the short run - and who knows? Perhaps another person is responsible for the system by the problem can no longer be ignored?

"The dramatic" is best, if the demands on the system have changed much since the system was constructed.

"The elegant" is good, if a 1-1 conversion is suitable, and the amount of code or data is non-trivial.

And of course you can combine approaches for various parts of the system. You could call this "the mixed".

I can help with all types of approches (except perhaps "the fatalistic" Smile).

Especially "the elegant" is something I have experience with. Existing code - in say COBOL or FORTRAN - and existing data files can often be converted automatically.

I have used parser systems like JavaCC and OpenVMS SCAN to migrate code written in IBM COBOL/CICS and Delphi Pascal and I have started working with Eclipse Xtext and Xpand - see presentation here.

What do you achieve?

The end result is a modern system, that is easier to maintain and develop further, a system that is more exiting to work with for users and employees, a system that is less costly to operate.

And if you migrate to open source based systems, you also extract your company from a vendors tight reins.

Selected references

  • Migration of IBM COBOL/CICS/IMS to VAX COBOL/ACMS/RDB - look here
  • Migretion of DDE Pascal to VAX Pascal - look here
  • Migretion of Delphi Pascal to Sun Java - look here
  • Import/export of Tandem data dictionary to VAX CDD - look here