Rebuilding a Java Legacy Application 

How we re-engineered the production workflow app of a major manufacturing company 

Company Summary  

Services

Web development  

Technologies

Angular 7, Java 11, Spring (Boot, Security, Data), Microsoft SQL Server, Kafka, Postgres (PostgreSQL)  

Project Locations

Egypt, France, Italy  

Size

$2-5 Billion

Customer Since

Industry

Manufacturing 

Our client runs a global manufacturing company with outlets in Europe, Asia, and South America. The company uses an application to track and monitor the steps in the manufacturing process from the material movement of raw materials to processing and assembly of the final product. Their app also tracks the boxing, palletizing, and shipping of their products.

This client approached us about revamping their application for a number of reasons. Primarily, it was built with a legacy Java technology, Java 1.6, by a previous vendor. The architecture was no longer sustainable since it lacked modern standards for technology and best practices.


Furthermore, the client needed the application to be rebuilt to operate efficiently both as a Java web application and for the handheld devices that scan barcodes found on the materials and containers involved in the manufacturing process.

2017

Since we were upgrading a legacy Java application responsible for the entire production lifecycle of a global manufacturing company, this project was a significant undertaking. This app tracked everything from raw materials to final shipping, and it was the primary workflow app. Comprised of over 200 wizards that individually contained multiple steps, our team was faced with a number of business and technical challenges throughout the project. 

The Challenge

A previous vendor built the in-house, legacy application using Java 1.6, and it wasn’t built according to RESTful standards nor was there consistent documentation. Not only was the business logic unclear in places, but since open source was not used in the legacy build, some of the files were in binary. Thus, our developers encountered a “black box” in places, and this required additional work to piece together the business logic behind the application. 

Lack of Consistent Standards

Primary users of the legacy application became accustomed to a particular user experience. Hence, when revamping the app, we had to re-engineer the legacy database and upgrade it to a modern data model that would provide a new but consistent user experience.


In other words, we needed to upgrade the database without disrupting the employee workflow. We didn’t want to introduce too many features in a short period of time that would require more training to learn. Therefore, adjusting the data model while preserving a familiar user experience was just one of the many challenges we had to overcome during this rebuild. 

Database Upgrade & Migration 

The client’s development team consisted of three back-end developers in Italy, and two front-end developers in France. The Italian team had competing assignments, so for several months, our team was working by ourselves on the backend. Coordinating across three geographical domains (United States, France, and Italy) on a legacy revamp created scheduling challenges from the start of the project. 

Scattered Development Team

Considering upgrading your technology? We can help  

Throughout our process to upgrade a legacy application to modern technologies, while preserving its original functionalities, we achieved a number of breakthroughs. Through trial and error, our team built a series of new workflows and implemented best practices to ensure the application met client expectations and offered employees a great user experience. While this project is still being worked on, and is slated for completion in 2021, our team is introducing a several new solutions to the legacy app. 

Our Solution

Updated Data Model

Since the original data model was inefficient, we needed to update the app to a new performance-based data model. However, remapping the database cannot happen all at once. A lack of documentation, and several “black holes” in the legacy app, required the developers to use trial and error to understand the application. Also, we took an iterative approach to upgrading the database since moving too quickly can create serious disruptions for users. 


The database currently uses Microsoft SQL Server, but we plan to migrate the system over to PostgreSQL, which is open-source and free. We’ll continue updating the system iteratively, feature by feature, until we have a new version with all of the features detached from the legacy app. 

Cross-Browser Compatibility

During our rebuild, we upgraded the system to run on modern technologies, like JavaScript, so that modern browsers would support the new application. This was an important benefit, since the legacy applications were limited by older and, in some cases, obsolete browsers. The new browser compatibility will enable more integration with HTML5 server-side and RESTful functionalities. 

One of the main reasons we needed to upgrade the app was to implement RESTful standards to enhance the app’s reliability, performance, and scalability.  


With RESTful standards in place, the system is stateless and separates the client and server as components that can be managed, updated, and reused without affecting the system as a whole. This led to a number of performance enhancements and efficiencies in the following areas: 

RESTful Standards

Find out more about working with Integrant. 

Faster Communication 

The original application leveraged a Java-based web framework called JSF (JavaServer Faces) that used the NetBeans IDE. With this architecture, each API was coupled with the user flow and required too many dependencies, and this increased latency and reduced application efficiency.


Under the RESTful framework, API requests are stateless, so data can be cached and retrieved as standalone requests. The new app’s modern architecture has led to better performance, as well as the ability to leverage more advanced functionalities included in recent versions of Java. 

Information Sharing 

Better Sustainability 

An information gap emerged during the process of upgrading the application. Our team learned that certain terminologies were used by the original third-party vendor, which were discovered to no longer be relevant in the upgrade. By working through these issues and definitions, our team developed a shared language around the features and functions they were addressing. 

Overall, the app’s modern architecture has increased the application’s productivity and made it easier to fix issues. By working with standard frameworks and design practices, we’ve created an environment with increased sustainability and efficiency. 

Performance Targets 

In the early stages of our legacy app upgrade, the team often found itself trying to perfect certain features. In the absence of performance targets, this caused the team to take more time than necessary to complete tasks. Thus, our team established targets to set limits on performance enhancement to avoid wasting development cycles. 

With a scattered development team, it can be challenging to align as well as ensure there are no missing links and the project can run smoothly without running into roadblocks due to things like dependencies. Utilizing Agile, our team was able to stay flexible throughout the project and tackle different aspects as needed. Daily stand-ups guaranteed the team was moving in the right direction together and avoided mishaps like the same engineer working on the same user story. 

Effective Communication and Agile  

We build enterprise software solutions. 

Outcome

The legacy manufacturing revamp project for our client’s Java web application kicked off in March 2019 and is slated to be completed in two years. 


Our team has overcome considerable challenges and hit some significant milestones over the past year. These have included:

  • Establishing a set of development best practices Are solution-oriented and resourceful
  • Upgrading workflows
  • Adoption of a new RESTful architecture
  • Data modeling and plan for migration to PostgreSQL 
  • Coordination between teams in France, Italy, and the United States   

Currently, we have developed about 15% of the 200 original wizards and are continuing to work efficiently to develop the remaining wizards. Our framework and foundation are well-established, and we’ve achieved significant breakthroughs over the past year. As we move into the second half of this project, we look forward to building on our successes and continuing to increase the everyday efficiency and productivity of our wonderful partner.  

Sign-up now for updates to this project or contact us to find out how we can help you with your Java legacy app rebuild!  

 Contact us today!  

Copyright © 2020. All rights reserved.