The Mainframe Migration Continuum (part 1)

No two mainframe environments are the same. As simple as that sounds to say, it is important to think about what it really means as it relates to the topic of mainframe migrations. Even though mainframes have been around almost 60 years, none of them look today as they looked the first day they were put into production. Over the years, software was added, 3rd party tools were utilized, and different data technologies were brought into play. That is why there are so many alternatives in terms of mainframe architecture that exist today.

Mainframes that started off using punched cards for data evolved to flat files, then VSAM files, then DB2 or IDMS or ADABAS, or something else entirely. Key-punched data entry became green screen data entry, which moved to graphical front ends and then on to web service enablement. COBOL and Fortran and Assembler programming languages started to share the development platform on the mainframe with C and java and 4GL languages.

So, when you consider what the “typical” mainframe is, it is easy to see that out of the multitude of components that may make up the mainframe architecture, there really is in fact no “typical” mainframe environment?

Why is that important when we discuss mainframe migration? Because it means there is no one single landing point that is right for every company that is considering moving off of the mainframe environment. Let’s look at the possible landing points along the continuum of migration options.

Readily Available Data

The concept of data warehousing became popular back in the 1970s and is still relevant for companies today. Being able to take snapshots of data, move it to an open system platform that is less expensive and then make business decisions against that data was the forerunner of migration practices. While the actual work and accumulation of data stayed as it had with all work being done on the mainframe, being able to work with snapshot copies of the data made it easier to make decisions in ways that were not possible prior to the implementation of data warehouses. And today, data warehousing has started to share the stage with big data, which offers the ability to work with massive amounts of both structured and unstructured data.

Lift-and-Shift

The Lift-and-Shift paradigm is one that has been in place for 20 plus years. Simply put, it allows a mainframe environment to be “lifted” from the mainframe and “shifted” over onto a lower cost platform, with the functionality staying exactly in place.

This methodology is perhaps the least risk intensive of all mainframe migration strategies. By default, it is designed to keep the business rules and data associations that have worked perfectly for years on the mainframe in place, albeit on a much less costly platform.

Code Refactoring

As wonderful and solid as many heritage computer languages have been, the future shines brightest on newer technologies. In truth, there are not many mainframe shops where just the classic languages are still in use. Most organizations over the years have chosen to expand their capabilities and developed not only on the mainframe but also off of the mainframe when it made the most sense. So, while a shop may still have thousands of COBOL programs in use, they may also have thousands of Java or .Net (c# or vb.net) programs in use as well.

Moving forward, it is easier to hire team members who know those newer languages than who know the classic languages. So, moving the code base to a common denominator is much more likely to be the chosen solution for companies than trying to keep everything in the classic languages.

Cloud MIgrations

Astadia has been helping companies move to new environments for 30+ years. In the early days, the migrations were always to lower cost open platform environments. However, in the last 5 years, the cloud (whether it be Azure, AWS or Google) has become the preferred landing spot for companies looking to migrate from the mainframe.

Whether the resultant implementation is a Lift-and-Shift model or a refactored model, an increasing number of organizations today are looking at cloud models that allow them to scale in ways that match their business needs. Both business agility and the need to adjust for consumption variation demand that businesses have the ability to quickly and safely change their processing models to follow ever-changing business needs. And that is an area in which cloud processing shines.

Why do companies consider migrating from the mainframe?

In the many years that Astadia has been helping companies migrate from one platform to another, we have had the chance to understand what drives companies to look at alternatives. It is obviously important to understand the reason(s) for the goal of migration so that a solution can be crafted that satisfies that goal. In general, we have seen that there are three major factors that cause organizations to look at migrating off the mainframe.

Cost Reduction

It is a no-brainer to state that cost is the major reason that companies look for alternatives to the mainframe. While some companies do already own their mainframe, many pay every month for the right to continue running on the mainframe. Moreover, it is not just the cost of the mainframe vendor’s hardware and software that is part of the reason to look at cost. As mentioned earlier, mainframes have evolved over time, as have the number of third-party tools that can run in those environments.

Many times, it is the cost of those third-party tools that is the driving factor to make people start to look for alternatives to their current processing environments. As organizations start to look at what percentage of their overall budget IT represents, many of them over the years have been led to the conclusion that they really need to consider alternatives.

Resource Availability

This author is a member of that aging group that was programming on the mainframe back in the early 1970s. The irrefutable fact is that fewer of those people who were programming back then are still doing so today. Even more worrisome is that more and more of that group of people are looking to retire. When organizations look at their COBOL or Assembler inventory, they have to worry about who will maintain that logic.

In so many cases that worry has caused companies to look at alternatives to get to an environment where it is easier to hire and retain personnel to keep the business going. Even worse than an application programmer shortage, when companies look at their system programmers and how hard it would be to replace them, they have to consider alternative environments where it is easier to hire network and systems personnel.

Extensibility

Most people would say it is easier and quicker to develop a new application off the mainframe than on it. The myriad tools that exist in today’s market have evolved quickly over the last years. Re-utilization of development assets like with the .Net Framework classes or even the availability of plug and play application components like with the NuGet repository means that organizations don’t even have to write complete applications anymore. Instead, they can leverage the base frameworks provided from open source tools and address business problems more quickly and with more accuracy.

Being in an environment where it is easier to take advantage of those extensibility advantages has led many companies to step back from doing business the same way they have for the last 50 or 60 years. Being responsive to the need to get applications working quicker as business needs change is the reason some companies have excelled in today’s competitive business environment.

The next part of this blog article will address the question “Where Do Companies Want to Land on the Migration Continuum?”