THE CHALLENGE

A local government agency held the responsibility for its region’s water quality, water supply planning, ecosystem restoration, land management, and, most critically, flood control during natural disasters which it accomplished by raising and lowering levies based on water level data. 

In order to fulfill its wide mandate, the agency had developed over the years a complicated portfolio of fifty integrations across two networks, one dedicated to the collection and processing of in-field sensor data and the other to the running of the organization itself. The agency had built these integrations in Mule 3—but with MuleSoft’s announcement that standard support for Mule 3 would be terminated by March 2021, and the product moved to End-of-Life status by March 2024, the agency faced the need to migrate to Mule 4 swiftly, or to face the many risks that would come from losing support and security updates for its Mule 3 implementation. As the custodians of large amounts of sensitive government data, the agency could not assume risks like these. 

The shift from Mule 3 to Mule 4 was easier said than done, however. As a long-time “Java shop”, the agency’s IT team had developed numerous integrations in customized Java code invoked from the Java Component rather than by using MuleSoft’s less code-intensive components and connectors. What’s more, the existing code didn’t follow MuleSoft recommendations for Mule 3 applications—so when Big Compass’s initial migration support team ran Mule Migration Assistant (MMA), MuleSoft’s tool for automating the Mule 3 to Mule 4 transition, only 20% of the code was migrated successfully, and the tool inadvertently added significant amounts of junk code (i.e. extra code not used by the application) as it attempted to migrate the rest. To get back on track, it was clear a “back to the whiteboard” rethink would be required. 

THE SOLUTION

With an expanded team, Big Compass tackled the migration from a new direction, starting by dividing the agency’s application portfolio into two buckets: one containing the in-field sensor and control system applications (the SCADA system), and one containing the agency’s enterprise applications. Starting with the SCADA applications first, the team designed a single code template—covering functions like error handling and data initialization—that could be used to build each of the integrations in a consistent way.

In the course of this work, the Big Compass team discovered that some of the Java libraries used in the client’s Mule 3 implementation—many of which were to be pulled into Mule 4, following the project’s “migrate as-is” guideline—contained CVEs (Common Vulnerabilities and Exposures); the affected integrations were either replaced by Mule components or their Java code modified to use updated libraries.

With the SCADA applications migrated and in user acceptance testing, our team is now applying a similar process to the agency’s enterprise applications. At the current pace, all applications will have been migrated to the Mule 4 version this spring.

THE RESULTS

With a successful and on-time migration to Mule 4, the agency will benefit from ongoing technical support from the vendor, ensuring its integrations continue to operate reliably in an environment where downtime can have significant negative impacts. Likewise, the agency will continue to be protected through the frequent updating of the platform’s security features. 

With so much riding on its systems and on the sensitive data they store, these are wins not only for the agency, but for the government and all the residents and businesses in the region too.