Seamlessly Migrate Valuable Mainframe Technology with TSRI's AWS-Certified Engineers and Architects
As an AWS partner, TSRI's certified engineers and architects get mainframe software into the cloud quickly by leveraging our automated refactoring technology. Our near-100% automation process transforms legacy applications to cloud-native applications ready for deployment on AWS. Our model-based solution transforms even very large legacy systems—tens of millions of lines of code—written in more than 25 languages including COBOL, Fortran, PowerBuilder, Ada, MUMPS, and VB6 into modern applications in cloud-native target architectures. The output is a multi-tier application that takes advantage of cloud utilities and scalability.
TSRI's Migration to AWS Cloud
TSRI has extensive experience in all forms of legacy code transformation, including migration to cloud services and containerization. TSRI can move currently modernized applications to the cloud using cloud-specific refactorings such as targeting services, microservices, and containerization. Our migration services take a three-step approach:
Migrate legacy monolithic code to a service-oriented environment
Integrate service-oriented applications with native cloud services
Transform native cloud to Docker or Kubernetes containers and Lambda/API serverless framework gateways
AWS Sample Target Stack
TSRI has modernized multiple mainframe applications directly to the cloud. Below you will find a sample target stack that we have modernized and deployed in the cloud. We refactored this application to utilize an MVC-style architecture, introduced a RESTful layer, and modularized as well as containerized the application itself. TSRI can easily adapt this example to fit your requirements.
AWS Sample Reference Architecture
AWS Cloud Case Studies
For over 25 years, TSRI has focused on modernizing the world's most critical technologies. From retail and financial systems to mission-critical military applications, TSRI has successfully completed more than 250 referenceable projects, including modernizations targeting private and public cloud architectures. We are pleased to bring our experience to AWS cloud migrations.
A major component of the system was more than 50 years old, written in COBOL, and provided retail-level business logic. The component ran on mainframes that have proven to be extremely difficult to change and manage, and the Department of Defense needed to modernize the component to drive down operating costs and move to an open platform, while retaining all of its functionality.
by Phil de Valence, AWS
On behalf of a U.S. Department of Defense (DoD) client, our multi-company team—comprised of staff from ARRAY, NTT Data, TSRI, and Datum—delivered a successful modernization of a COBOL-based system running on aged mainframes to a Java-based system running on x86 Red Hat Enterprise Linux (RHEL).
Our combined goals: introduce agility, reduce costs, modernize the technical stack, and enhance security by leveraging Amazon Web Services (AWS). We did this using automated code conversion tools and techniques while maintaining all functionality, screens, and reports.
We set AWS GovCloud (US) as the modernization target to address the DoD’s stringent security and compliance requirements, such as U.S. citizenship.
The system we modernized, an ACAT III major defense acquisition program and mission-critical system, is used by more than 18,000 users in over 260 global locations. It provides daily supply chain and equipment support for DoD missions and serves as the accountable data system for more than $30 billion in inventory.
AWS provides the system’s capabilities for reliability, scalability, and availability with features such as availability zones (AZs), auto scaling groups, and Amazon Relational Database Service (Amazon RDS).These are the objectives, approach, solution, lessons, and customer benefits realized from this experience. ARRAY Information Technology is an AWS Partner Network (APN) Standard Consulting Partner.
CONTEXT AND OBJECTIVE
A major component of the system was 54 years old, written in COBOL, and provided retail-level business logic. The component ran on mainframes that have proven to be extremely difficult to change and manage, and the DoD needed to modernize the component to drive down operating costs and move to an open platform, while retaining all of its functionality.In the past, attempts made to modernize the component failed due to the massive size and complexity of the task. In fact, modernizing the component was regarded as such a difficult task that it was highlighted in the 2003 book Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices.
After 54 years of operations, maintenance, and extensions, the component’s code had become poorly documented. The technical design of the existing system, which was needed to support the modernization effort, had to be derived from the existing system and code.
Key characteristics of this component included:
- Annual operating costs of over $30 million, largely attributable to mainframe hosting and maintenance costs.
- 1.3 million lines of COBOL source lines of code (SLOC).
- A data management system, comprised of 1.2 million lines of COBOL code, that supported approximately 500,000 transactions per day.
- Few remaining subject matter experts (SMEs).
- Difficulty finding qualified, affordable COBOL programmers.
MODERNIZATION APPROACH AND SOLUTION
Our team had developed a trusted relationship with the DoD’s project management office over several years by delivering solutions that transformed and improved their supply mission.The DoD therefore contracted our team to modernize the component to become an integrated and sustainable part of the overall system.
We started the project by identifying and evaluating solution options:
• A total manual rewrite and re-architecting solution failed to meet the program’s time constraints, had historically low success rates (high risk), and would have been too costly.
• A replacement solution was not selected because the DoD needed to retain all the current business rules.
• A COBOL emulator re-host solution was a stopgap measure that failed to reach the J2EE/RHEL/SQL DB architectural future-state requirement.
This analysis led to our decision to use a COBOL-to-Java code automated refactoring solution, an option that would take a low-risk, incremental approach and apply a blended agile/traditional methodology and tools to ensure rapid, high-quality software delivery.
COMPONENT MODERNIZATION PHASES
Once the COBOL-to-Java code automated refactoring solution was selected, a three-phase approach emerged to meet the entirety of the DoD’s requirements and cost, schedule, and risk constraints.
Phase 1 (18 months): COBOL-to-Java automated refactoring to x86/RHEL platform
This was the most complex and risky phase, as we automatically refactored COBOL code from mainframes to Java code on a virtualized x86 RHEL platform while not losing any functionality or performance. The resulting Java code contained design remnants of COBOL, and development and test environments were moved to the AWS Cloud.
Phase 2 (12 months): Code-advanced refactoring to remove COBOL design overtones
We refactored the Java codebase even more to remove residual COBOL remnants, overtones, and design elements to improve maintainability.
Phase 3 (3 months): Infrastructure moved to AWS GovCloud (US)
We moved all remaining environments to AWS GovCloud (US) including staging and production. AWS GovCloud (US) allowed us to meet the many cyberthreat security requirements for the DoD.
Figure 1 shows our three-phrase modernization approach. The two Java logos illustrate the different Java phases. At the end of Phase 1, the Java program is “dirty” with remaining COBOL coding practices. At the end of Phase 2, the Java program is “clean” without COBOL remnants.
The modernization of the component involved a conversion of 1,260,679 lines of COBOL code and 10,078 lines of C code to Java to maintain current application capabilities, graphical user interface (GUI), and performance while migrating to an affordable and sustainable x86 RHEL platform.
The component’s COBOL online and batch applications were automatically refactored to run on a JEE platform using Java object-oriented software layers (data access, presentation, business logic) and patterns to enable migration to a standard x86 architecture.
The modernized Java software reused identifier names from the original COBOL application, allowing the component SMEs to read and understand the new Java code and routines more easily.
Rather than simply transliterating source COBOL code to target Java code, the tool executes a mature automated conversion and refactoring process by first constructing a comprehensive intermediate object model of the legacy system in an intermediate translation language.
Once modeled within the tool engine, SMEs employed an iterative process of applying rules and tuning to output the transformed code into the target Java language.
We completed the work of reintegrating items like schedulers and other utilities, testing the initial construction iterations of the code, and providing defects. In response to each construction delivery evaluation, we adapted the transformation rules and regenerated improved construction iterations of the code according to internal evaluations.
During this phase, we transformed the COBOL data management system network database code to COBOL with SQL. This COBOL and SQL code was then transformed to Java and SQL code.
PHASE 2: Advanced Refactoring to Remove COBOL Design Overtones
After we completed Phase 1, the resulting converted Java code contained COBOL paradigm design remnants, or COBOL overtones, that required personnel to have specialized skills to maintain the codebase. A plan was developed to identify and correct COBOL overtones with standard Java solutions. We considered this part of the effort low risk because we used approaches, processes, and techniques proven in Phase 1.
Our refactoring approach used TSRI’s JANUS Studio® tool and a semi-automated refactoring method that performs further code optimization, naming changes, and other enhancements to improve architecture, design, security, sustainability and performance.
We used an iterative approach that consisted of tool-driven automated refactoring, regression testing, and customer review to address the four most significant COBOL overtones existing in the component’s Java codebase:
• Refactoring the COBOL memory model to Java
• Refactoring the COBOL data mapping layer to native Java and SQL
• Removing COBOL-style control-flow/GOTO logic
• Identifying and removing redundant code sections
These techniques, along with the improved method-synthesis algorithm, greatly improved the maintainability of the Java codebase.
PHASE 3: Infrastructure Moved to AWS
After we completed Phase 2, the entire component was moved to AWS GovCloud (US), including the staging, production, and all support environments.
AWS GovCloud (US) was selected because it aligned with the future technical direction of the system. This included cybersecurity, DevOps, and automated continuous integration (CI) and continuous delivery (CD) tools. The component’s architecture was installed in AWS GovCloud (US) and continues to evolve.
For the DoD, the component has been transformed from an expensive mainframe COBOL legacy system to an affordable, modern, maintainable Java-based system. All valuable existing business rules have been preserved in the modernized system while development, test, and production environments were migrated to AWS, providing flexibility at reduced cost.
The DoD’s projected cost savings is $25 million per year, and they are now able to use easy-to-find Java programmers to maintain and enhance the critical component.
This project taught the DoD that automated refactoring projects are a viable approach to modernize major legacy systems, including complex COBOL-based mainframes, to preserve the existing business rules within a cost-effective, open system.
We can highlight specific lessons learned during this project:
• Code conversions via automated refactoring are a low-risk approach to modernize away from legacy platforms and migrate to the AWS Cloud.
• Breaking efforts into phases (modernize, migrate, etc.) keeps risk low and ensures mission success.
• Breaking away from legacy COBOL enabled a completely new set of sustainment opportunities, such as labor and tooling.
• Agile development models enable real-time course corrections and reduce delivery risk.
• Maximum automation is crucial in transforming millions of lines of code while preserving functional equivalence, reducing risks, and reducing the project timeline.
• The Java language target allows choosing from a wide range of cost-efficient reliable compute options. In this case, it allowed the elasticity and scalability to meet the mission-critical DoD system needs.
• Moving away from legacy proprietary mainframe and COBOL to an open Java platform allows access to a large pool of talented architects and specialists for design and operation.
• Suppressing proprietary COBOL technologies allows more cost-efficient and reliable application servers and databases.
Choose Your Path to
The key to a successful migration is to evaluate and model the underlying legacy code logic and to pinpoint those areas which must be adapted to the new environment. Not every application has a natural and hazard-free path to a cloud-based, containerized solution.
Multiple Approaches to the Cloud:
In software transformation, changes are made to deliver a new system that has the same functionality of the legacy system, but it is "transformed" to meet the goals of a specific project like cloud migration. TSRI's fully automated toolset ingests each software application and transforms it into a modern, native, object-oriented target language.
Transformation, coupled with refactoring, is the right choice for you if you want a functional-equivalent, cloud-native application that will be maintained and actively developed in the future.
The TSRI modernization approach includes refactoring and optimization of the modernized software systems. In performing this function, we can evaluate source code and model it, refactoring it into microservices that permit a flexible and modern approach to integration with cloud services.
TSRI's experience in over 250 legacy application transformations for major software systems includes innumerable success stories of re-architecture in moving older systems of a wide variety of languages and structures to modern architectures.
Rehosting, also known as lift and shift, moves but does not modernize an application. The application remains in its legacy language without any change to behavior, code, database, or UI.
Rehosting is a great solution if the application is not actively maintained, will be decommissioned in two to three years, and only needs to move off its current hardware or platform.
The solution retains the legacy language, so development and maintenance continue to be difficult, human resources are often scarce and quite costly, and the customer may be exposed to increased technical debt as fewer and fewer resources are available. The significant licensing costs associated with rehosting can also be unattractive.
Rehosting is a great temporary solution to leave a legacy environment and achieve savings quickly, which in turn can be used to transform or refactor the application. In fact, some of our clients have rehosted, then later transformed their application with TSRI.
A full rewrite means green fielding or reengineering an application from the ground up.
It is the most time consuming and expensive option for modernization and migration. Full rewrites require securing a team of engineers, PMs, and other resources. Additionally, you will need a thorough understanding of how to build the application to be cloud-native.
While it's possible to see long-term benefits, the high-risk, high-cost, and extremely long cycle—oftentimes measured in years—to release typically doesn’t achieve the desired value in most scenarios.
If your application and its functionality need to change dramatically (30%-plus change in functionality) then a full rewrite makes sense.
Yes, you are reading this right. You can indeed do nothing and push out your modernization journey until a later point.
While it makes sense to modernize your applications and get away from legacy environments such as mainframes and thick-client applications due to the functionality, security, and human-resource availability, we understand that sometimes the timing is not right... yet.
Even in this case we can still support you in the final modernization planning and provide legacy code-level documentation via our Application Blueprint® ("As-Is") documentation for over 35+ different legacy languages to support and lower the cost of your O&M maintenance costs.