Migration from RPG to Java in ERP software

In 2021, we partnered with a technology leader in business software for medium-sized enterprises in industry and wholesale trade. The company provides custom ERP software which closely aligns with the process and application requirements of the engineering, retail, medical, and automotive target groups. The ERP software, developed by the client, is available in multiple languages, which means it can be used in different countries. 

ERP systems were implemented with end customers several years ago. By default, these systems are supported and developed by manufacturers for a period of two years. However, over time, companies scale and processes evolve, creating the need to tailor systems specifically to the business. For a while, customers hired their own developers, who understood RPG (AS/400) syntax or worked with different vendors. However, this all happened outside of documentation, so it only functioned on an ad hoc basis for business needs.  Although ERP systems have continued to operate, RPG is now an older technology, which makes it difficult to find developers for further development.  

Companies, therefore, face a choice: either they decide to go back to the ERP system vendor and build the system anew, which is extremely expensive, or they migrate their customized system to a newer technology. Companies mostly decide to do the latter, working with the client’s teams and VM.PL. 

In the initial phase, three programmers worked on the projects. Currently, the client employs a 15-person VM.PL team, which, in addition to programmers, includes a project manager, a business consultant, and a customer success manager.     

Throughout the process, we have worked directly with the client, directly consulting the end customers.  We have performed migration projects from RPG to Java 11 for companies involved in areas such as: 

• Supply of medical and food industry gases 
• Manufacturing of industrial machinery 
• Production of heat pumps and heating systems 
• Production of printing products 
• Telecommunications solutions 

Migration from RPG to Java  

In the typical migration process we begin by getting to know the old ERP system with the original versions of each client’s libraries, which are entirely written in RPG. Each company with such an ERP system has modifications and functionalities built for the needs of its business.  

Our task is to build a fresh version of the ERP system with all the necessary modifications to the newly implemented system. We have learned within the team how to interpret this code, implement customer modifications, and analyze the operations of the older program. 

Our team had no problem understanding the RPG system, which, nevertheless, is not easy due to the level of complexity of ERP systems. But now after analyzing the older code, we not only migrate legacy code but can create a new comprehensive client framework with its specifics based on Java 11. 

“A vast number of large systems, e.g., banking systems or other ERP platforms, are based on RPG code, and fewer and fewer programmers can handle it. It is no longer widely taught. We have a significant technological advantage because our teams understand how the code works and its dependencies.”  

Daniel Hodaniewicz, Backend Engineer 

In addition to backend activities, we use the Java Emitter Template (JET) tool to generate the fields, values, descriptions, and charts necessary to operate the ERP system. 

What challenges do we overcome? 

• ERP system modification conflicts 

When a newer version of the software is implemented, then we actually implement the version update separately for each customer. This is because sometimes modifications can cause some problems when they are created for the client’s specific needs, so with each update, we resolve functionality conflicts on an ongoing basis. 

• Performance issues  

Sometimes, performance issues arise, and then we look for new solutions, optimizing performance from within Java. As we analyze the code, we identify areas to be improved for the next global system update. 

• Monolithic system architecture 

ERP systems lack an architecture of individual microservices but are one large monolith, which means that, for example, sometimes calling one function suddenly calls up ten different methods from ten different areas. This requires analysis and inquiry from the experts who built this type of dependencies in the ERP system.
 

The migration process can be divided into stages: 

1. ERP consultant meeting with the client (analysis and planning) 

1. Development – migration from RPG to Java 

1. Implementation and testing 

1. System maintenance for a minimum of one year. 

Upgrading the ERP system version 

Some clients already have a newer version of the ERP system, and because we have the base client’s version, we can customize it Therefore, we also manage version changes in addition to migrating the code. If the client’s version of the ERP system is, for example, 4.1, we upgrade it to version 7.2. This advantageous solution increases efficiency and improves the system’s security.  During the version upgrade, we check what modifications have been implemented in the client’s system so that they are already incorporated into the new version.  

Building a customized web and mobile application 

We are building a new fuel card system with the client’s team for a liquid cargo handling and transportation company. The end client’s company operates on an in-house ERP system dealing with, among other things, vehicles, gas stations, car washes, etc. The project aims to unify the four systems that are currently dispersed and create a single platform to implement cards for drivers to use when refuelling. 

A team consisting of an ERP analyst, developers, and a product manager regularly conducts product workshops at the end customer’s site to gain detailed information on the design requirements needed to build new functionality. 

The development process follows an Agile approach, and we gradually build prototypes, adding functionality that the customer tests and then develop in greater detail.

We systematically make improvements to client systems that require transfer to newer technologies. We strengthen project cooperation through remote meetings and in person to build relationships on an ongoing basis, strengthen mutual trust, and discuss processes in depth. 

With a strong command of the English and German language, the VM.PL team communicates fluently with end customers, significantly improving the quality and pace of work, mutual understanding, and overall atmosphere.