A few years ago, Software AG announced its intention to support Adabas & Natural through the year 2050. Although that might offer some degree of comfort to organizations running their systems on this older technology, it provides little benefit with respect to actually modernizing those systems. In order to reap the benefits of cloud connectivity and scalability and to take advantage of the cloud native services provided by hyper scalers like Google, Microsoft, and AWS, companies running older mainframe technology with Adabas & Natural are faced with the daunting task of moving to RDBMS databases and object-oriented languages that can better support agile development and modern integration standards.
Fortunately, that job has gotten easier, faster, and far less risky than it has ever been in the past. Automated code conversion and database migration makes it possible to map database schemas and legacy code to modern languages and RDBMS platforms with tools that automatically accommodate schema changes within the code; then allow for iterative testing of that mapping with virtually no marginal effort. The result is a highly stable, predictable process that enables an organization to make a clean “big bang” cutover to their migrated system in the cloud while maintaining complete confidence in the stability, performance, and functional equivalence of that system running on its new platform.
Organizations running Adabas & Natural are all too familiar with the high costs associated with these technologies. Maintenance and runtime fees are already high, – and if past history is any indication, those costs will continue to increase in the coming years. It is also becoming more difficult than ever to hire and retain developers and database administrators who have the necessary skills to maintain system built with Adabas & Natural.
The latest generation of computer science graduates seems to have very little interest in mainframe technology, –preferring instead to work with OO languages and the highly interconnected systems that have gained momentum with the emergence of cloud technology. Adabas & Natural, in contrast, fall short when it comes to extensibility and interoperability with other applications.
Software AG has never provided a simple path for transitioning from the mainframe version of Natural to its Linux, Unix, and Windows versions, further motivating technology leaders at many companies to migrate their systems away from Adabas & Natural altogether.
Converting legacy applications and databases presents some formidable challenges, due in large part to the fundamental differences in design principles between modern technologies and legacy mainframe systems. Although the use of relational databases and object-oriented programming are standard practices today, this was not the casein the early 1970’s when Adabas & Natural were initially released.
As companies look to modernize their legacy systems, they have an opportunity to reconsider some of the anachronisms associated with older databases and make changes that will rationalize data base schemas for better manageability and conformance to modern design principles. Where a non-relational database might allow for a fixed quantity of phone numbers to be associated with a customer record, for example, a re-design could move the customer phone number to a child table, allowing an application to store and retrieve an unlimited number of phone number records for each customer.
In a traditional legacy migration scenario, that would require changes to the target database schema, as well as code changes in all of the applications that read or write to any of the phone number fields in the customer master table. During the migration process itself, such a change would require that phone number data be mapped from the old schema to the new relational table structure.
Without some means of managing those kinds of design changes and automatically accommodating them elsewhere throughout the system, the prospect of making such modifications would require a great deal of effort, and would introduce considerable risk. For this reason, legacy modernization projects have frequently focused on a “least change” approach which sacrifices flexibility in exchange for system stability and lower risk. As we will discuss a bit later, an automated approach solves this problem it makes it possible to have both flexibility and low risk in your mainframe-to-cloud migration.
There are some specific challenges that we see with the Natural programming language as well. For example, Natural data items have an associated type (e.g. alphanumeric, date, logical, …), but can also be redefined and handle as if they were a different data type. This makes it possible to store “illegal” values in Natural & Adabas systems. This problem must be addressed as part of the automated migration process.
Many of the mechanisms present in Natural do not exist in modern programming languages such as C#. It is common practice in Natural, for example, to use copy codes as a means of re-using code across multiple programs, whereas C# has no concept of an “include file”. Natural’s control-flow instructions such as REINPUT peak likewise, and RETRY, simply don’t have a counterpart in C#.
There are other examples, such as Natural’s control-flow instructions, which may incur overhead if used in a modern programming environment; or the differences in Natural’s stopped handling of high-precision arithmetic operations.
The Astadia Migration Factory addresses these challenges holistically using four integrated components. CodeTurn automates the conversion of legacy code into modern programming languages with automation levels of approximately 99.99%. DataTurn automates the migration of data from legacy databases to virtually any modern relational database, allowing for adjustments to the schema in the process.
TestMatch is a test automation tool that uses tracing capabilities within source mainframe platforms to record user activity in the live production system, then replicates that user activity in the target system. Finally, DataMatch performs a comparison of source and target databases, – automatically adjusting for any modifications that might have been made to the database schema as part of the migration process.
These four components of the Migration Factory operating in harmony so that refactoring and testing are automated and synchronized. Taken as a whole, the Migration Factory allows for virtually unlimited iterative testing, so that all stakeholders can be confident in the stability, performance, and functional equivalence of the newly migrated system before it goes live.
The result is approach to mainframe-to-cloud migration in which risk and effort are dramatically reduced, and which allows for maximum design flexibility.
You might also like:
Using powerful conversion and testing tools, complex migration processes can be almost entirely automated, which results in minimal turnaround time for workflows, no errors or delays, and reduced project costs. Here's how.
Here are some of the most common mistakes in legacy transformation projects and how to avoid them when designing your modernization strategy.
As technology advances, mainframe organizations are increasingly pressed to transition to more modern platforms. Here are some of the most common misconceptions that hinder their mainframe modernization journey.
The cost of not modernizing mainframe systems is generally far greater than the time, effort, and money required to make the transition. Here's why.
As mainframes host mission-critical applications, it's essential to ensure that the modernization process is accurate and causes minimal disruption to business operations. This is where automated migration and testing tools come in.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now