Frequently Asked Questions

The Updraft modernization factory relies on a rules-based translation engine that’s generic and easily adapted to new programming languages. Most of our engagements have involved migrations from mainframe COBOL applications to Linux-based Java applications, running on either client-server or cloud architectures. We have also delivered solutions involving Java-to-Java modernization, Java-to-stored procedure modernization, ColdFusion-to-Java modernization, and several modernizations of proprietary programming languages. We continue to add new capabilities and languages to the factory. If your language isn’t listed, please reach out.

A legacy online application typically involves both a user-interface portion as well as a back-end portion that the user interface interacts with. For example, a common framework for online applications on the mainframe is CICS. CICS provides a user interface through BMS maps that render the familiar “green screens” on terminals. It also provides a transaction-processing mechanism that mediates the interaction between the terminals and the back-end server-side processing. The Updraft modernization factory transforms the server-side portion to execute a server application in the chosen future-state target environment and migrates the terminal screens into HTML5-based web front-ends. The web front-end is translated like-for-like, but customization and branding is afforded through CSS hooks in the rendered HTML. You may also want to completely reimplement the user interface in a more modern style. In this case, we provide an API that the modernized interface can latch onto to interact with the back-end server process.

Much mainframe legacy processing is performed as batch. Typically, a JCL job is initiated by a schedule, which in turn invokes other JCL procedures, external utilities, or COBOL and other programs. The Updraft modernization factory transforms JCL into a scripting language, such as Groovy, or a programming language, such as Java. Supporting utilities provided by the mainframe vendor are either translated into corresponding utilities or mapped onto services provided by the future-state operating environment. The COBOL programs are translated to the future-state language. The resulting programs and scripts all work together to provide the behavior of the legacy program.

Utility and sort programs provided by mainframe vendors are migrated to supporting programs in the future-state environment or directly realized by services provided by the future-state operating system. You can integrate third-party utilities into modernization batch scripts translated from the JCL through well-defined APIs.

When the future state involves migrating a database off the mainframe, the code that queries the mainframe database, the queries themselves, and the processing of results and return codes may need to be adapted. The Updraft modernization factory takes care of all such required adjustments. For cost or performance reasons, modernization may require migration from one database to another, such as DB2 to PostgreSQL. This modernization demands that the SQL code in the queries is changed to account for the differences in the dialects of SQL. The Updraft modernization factory will make the required changes to the SQL queries during migration.

When application code is migrated, the way it accesses files will be migrated accordingly by our Updraft modernization factory. While flat files also exist in the typical future-state environment, indexed files do not. Our modernization factory will instead represent indexed files in a database, so that the modernized code can access this data through database queries. Typically, a lightweight, in-memory database such as SQLite will be used, but a full database could also be leveraged. Files can be accessed as encoded in either ASCII or EBCDIC format. You are responsible for performing any necessary file-encoding conversion.

Updraft solutions have been deployed to AWS, Heroku, and Azure clouds. However, the Updraft modernization factory is easily customized to other cloud targets, as needed.

Migrating legacy applications to the cloud using the Updraft modernization factory creates the architectural choices and scaling strategies you require. Services will be transformed into cloud-native applications where appropriate and involve load-balancing and resource-management servers, cache servers, system monitoring, and cloud-based file systems and database servers. An application will typically be distributed over a number of instances by the load balancer. An orchestration layer may be integrated, if desired. To support further scalability, a typically monolithic legacy application will be decomposed along dimensions such as use cases, transactions, or interaction steps.

An application modernized by our modernization factory typically relies on a runtime library providing low-level services. This library is available in source-code form under a no-cost, perpetual license, which you can modify at will. There are no strings attached. All the migrated code we provide is in source form without costly dependencies.

No specific third-party software is required. We customize our modernization factory to your desired future state so that the modernized application can be deployed without further adjustments. That future state typically will include third-party software, and we will customize the factory to leverage such software where needed. When no client preference exists, we’ll suggest standard solutions. For example, log4j is typically used as a logging solution for Java-based applications.

