Mule 3 to Mule 4: The Upgrade Expedition

In the technical metaverse, there is an abundance of technologies that an organization uses. Almost all of them use a multitude of these technologies. Over the period, some of these need to be updated. Either a newer version comes out, or someone comes up with another tool/technology which can compete and win against the existing one. So, to maintain the currency of the stack, have a technical edge over the business competitors and reduce the time to market products, the organizations need to move on to the latest technologies. This movement is what we coin as “Migration”.  Migration is not just a taboo but a need of the hour for many organizations that need to mobilize their technical infrastructure to gain higher returns on investment. Let’s look at the million-dollar question. What triggers a migration? One of the most common reasons any organization takes up migration is to increase business agility. Access to the latest technical assets is imperative for keeping pace with the competitors. The longer an organization takes to migrate, the more it loses out on the market shares. This is one of the significant reasons we see a lot of migration towards Cloud Resources. Migrating to newer tech also comes with the added feature of adding the latest security features, which help keep cyberattacks to a minimum. Some other triggers for migration triggers are usage of Open Standards, Implementation of new cloud strategies, moving from monolithic to micro service architectures and requirements of removing technical debts. All the mentioned are either singularly or collectively forcing a lot of organizations towards their respective migration journeys. One other pressing migration stimulator is the End-Of-Life concerns of the hardware and software. In contrast, an organization strives hard to provide services to its customers. If the supporting IT infrastructure goes out of support, that poses a risk to the business continuity. Migration also has a positive side effect, which helps the organizations Enable Digital Transformation, the town’s buzzword. Also, migrating from legacy tech to cloud-based solutions helps increase productivity agility and unlock new avenues of revenue generation. Whatever the reason for the migration, it will eventually and almost certainly remove the technical debts in the organization. Organizations using MuleSoft as their integration tool face similar challenges. The users must plan the migration with the MuleSoft version 3.9 coming to end-of-life in March 2024.

Source: mule-runtime-end-of-life

The Mule 3.9 version has already devolved in its extended support, which will end in the next few months. While migrating from MuleSoft to any other technology may take longer, migration from Mule3 to Mule4 is a relatively more straightforward task. Maintaining the currency and being on top of the game requires less effort than moving to a microservice or native cloud solution. Moreover, why to move? Mule provides complete MuleSoft-managed runtime planes such as CloudHub 1.0 and CloudHub2.0. Both variants have different flavours of cloud features as per the customers’ liking. Before we move on to the decision of How To there is a very big decision that needs to be taken by the stake holders. And that is the Approach. When you say approach, it basically boils down to two approaches,

1. AS IS Architecture
2. Re-Architecture

AS-IS architecture basically is taking the existing code as is and converting it to Mule4 code and deploying it on the latest version of the Mule Runtime. This is a faster approach with minimal changes. Rather to speak more appropriately, change wherever it is inevitable. This makes the migration journey faster and the business get a AS-IS solution of the existing MuleSoft implementation on the latest version. A more pragmatic approach is doing the re-architecture. This no-doubt is a longer approach and costs more. However, the underlying benefits of this approach are many folds greater than that of the lift ad shift approach. The biggest and far-reaching benefit of this approach is that you can eliminate all the technical debts that creep in due to an outdated version of any application. This also enables you to take advantage of all the latest benefits of the newer version as well. This also ensures that older risks are mitigated, and the final solution is up to the latest technical standards and not the outdated ones. The drawback of this approach is that it takes longer to achieve. It also involves more effort to re-architect/design and also convince the stakeholders and business to fund the same. Mule4 has introduced a myriad of developments over Mule3, which include (not limited to)

• Easier and faster development
• Seamless access and data mapping
• Simplified connectivity
• Auto-tuned and highly performant
• Seamless upgrades of runtime and connector versions

