Mainframe migrations are happening in large companies across the country today. But why? Somewhere, in a data center far away, the mainframe sits. Unseen by most IT personnel, it runs mission-critical applications, and it has probably been doing this for decades within your company. Many Fortune 500 companies from the insurance, banking, healthcare and finance sectors still use mainframes today.
Mainframe computing started in the 1960s and the term mainframe was more a description of the type of hardware. Now, the mainframe is made up of servers, just immensely powerful ones. However, there are challenges when running applications on the mainframe. They can include the cost and finding resources with mainframe expertise. The image below is a very old depiction of the mainframe. I think this is how some folks still view it as!
Operating costs for a mainframe are significantly higher than distributed servers. From a cost perspective, running a mainframe is often the largest IT expense within an organization. These costs are usually fixed and based on CPU usage, storage, and memory. The more applications you have running, the more resources you need. Depending on the size of your mainframe, the costs can be over 1 million dollars per month.
Technical resources for mainframes are also expensive. There are fewer people available who have the necessary skills to maintain the application code and the actual infrastructure. This is due to mainframe experts retiring and the lack of new resources as most technologists want to learn the newest languages. My experience with a recent modernization was that the people who knew COBOL were a mix of newer and veteran IT people but the experts who understood the mainframe itself had been in that space for a number of years.
This has caused companies to investigate switching from the mainframe to the cloud. The thought is that with cloud infrastructure, applications can be placed on virtual servers that can be scaled up and down when required which would save money, and the resources to maintain the infrastructure would be easier to find since cloud computing is so popular.
Mid and large companies that still use mainframes probably have millions of lines of COBOL code for applications that may have been running for well over 20 years. Rewriting those applications to a more modern language would take years due to the lack of application documentation and available subject matter experts. A better solution is performing a mainframe migration by moving the applications off the mainframe onto a distributed runtime like Micro Focus COBOL running in the cloud.
First, you need a list of online and batch applications running on the mainframe along with integrations upstream, downstream and between those applications. If you are lucky, the company will have included these in your CMDB or application catalog. Much of this information will also be available from run books, application documentation, and interviewing in-house subject matter experts. This will only get you so far though. As mentioned earlier, most of these mainframes have been around for decades and information gets lost over the years. This is where an application intelligence platform (e.g. environment scanning software) comes in handy. It can be used to generate a view of applications, jobs, and interfaces which can augment the lists you’ve come up with already. Using the information gathered, you should be able to draft a current state design if one is not already available. A Component Diagram is a great view of the components and connections that make up a larger system. This is an ideal way to give people a good understanding of the applications in scope.
Once you have the list of applications and interfaces, you need to decide what order the migration of the applications should be. It’s possible but not probable that you would migrate all the applications at once due to the number of applications and the complexity surrounding them. Some things to consider would be:
I would recommend starting with the simpler applications to gain some lessons learned for when the more complex and critical applications are migrated.
There are multiple options on how a migration can be done. AWS has a good framework called The 7 Rs. The 7 Rs are:
To decide on which best fits your migration, go here: AWS Migration Strategy. The approach works regardless of the cloud platform you are migrating to!
To get buy in from stakeholders, it would be a great idea to complete an Options Analysis which would outline the pros and cons of each one. You would then use the analysis to get to a final decision from the pertinent stakeholders on which migration strategy fits best for your situation.
We decided to go with Replatform and run our applications using Micro Focus COBOL on EC2 instances.
It is very important to understand what all the different interfaces are. Some existing application integrations that are on the mainframe may not be supported on Micro Focus COBOL. One example is the CICS API Front End Programming Interface (FEPI). This allows CICS programs to be written that can access existing CICS screens like they were an actual user and ‘screen scrape’ the data displayed on those screens. These FEPI programs would need to be migrated to a more modern interface like a web service.
Another interface ‘gotcha’ is when you have 2 applications that communicate with each other over a CICS link. This works fine when both are on the mainframe, but a lot of thought will need to go into the solution when you migrate one application while the other stays on the mainframe for some time.
For the AWS environment, you should follow The AWS Well-Architected Framework. This is not a technical design article so I won’t go into design decisions on how you should deploy the applications. You do need have awareness of data transfer costs though. There is a cost for data transferred from your AWS account back to your data center since it will be going over the Internet. I’m assuming here that some on-premises applications will still require data from the applications you are migrating out of your data center.
Application security is an additional layer of work that will take some time and thought. User authentication on the mainframe is handled by products such as RACF and Top Secret. The user accounts will need to be migrated to something more modern such as Azure AD or OpenLDAP that can be used with the applications now in the cloud. The process of requesting, provisioning, and approving new application users will also need to be hashed out. Hopefully you can reuse an existing AWS user provisioning process already in place for your other applications that are in the cloud.
User authorization requirements have become more stringent over the years since the applications were originally deployed on the mainframe. One example of where this can be an issue is authorizing the calling of CICS web services previously hosted on the mainframe from an on-premises application. If the client is an application calling the service on behalf of a logged-on user, the service should validate that the user has the proper access to the data being returned. If this is not being done, you run the risk of man-in-the-middle attacks and failing company application security requirements that were probably not in existence when these services were created.
Security, of course, is just one of the categories of non-functional requirements you will need to address, but, as always, it remains a very important one! Apply your organizations standard design process to each application as you migrate it,
From a testing standpoint, ideally you will have the ability to perform equivalency testing. This is comparing the application functionality, response and results you’ve seen on the mainframe with the same application once it’s been migrated to the cloud. The need for multiple test environments must be thought through also. Our experience with this was that having the usual test environments (Dev, SIT, QA, etc...) was not enough. Based on build and release schedules and the number of applications that integrate with an enterprise level application, this can drive the need for individual environments for some teams.
In conclusion, undertaking a mainframe migration can be a daunting task. The good news is that there is a wealth of information available and experienced consulting partners that have done this before to help you on your journey. Here are some links to get you started.
To view some of our other blogs, please go here: Posts - Wittij Consulting
Good luck with your migration!