We are well aware that migrated applications will continue to be enhanced in the future, and that ease of future maintenance is an important success criterion for any modernization. Our goal is to make the modernized code as maintainable as handwritten code. To judge the success of any modernization project, the migrated code must be assessed against your coding standards. If the migrated code meets the same coding standards that your handwritten code must meet, maintainability is assured.

Using COBOL-to-Java migration as an example, our solution relies on native Java types as much as possible and uses only familiar Java control structures. For example, the Updraft modernization factory eliminates GOTO transfer of control because there’s no natural counterpart in Java, and literally translating a GOTO into Java would result in an unnatural Java realization. The COBOL language supports other features that do not have a counterpart in Java, but for performance reasons cannot always be avoided – such as data redefinitions and pointers. Where possible, our factory will eliminate such constructs before migration. When these must be emulated in the resultant Java code, they will be implemented using a well-documented and easy-to-understand API. Documentation and further training is available to support maintenance of the resulting application.

Modernizing a large application often also raises staffing concerns with respect to future maintenance. Team members familiar with a legacy application typically don’t know the future-state language, while those who are familiar with the future-state language are unlikely to know the legacy language or application. To smooth every handover, we suggest that the overall control flow of the application initially mirror the legacy application. The application can be further refactored automatically at a later stage once the new maintenance team has become more familiar with the modernized application.

Legacy applications, in particular those that are mainframe-based, are usually monolithic. Such applications often support multiple use cases, but the programs realizing these use cases are intertwined and not easily separable. The applications may support many users, but must perform each user interaction as a sequential transaction. If translated literally, scalability and maintainability of the modernized system would be lacking.

The Updraft modernization factory peels off the separate services provided by the monolith along different dimensions. A monolith may be decomposed into its use cases, into the transactions it provides, or even into more atomic interactions between the front-end and back-end services. The type of decomposition performed is chosen based on the preferred client architecture, and it’s driven by the scalability and performance requirements of the future-state application.

When modernizing mainframe batch applications, performance of the future-state application is an important concern. The mainframe is a highly performance-optimized architecture, and legacy languages are usually very efficient. For example, in our experience, Java is 3-7 times slower than COBOL for typical IT applications. The data pipeline on the mainframe also can be up to 30 times faster than the data pipeline on a Linux-based client-server application. If substantial latencies are introduced in a cloud realization, performance degradation can be even more severe.

Nevertheless, it’s possible to achieve parity with the legacy application. We’ve optimized our modernization factory to produce high-performance results in the future-state language. Further performance improvements are identified by profiling the migrated application and locating the sources of any degradation. When database latencies are the source of slowdown, architectural changes and database tuning can win back the lost time. Where inefficient algorithms were used in the legacy application, the Updraft modernization factory applies custom transformations to automatically search for such algorithms and replace them with faster realizations. Most importantly, in many modernized applications, data parallelism can be used to spread the application over the many processing cores available in a typical future-state system. The Updraft modernization factory adjusts the transformed system to take advantage of the identified optimizations.

We offer legacy modernization based on a fixed-fee pricing model. For each Updraft solution, a base price is established using easily determinable characteristics of the legacy application (lines of code, number of artifacts, and so on). Each solution is customized to your needs and requirements. Most customization is part of the base price, but add-on services are available to further enhance your solution. The Updraft modernization factory delivers fully modernized application source code without any ongoing fees or royalties. A no-cost license is granted for any supplied run-time libraries. We offer a full 1-year warranty included in the price.

We are a technology-enabled services company. Whether we work directly with an end customer or through a system integrator, our approach is always the same. Updraft team members are there with you at every step of the process. In addition to being highly skilled with legacy/target languages and environments, our engineers are experts in adapting our modernization factory to your needs and running your legacy code through the factory. Updraft will deliver your modernized application ready for deployment. Clients or integration partners will then be responsible for testing and deploying the application.

The Updraft modernization factory can be configured so that the legacy source and supporting project files reside in your data center, Updraft’s data center, or in the cloud.