Multiple Migrations from RPG to Java in ERP Software

In the initial phase, the projects were handled by three developers. Today, the client employs a 15-person VM.PL team, which includes not only developers but also a project manager, a business consultant, and a customer success manager.

Throughout the process, we work directly with the client, who provides consulting services to their end customers. We have carried out RPG-to-Java 11 migration projects for companies involved in areas such as:

• supplying medical and food-grade gases,
• manufacturing industrial machinery,
• producing heat pumps and heating systems,
• manufacturing printing products,
• providing telecommunications solutions.

Migration from RPG to Java

The migration process begins with a deep understanding of the legacy ERP system, including the original library versions used by each client—all fully written in RPG. Each company using such an ERP has built custom modifications and functionalities tailored to its business needs. After analyzing the legacy code, we rebuilt a comprehensive client-specific framework based on Java 11, incorporating the client’s unique assumptions and requirements.

Our role is to create a fresh version of the ERP system that includes all essential modifications, re-implemented from scratch. Over time, our team has learned to interpret legacy RPG code and integrate custom client features, while also analyzing the behavior of the older system.

Beyond backend work, we use the JET (Java Emitter Template) tool to generate fields, values, descriptions, and charts essential for ERP system operations.

Despite RPG’s complexity—especially due to the nature of ERP systems—our team has no issue understanding and working with it.

“Many large-scale systems—like banking platforms or legacy ERPs—still run on RPG code. Yet fewer developers today can maintain it because so few are learning it. The fact that our teams understand how the code works and how its dependencies are structured gives us a significant technical advantage.” — Daniel Hodaniewicz, Backend Engineer

• ERP System Modification Conflicts
  When a newer version of the software is rolled out, the update is deployed individually for each client. This is because many of the modifications were originally developed for specific business needs, and may lead to functionality conflicts when the system is updated. That’s why we actively resolve these issues during each update cycle, ensuring continued system stability and feature compatibility.
• Performance Challenges
  At times, we encounter performance issues, which prompt us to seek Java-level optimizations. During code analysis, we often identify additional areas for improvement, which are then scheduled for the next global system update.
• Monolithic System Architecture
  These ERP systems are not built on a microservices architecture, but rather as large monolithic systems. This means that calling a single function might trigger 10 different methods across 10 unrelated modules. This complexity requires in-depth analysis and insights from domain experts who originally developed the ERP’s dependency structures.

The Migration Process Can Be Divided into the Following Stages:

1. ERP Consultant Meeting with the Client – Analysis and planning.
2. Development – Migration from RPG to Java.
3. Deployment and Testing.
4. System Maintenance – Minimum one year of ongoing support.

ERP System Version Upgrades

Some clients already use a newer ERP system version. In such cases, we take the base system and adapt it to the client’s specific needs. So, in addition to code migration, we also handle version upgrades. For example, if a client’s ERP system is running on version 4.1, we upgrade it to version 7.2. This is a beneficial solution that improves both system performance and security.

During the version upgrade process, we review all client-specific modifications previously implemented in the system to ensure they are properly reapplied in the new version.

Development of a Web and Mobile Application Tailored to the Client’s Needs

For a company specializing in the handling and transportation of liquid goods, we are building a new fuel card system in collaboration with the client’s internal team. The end client’s company operates on an internal ERP system that manages, among other things, vehicles, fuel stations, and car washes. The goal of the project is to unify four currently separate systems into a single platform that enables the deployment of fuel cards for drivers, allowing them to refuel seamlessly.

The team—comprising an ERP analyst, developers, and a product manager—conducts regular product workshops with the end client to gather detailed project requirements for the development of new functionalities.

The development process follows Agile methodology, with prototypes built incrementally. We gradually add new features, which the client tests, and then we refine and expand them based on feedback.