Why mainframe migration is more than technology transformation

British author and novelist L.P. Hartley once said, “The past is a foreign country: They do things differently there.” This sentiment is especially true in the realm of mainframe migrations, which often trigger unforeseen changes across an organization.

Processes established in mainframe environments tend to be delivered as centralized internal services with critical capabilities, such as maintenance, security, and support. However, these centralized processes and delivery are also bound to transform when migrating applications and workloads to cloud environments.

Centralized delivery has proven effective at lowering costs through consistency, shared engineering resources, bulk discounts, and specialized understanding of organizational requirements. At the same time, finite resources also hindered scalability, flexibility, and speed; any initiative that tangentially touched the mainframe had to be coordinated centrally.

But as cloud migrations near the finish line, many organizations suddenly realize they will need to replicate the same work once carried out by their mainframe teams — and they have new power to make changes. Here, deep expertise from a cloud provider or partner can prove invaluable for helping organizations get the most out of their transformations.

At Google Cloud Consulting, we've helped organizations navigate this complex journey countless times, witnessing firsthand that transformation is not just about technology but also people and processes. In this post, we’ll share three areas where you can expect the biggest impact and change when migrating from mainframes to the cloud.

Maintenance: The difference is in the design

We frequently advise customers to design away the need for processes, so they don’t become a bolt-on activity that the new cloud team needs to worry about. For example, opting for a Google Cloud managed database, such as AlloyDB, CloudSQL or BigQuery, can remove many of the utilities and maintenance tasks associated with on-premises databases or data stores. Instead of worrying about nightly backups or annual database reorganizations, these processes are automated and managed by Google Cloud.

Similarly, Google Cloud can automatically perform OS upgrades and patches by rotating GKE instances on a regular basis (e.g., 30-45 days). Organizations can define this in their policies and integrate rolling out the new OS images into their CI/CD pipelines. In this way, these processes become part of the normal development lifecycle rather than a separate activity that must be monitored and managed.

Of course, teams will still need to test backup and emergency restore processes regularly. However, testing doesn’t have to be particularly onerous. The intrinsic network isolation combined with on-demand capacity means it is quite possible to spin up a disaster recovery environment, restore a database, run the tests, and tear it down again — all without any disruption to the production environment.

Compared to the centralized processes they replace, maintaining and updating cloud-based applications generally takes a fraction of the work and time associated with the same tasks for on-premises solutions.

Security: Everyone gets a key (well maybe not)

Dealing with security is often another challenging transition during migrations. Google Cloud offers encryption at rest by default, but in isolation, that is not always enough. There are additional steps, such as rotating keys, to consider. With the move to a cloud environment, rotating the keys becomes the responsibility of the organization.

Where a mainframe may have been grandfathered in with the minimum acceptable solution, many organizations take the opportunity to step up their security controls when migrating to the cloud, which can create new burdens. In mainframes, the same key might be used for all data. In the cloud, applying the same policy to everything, everywhere, is illogical.

A common pattern we see for success is pushing the responsibility of rotating keys down to each product or application owner. This allows for different rotation policies based on the data; keys for data that require the highest levels of PCI and PII protection might be rotated every 90 days, while public data may be every 12 months. This pattern also shrinks the blast radius related to compromised keys. The goal is to tailor the policy for the data and any local laws, improving the overall security posture with nominal additional effort.

Similarly, cloud compliance is a crucial issue to address. Compliance audits are time-consuming, but they also play a critical role in helping organizations ensure transparency and safeguard their data and cloud assets. The trick to a successful audit is supporting policies and documentation with an electronic trail that shows compliance. The beauty of the cloud is that it’s easy to layer organizational policies on top of existing cloud documentation and use logs from products and services as proof of meeting requirements.

Support: New responsibilities, better solutions

There’s nothing worse than a 2AM call because something has failed (bad) or is limping along (worse). The tightly integrated nature of the mainframe used to mean that support primarily fell to a core on-call team with the skills and security permissions to troubleshoot mainframe problems from the ground up.

With a migration to Google Cloud, we are responsible for providing the instructure, but we have little to no insight into what is being executed. Therefore, support will shift to individual product teams — a new responsibility, but one that comes with a lot of help.

Whether it is a Single Pane of Glass or a “Single Glass of Pain”, Google Cloud Operations contains a fully integrated suite of metrics to assist troubleshooting. These metrics can be optimized with plug-ins to reflect an organization’s particular technology stack.

In addition, the cloud also offers new options for resolving issues — ones that don’t require debugging on a call in the middle of night. For instance, it’s now possible to simply isolate the instance having the problem from the cluster and spin up a replacement in seconds, leaving customers to get on with their lives and teams to solve problems in the morning with a cup of coffee.

Final thoughts

Embarking on a mainframe migration journey is both challenging and rewarding. Taking on new roles and responsibilities can be exciting, but it’s likely to be a bumpy transition for existing teams that have spent decades honing their skills in specific roles. Organizations should accept this up front and plan accordingly, eliminating as much as possible through design and automation.

At Google Cloud Consulting, we understand the intricacies of this process. Our team is dedicated to helping clients navigate these changes, leveraging our deep expertise to streamline the transition, automate processes, and empower organizations to embrace the full potential of the cloud.

Read more about how Google Cloud approaches mainframe modernization, or drop us a line if you want to chat with one of our experts. Our invitation is open: connect with us at Google Cloud Consulting to explore how we can tailor a migration strategy that aligns with your organization's unique needs and goals. Together, we can turn the challenge of mainframe migration into an opportunity for growth and innovation.