Rationalizing and Natural/Adabas

by Jeff Shelby

I think we can all agree that Natural/Adabas are not exactly cutting edge technologies.
At this point you are probably thinking, “great, another person with no Natural/Adabas experience calling it an obsolete”.

Let me assure you that is not the case. I worked with the government during the 80’s when Adabas was all the rage and worked on a project to re-platform Natural/Adabas as recent as 2016. There are reasons to keep Natural/Adabas but the reasons to look for a more sustainable home for your business logic are getting stronger every day.

Jeff Shelby
by Jeff shelby

Is it time to modernize?

You are probably thinking, “why spend money to fix what isn’t broken?” The short answer is that your application is too mission critical to be allowed to break! You have to look at the operational risk, sustainability, and ongoing costs of the application that lead to potential failures. Operational risk here is the probability that the application will not be able to respond to the needs of the business in a timely enough manner to prevent opportunity loss or revenue decline. This could be anything from lost customers or regulatory fines. Sustainability is exactly what you think: can I continue to get the resources and vendor support to operate? Ongoing costs are the resources required to support and enhance your Natural/Adabas application.

An over simplification is:

While it is a simplification, it is a good place to start. Of course, you have to answer these questions for your individual situation. However for discussion purposes, let’s look at some general trends for Natural/Adabas.

  • It is no secret that Natural/Adabas resources are scarce and they are not making new ones to replace them. In my 2016 project, my biggest challenge was keeping key resources from re-retiring before we completed the project.
  • This leads to cost issues because the staff requires senior level compensation that adds to the overall operational costs. If you have to recruit new skilled resources, you can end up in a bidding war. Trust me I know.
  • This can lead to open developer positions or less qualified developers. This will slow down enhancements, increase issue response times and increase the probability of issues occurring.
  • Most Natural/Adabas applications have been in service for decades. That means generations of different programmers have maintained them with their own approaches and styles. When combined with the aggressive schedules most developers face, the enhancements lead to large complex applications that are hard to understand and difficult to enhance.
  • The longevity of your application also contributes to higher operational costs. Vendor costs rise over time. If you paid $250,000 in maintenance starting in 1990 with the average 5% increase each year, you are now paying over $900,000. Let’s hope you renegotiated along the way.
  • Software AG is not selling a lot of net new licenses. That means that they need to maximize revenue from you.

Can a modernization work for your environment?

Sounds pretty bleak. You have increasingly complex applications with increasing less experience to manage them and everything is getting more expensive! Don’t worry too much. Stay with me while we work through this. You are probably thinking, “modernizations are not free, they take forever, and they are very risky”. It is certainly true that converting your business logic and data from one technology to another is a complex project. These factors need to be added to the decision on whether to modernize or not.

Therefore, the equation looks more like:



There are certainly costs and risks with modernization projects. The duration can be an issue as well. It can take a long time to get to a new application (also a really good reason to plan ahead) and the benefits promised. Let’s cover some of the things that can affect modernization risk, cost, and duration.

  • If you have a complex application with a less than ideal understanding of its specifications, how is anyone going to be able to recreate it in a new technology without a very long requirements redefinition?
  • If you could recreate the technology, it would take forever and then take even longer to test it.
  • We have already mentioned that Natural/Adabas skills are in short supply. There is no way you could spare them from operations for modernization tasks.
  • After you invest in a modernization, how do you even know if the end product will be useable?
  • If you invest in a modernization, you need results quickly not in 3 or 4 years or longer.

The Blu Age-PKS answer

The question is can you manage these concerns so that benefits overcome the risks. This gets you to a modern, affordable, and sustainable application that eliminates your current operational risks. Blu Age and PKS have teamed up to address these concerns to make Natural/Adabas modernization low risk, affordable and of reasonable duration so you can justify focusing your resources on working towards the future digital world and not keeping the past going.

Blu Age’s automated modernization of l Natural/Adabas to JAVA architectures uses your existing Natural Code and Adabas definitions as the basis for the new application. This allows you to retain your existing business logic with its years of investment. There is no long requirements definition and no chance to introduce errors in your valuable business logic. This automation speeds up the process of generating the new Java application and uses a continuous build and deploy process that includes automated testing. This allows testing to repeatable and limits the need for manual tests. The result is a very efficient testing approach that speeds up the verification process significantly.

