As more organizations embark on mainframe modernization journeys, Google wants to make sure they head down the right path. The company outlined common pitfalls and antipatterns businesses face when migrating or modernizing their workloads.
“Migrating or modernizing your mainframe workloads is complex and challenging, even under ideal conditions,” Travis Webb, solutions architect at Googe, wrote in a blog post. “If you avoid the antipatterns discussed in this document, you increase the odds of a successful transformation.”
RELATED CONTENT: Mainframe for DevOps puts an end to silos
While these approaches may work for some circumstances, Webb warns against them because “they have a high probability of failure.”
According to Webb, the three most common antipatterns are:
- Big bang rewrite applications: Rewriting or re-architecting your legacy mainframe code into a more modern language or design patterns can help speed of application development and future-proof solutions, but it’s a capital-intensive and time-consuming endeavor, Webb explained. Risks include budget overruns, unanticipated complexity and staff turnover. “Even for companies that have the tenacity to see through a multi-year transformation effort, the raw cost of a rewrite is often prohibitive. When compared to all other approaches, a big bang rewrite is the costliest way to modernize your mainframe software,” Webb wrote.
- Lift-and-shift migration antipatterns: Organizations are often tempted to move an application from one system to another, for instance moving the mainframe into the cloud. This can be a quick way to get away from an on-premise environment, but organizations still remain locked into the mainframe ecosystem and dependent on an emulation layer. “That dependency can result in a new set of technical challenges. Challenges that are often unfamiliar to the teams maintaining the mainframe software. Unfamiliarity can lead to additional reliance on a new, single-vendor cloud ecosystem,” according to Webb.
- In-place modernization antipatterns: With this antipattern, instead of rewriting and re-architecting mainframe code, you focus on the quality, maintainability and testability of software — but you still are subjected to the same risks of a big bang approach. “Any approach involving manually updating your mainframe software can have budget and time constraints. These efforts also often suffer from the second-system effect. Performance and correctness issues inevitably arise because rewriting business logic in a new language requires extensive testing before it aligns with the previous functionality,” Webb wrote.