top of page
  • MOST Technologies

Mainframe Migration Strategies Explored

Updated: Jan 30, 2020

(October 2019)

The story goes that, during the space race, NASA scientists discovered that pens could not function in space. To solve the problem, millions of dollars were spent to develop a pen that could write on paper where there was no gravity. Meanwhile the Soviets simply handed their cosmonauts pencils.

This well-known story is a myth and entirely untrue.

There are a lot of myths surrounding the issue of mainframe migration. Before embarking on such a critical project it is important to explore the possible strategies, understand the risks and opt for the best solution. In spite of what you may have read, one solution does not fit every customer.

Why Migrate

  • Maintaining the mainframe is considered very costly.

  • Although the mainframe is still alive and fighting, IT personnel with a mainframe background are a disappearing breed. The computer programmers of today are looking for more modern environments and challenges.

  • In a world controlled by ever evolving technology, there is a need for faster application changes using modern software rollover methodology such as DevOps and scrum.

  • The company's main core infrastructure is now employed on distributed open platform systems.

What to Migrate

Software - Mainframe Software contains a treasure chest of historic business logic in classic languages such as COBOL, JCL, Natural, PL/1, and Assembler.

Databases - The mainframe supports a variety of databases and sequentially stored data, many of which are not supported on a distributed platform such as IMS, VSAM, GDG files and more.

Infrastructure - The mainframe supports a multitude of software packages, utilities and infrastructure that need to be addressed in any migration effort.

When to Migrate

Don’t wait until all legacy system knowledge has left the company.

What are my Possibilities?

  • Retain

  • Retire

  • Re-host

  • Refactor

  • Rewrite


Before embarking on a costly mainframe migration project it is important to determine the reasons for initializing such a project. Obviously the easiest decision is to do nothing. However, as stated above the lack of future IT support for mainframe legacy systems due to decreasing knowledge and expertise can be catastrophic when envisioning the future.


Sometimes a system that provided the backbone of a company's business is no longer relevant due to changing business trends and priorities. In such a case it might be prudent to explore the possibility of retiring the system completely.


Re-hosting a mainframe system means transporting the existing processing along with the existing code to a physical or cloud based LUW platform. This is especially relevant and attractive when a customer wants to quickly move off the mainframe in the least risky and most cost efficient way. Re-hosting provides a lot of advantages:

- The migration is done using automatic tools

- The original code including decades of proven business logic are preserved

- Because the source and target code is almost identical automated regression testing can be performed.

- There is little training necessary as the target programming languages are the same as the source ones.

- The system and interface delivered to the end users is identical to the what they are already familiar with.

- Once on the new platform, phased modifications to the systems can be done without endangering the core processing.

- The programmers now work in a modern GUI programming environment


Refactor is similar to re-hosting in that it retains the existing business logic and processing but it adds the automatic conversion of the code to a more modern programming language such as C# .NET or Java. This strategy is particularly attractive to companies who want to move away from traditional mainframe programming languages such as Cobol, PL/1 and Natural. Refactoring also provides many advantages:

- The migration is done using automatic tools

- Because the conversion is done on a line by line basis, the business logic, as found in the original code, is preserved as is the original mainframe code that is kept as comments.

- Even though the code is now in a different programming language, outputs and screen flow are preserved thus allowing for automated testing.

- The new code is generated in modern programming languages that are attractive to modern day programmers

- The delivered user interface is very similar to the one the end users are already familiar with. The HTML5 interface can now be easily adapted and enhanced.

- The programmers now work in a modern GUI programming environment

Rewrite -

Many shops initially find attractive the idea of rewriting a system entirely or replacing the entire system with an off the shelf software package. The immediate advantages for such a strategy seem obvious. New is good because it allows you to rethink and start anew. Opting for a ready-made package is often even more attractive – using what works for others reduces future headaches. However it is important to address the risks and possible pitfalls in adopting such strategies:

- Rewriting from scratch requires deep analysis of all the existing business knowledge, redesign of all interfaces and processes.

- Compared to other strategies, rewriting is generally a much costly strategy and takes much longer to complete

- Rewriting projects tend to go over budget some failing entirely and abandoned midway

- Off the shelf packages are by definition a one solution fits all. In reality much of the specific existing business logic is unique to the company and thus requires adapting the off-the-shelf software to the company's needs. This problem magnifies for financial and governmental systems that have specific needs that are unlikely to be supported by a common software package. If adaptation to the software is required, how will future versions of the software support such changes?

- In a world that's constantly changing, opting for a long term project such as rewrite might make the new system technologically obsolete before it even goes live.

How to migrate safely

Automation - One of the keys to a successful migration strategy is the percentage of automation involved. The use of automated tools in a migration project is often the key factor that defines its success. Automated tools can be used for assessment, project scoping, phase implementation determination, code conversion, data migration and regression testing. Because it is generally necessary to continue maintaining and enhancing the existing mainframe systems, during the period of the migration project, it is crucial that the changes can be incorporated automatically to the migrated systems.

Don't try and do everything at once – companies sometimes want to combine the migration together with a face lift (either of business logic control or user interface). Trying to combine too much into one project complicates testing (regression testing is no longer a feasible option) and adds unnecessary risk.

Reduce Risk

Along with the considerations listed above the following are important to reduce risk:

- Priorities and goals must be clearly planned out before choosing a strategy

- Check that the ROI for the migration strategy makes sense to the company

- Proven tools for migration projects are available, don't try to reinvent them

- When approaching a migration project the vendor and customer should act as partners with a common goal - there should be no them & us

In Conclusion

If one hat would fit all heads, our world would be a very boring one. Every migration project is different and presents its own challenges. Understanding this is the key to a successful project.


bottom of page