Overcoming lack of skills

That leads to one of the other main issues around Natural/Adabas, the lack of skills. Can you do a modernization project with minimal impact to your existing Natural/Adabas staff? Through the use of automation and relying on the existing code base as the specification for the new system limits the demands on your existing staff for the transformation. So what about testing? It is the most important part of any project. Testing will require some resources, but the Blu Age approach limits those resources in two very key ways. First is automation again. The second is the establishment of quality gates that the code must pass before it is ever sent to you for testing. These quality gates are built around independent quality metrics and functional equivalence verification. This means that only high quality verified code is presented to you for testing. You are not spending your time debugging the transformation process or testing code that will not be deployable due to poor quality.

Timely results from a modernization are crucial. They both validate the process will produce acceptable results and start providing payback to the business. This is a difficult objective that Blu Age and PKS have solved. The Blu Age and PKS process uses an incremental process where logical subsets of the application that can be modernized, tested, and delivered independently are identified. This provides early access to the modernized code for verification, knowledge transfer, and production planning. It also ensures that transformation and testing can be done concurrently to minimize the duration of the project.

Phased deployment

While that sounds good, you are probably thinking, “it still does not replace any of the Natural/Adabas in production”. Blu Age and PKS understand this. One of the key benefits from a Natural/Adabas modernizations is the manageability of a fully relational database. This is why the first step is to convert Adabas to a relational database. Blu Age uses SmartDCI from PKS to allow your existing Natural applications to access a Db2 or Oracle database without any changes. As each application subset is transformed, it is verified against the relational database. Once verified, you replace the production Natural with the modernized Java. This continues until the complete application is taken into production. This process reduces the risk of failure associated with a typical “big bang” implementation and gives you financial payback early on.

Containing costs

That brings us to the topic of costs. There are three things to consider here. First is the current and forecasted ongoing costs of your existing Natural/Adabas. If you have not already done so, you should take a serious look at these costs including the costs of contingency plans if you lose resources. Additionally, you should investigate if the existing UX is costing you potential business. The second is the cost of the modernization. While that is specific to your environment, it can be controlled through the use of automation, quality gates, and efficient project coordination as we discussed above. You should work with solution providers like Blu Age and PKS to understand a ROM cost of modernization. The third is return on investment. How soon can you start to see payback on your investment?


Natural/Adabas applications have serious issues around resources, general sustainability and costs. These are very unlikely to improve and will certainly become increasing problematic. The obvious answer is to start modernizing these applications but that too poses issues around risk, cost and project duration. To make the best decision on the future of your Natural Adabas, you must weigh these against each other.

Blu Age and PKS have partnered on a solution that lowers the risk, cost and duration of modernization projects making it an increasingly attractive option. This solution’s automated modernization of legacy Natural/Adabas to JAVA architectures allows businesses to retain their years of investment in these applications. It requires no runtimes, and helps you to quickly migrate to a relational database while incrementally modernizing the related business applications proving quicker payback, enabling digital transformation, cloud migration, and lowered operating cost. Blu Age and PKS realize that the quality and maintainability of the new Java application is of paramount importance. This is not left to chance. During the modernization process independent metrics will be used to assess the reliability, maintainability, and security of the new code. Additionally, the application will be tested for completeness and full functional equivalence.

The Blu age and PKS solution is the best value based on the investment and final Java environment. It gets you off of Adabas at the start of the project and provides the most efficient, highest quality modernization project. This gets you to commodity skills faster than any other approach with the least risk. You will also have a modern object-oriented Java development environment that will have lower operational costs and be sustainable for many years to come.

More information

The information in this blog will be discussed in more detail during the upcoming webinar, “Safely Modernize Your Natural/Adabas to Java Using an Automated Incremental Approach.” The webinar is scheduled for October 31st at 11:00 am Eastern.

To learn more, sign up for the webinar or feel free to reach out at contact@bluage.com.

Back to news