MuleSoft also provides a community tool, Mule Migration Assistant, aka MMA (Mule Migration Assistant), to help migrate from Mule3 to Mule4. Let it be spoken out loud enough to erase any doubts. This tool does not migrate 100% of the code. However, it reduces the efforts by almost 30-40% of the total effort needed to migrate the APIs. The amount of migration capacity also depends upon the complexity of the API. The less complex APIs get migrated readily using this tool compared to the more complex ones. The MMA will convert the flows and their inner logic, the global elements, and configurations. It will also transform the DWL1.0 scripts to DWL2.0 scripts, Munit Tests, connectors, transports, and modules. Factoring the amount of human intervention required, the investment required to migrate from Mule3 to Mule4 is still considerably lower than migrating to another platform. Mule4 also allows you to utilize the plethora of services and features that come with Mule4. Some key considerations must be accounted for while migrating from Mule3 to Mule4.

• Is there a requirement for any RAML refactoring?
• Does the project have any custom implementations for parsing, file handling, cryptography etc?
• Is there a specific naming convention requirement?
• Do you have any logging and error handling standards or custom implementation?

Post the considerations mentioned earlier, certain fine-grained aspects also need to be looked at before jumping the gun (not an exhaustive list).

• Refactor of Transformers, which have no support in Mule4.
• Replacing complex MEL with DataWeave2.x as MEL is not supported in Mule4.
• DWL1.0 to DWL2.0, where the syntaxes are different.
• Object Stores, which use a new connector in Mule4.
• Message Structure has also changed dramatically, wherein session, outbound, inbound and invocation properties are not supported.
• The Scheduler component in Mule4 replaces the Polling component.
• Mule4 uses the spring module as compared to calling the Spring Beans in Mule3
• Splitters are no longer supported in Mule4. Also, the aggregators have a different behaviour.
• Mule4 comes with a new validation module which replaces the filters in Mule3.
• The migration plan should also take into consideration any technical debt that is there and remediate the same.

One of the Aspects that an organization should need to consider is the “Migration Bubble”. Generally, a migration bubble is spoken of during an On-Premises to Cloud Migration, however the essence is the same here where in your investment to move applications and the infrastructure (if using Mule3 on-prem) could be significantly high compared to the initial estimates. While planning for the migration the team needs to factor in the money and time for the following

1. Meticulous planning and assessments of the migration.
2. Need for duplicate environments (Mule4 env and Mule3 env) for a certain duration.
3. Upskilling existing technical resources.
4. Backfilling or recruiting any technical resource shortage.
5. Clearly understanding any licensing requirements and its associated penalties if any.

The initial cost of the Bubble might seem comparatively high; however, truth be told, there will be savings soon enough. Ensuring to collaborate with the right strategic partners during the migration process will help the organization keep the Migration Bubble very limited. The Other Key Aspect that also needs to be considered is the Migration Approach. There are two ways this can be done.

1. Big Bang Approach – Migrate all the applications at once.
2. Iterative Approach – Application(s) are migrated in smaller groups.

If the portfolio has a massive number of applications, in such cases, it is always a safer bet to take the Iterative approach as compared to the Big Bang approach. This would also account for the varying levels of the business criticality of each application group that is getting migrated and any dynamic functional changes if required. As a suggested approach for the Iterative model, it is better to first consider migrating any shared libraries that are there. That can be followed by the migration of the APIs based on their business criticality and usage/consumption. Another approach in the iterative model could also be clubbing a set of chained APIs (Experience, Process and System) delivering a specific Business Goal in batches and, along with that, if there are any libraries, migrate them as well.  Planning is the Key to any successful migration. Also, be prepared to face the worst while preparing for the best.   Once the Migration is done, the Cutover needs to be planned immaculately to ensure it is seamless for the consumers of the APIs. This again can be achieved in two ways:

1. Big Bang Cutover
2. Phased Cutover or Canary Deployment Method.

Finally, on a closing note, it is important to reiterate that any migration is not a simple process. And the same holds good for the Mule3 to Mule4 migration. There is no sure-shot shortcut to achieve this, and there would be certain aspects of the migration which would be gruelling. However, this would be less when you compared to migrating from mule3 to a spring boot microservice. If you think that your organization needs help in this migration, feel free to reach out to us, and we can discuss the different ways Prowess Software can help you.