HID Converge Platform Modernization

5.1 Java 8 → Java 21

The backend runtime was upgraded from Java 8 to Java 21. This was a foundational modernization step intended to establish a current long-term-support (LTS) Java runtime and to reduce dependence on obsolete platform generations. Because the application is a mature enterprise system, the change required compatibility analysis across framework integrations and dependencies rather than a simple build-file version change.

5.2 Spring Framework 4 → Spring Framework 6

Spring was upgraded from Framework 4 to Framework 6. Spring is deeply involved in the application through dependency injection, MVC, security, REST APIs and application infrastructure, so the upgrade affected foundational application behavior. The migration therefore required compatibility review and coordinated changes across the backend rather than isolated edits to the framework declaration.

5.3 Enterprise Capabilities Preserved

• REST APIs and backend service contracts remained central to the platform integration model.
• Security, role-based access control (RBAC) and multi-tenant application management remained core platform capabilities.
• Persistence and transaction behavior continued to support the existing business workflows and database model.
• Workflow, reporting, auditing and scheduled processing remained part of the backend validation scope.

5.4 API Compatibility & 5.5 Deployment Artifacts

The deployment and plugin design explicitly considered API compatibility. The goal was to minimize unnecessary disruption to existing endpoints while modernizing the surrounding infrastructure. Keeping business API changes separate from infrastructure modernization reduced the risk that the technology migration would become a simultaneous business-contract rewrite.

The architecture retained backend WAR/JAR artifacts as deployable components while separating frontend packaging into UI.war. This separation avoided unnecessarily duplicating frontend content inside backend application bundles and allowed the deployment model to evolve without discarding the existing modular packaging approach.

6.1 AngularJS → Modern Angular (Incremental Hybrid Migration)

The frontend migration began with AngularJS 1.6.10 and moved to Angular 18, followed by Angular 19 and the current Angular 20.3.30 implementation. The migration was incremental rather than a single rewrite. A hybrid architecture allowed Angular and AngularJS functionality to coexist while application areas were progressively converted.

The work involved more than converting syntax. AngularJS controllers, directives, services, templates, routing and dependency injection patterns had to be mapped to modern Angular concepts. Application startup, authentication, shared services and routing also required coordinated migration because these concerns cross-cut individual UI components.

6.2 Current Frontend Stack

6.3 Migration Path & 6.4 Shared Infrastructure

The migration sequence created a controlled path from the legacy application to a maintainable modern Angular platform. The initial Angular 18 implementation provided the modern foundation; after stabilization, the framework was upgraded further to address additional SCA critical and high findings. The documented path is:

Routing and authentication were migrated alongside application modules rather than treated as isolated UI concerns. Shared services and component patterns were redesigned for Angular dependency injection, providing stronger typing and tighter compilation guarantees.

7.1 Kendo Grid → PrimeNG (nx-grid Abstraction)

One of the largest frontend migration challenges was removing the legacy Kendo-based grid. The Case Dashboard grid was configuration-driven and combined UI behavior with AngularJS-specific templates and expressions. A direct component replacement would not have preserved the complete behavior model.

The migration redesigned the rendering layer while preserving business behavior across:

PrimeNG was adopted through an application-level grid abstraction, including the nx-grid approach. This creates a stable application contract above the underlying third-party component and reduces direct coupling between feature code and the UI library implementation.

7.3 Kendo Chart → ngx-echarts / Apache ECharts

The charting layer was also modernized. Legacy Kendo chart functionality was replaced with ngx-echarts and Apache ECharts. The migration required updating chart configuration, rendering integration and Angular component usage while retaining the intended graphical representation of application data.

7.4 Plugin Architecture: From AngularJS Runtime to Modern Angular

The Converge platform supports extension mechanisms for additional applications and functionality, including NGS (Next-Generation Sequencing) applications. The legacy plugin model was tightly coupled to the older AngularJS runtime. Modern Angular uses Ahead-Of-Time (AOT) static compilation, so the old dynamic registration approach could not simply be carried forward.

The modern architecture introduces explicit plugin startup services, registration, plugin context, mount points, extension points and component resolution/registry mechanisms. This makes parent/plugin interaction a defined architectural contract and allows Angular-based NGS applications to integrate cleanly with the modernized parent application.

8.1 Deployment Direction: Pre-Installed vs Dynamic Downloading

The NGS App Store architecture favors pre-installed NGS applications with tenant-specific licensing rather than dynamically downloading and installing applications after user login. This model provides a more controlled deployment lifecycle while keeping activation behavior tied to licensing.

8.3 Startup Sequencing Pipeline

A significant design risk was installation occurring before dependent platform services were available. The expected sequence was represented and enforced as:

8.4 Proof of Concept & 8.5 Parent / Plugin Integration

A proof-of-concept approach was used to validate the proposed deployment architecture before full commitment. The POC covered deployment behavior, database script installation, plugin installation, dependency sequencing, backend API compatibility and interaction between Converge and NGS modules. This reduced the risk of implementing a deployment model that later required major rework.

The deployment design keeps frontend and backend concerns aligned without forcing them into a single artifact. The parent application provides the hosting environment and integration contracts, while NGS applications can be packaged and activated under the controlled App Store model.

10.1 Security Modernization

Security improvement was a primary driver of the program. Older frameworks and third-party dependencies contributed to findings from SCA and SAST. The chosen strategy was to address the underlying technology generations so that a significant portion of obsolete-dependency risk could be reduced while creating a platform that can continue to receive incremental security updates.

The Angular migration also established a path for progressive remediation: AngularJS → Angular 18 → Angular 19 → Angular 20, with future supported-version upgrades available as required. The objective is not to treat security as a one-time migration milestone, but to make continued dependency maintenance practical.

11.2 Lessons Learned

11.3 Future Evolution

The modernized foundation supports incremental Angular upgrades beyond Angular 20, continued dependency remediation, further removal of legacy frontend infrastructure, additional UI modernization, stronger plugin standardization and increased automation around compatibility and security validation.