The two last 3.x versions of MuleSoft’s runtime engine, Mule 3.8 and Mule 3.9, have reached End of Support (EoS), whereas the extended support for Mule 3.8 is fast approaching (November 2021). With that, many users are increasingly concerned as to what that means for their applications and what are their options. We talked to Sreekanth Cherukuri, VP & Global Head of PreSales (MuleSoft) at Coforge, to help shed some light.
What does it mean that a Mule version has reached end of extended support?
According to MuleSoft, products that are not covered by Standard Support or Extended Support are considered End of Life (EoL). After the EoL support period expires, MuleSoft will not provide support of any kind which will be the case for Mule 3.8 from November onwards.
What problems might users face if they continue running apps on an EoL version?
What EoL really means, depends on the deployment model (CloudHub, Runtime Fabric etc), and MuleSoft has a detailed article on it. In summary however, these are the main areas that will be affected once a Mule version reaches End of Extended Support / End of Life:
No longer able to restart apps
There are many reasons why you’d need to restart your apps. You might need to deploy an updated version, or apply a patch. It might also be enforced because of a power cut or if the data centre is down. If you runtime engine has reached EoL you will not be able to restart your apps.
No longer able to deploy new apps
If your Mule version has reached EoL, you will not be able to deploy new apps, but you will still be able to modify existing (as long as the modifications do not require to restart the app).
What would you recommend to customers that their Mule version has reached or is reaching EoL?
In 2018 MuleSoft introduced Mule 4, the latest version for Anypoint Platform’s runtime engine, with many new features and components (but equally many retired ones). Compared to Mule 3, Mule 4 simplifies the expression language and reduces management complexity so that you can speed up the on-ramping process and deliver applications faster.
Having worked with many customers already that implemented Mule 4 as their new integration platform, or migrated to it from a previous version, we have seen first-handed the many improvements and optimisations that come with Mule 4. I would therefore strongly recommend existing Mule 3 users to migrate to Mule 4. Specifically for Mule 3.8 and Mule 3.9 users, the recommended version to migrate to is Mule 4.3.
On top of the improvements that are inherent to the new version, migration to Mule 4 will ensure app continuity, eliminate risk, allow new app development and ensure MuleSoft support.
What does it mean in terms of effort and cost to migrate to Mule 4?
There is no clear-cut answer to it. Time, effort and cost will largely depend on the components. In our ’10 things to consider when thinking to migrate to Mule 4’ paper and webinar we go over the most common components in detail.
For businesses that are looking to engage a partner to help them with the migration, our Mule 4 Migration Accelerator has been approved by MuleSoft and can automate the migration process by up to 90%. Perhaps more importantly, we are able to provide a fixed price from the beginning, so there is absolute transparency, significant time and quality efficiencies, and no hidden costs.
Are there any risks during or after the migration?
To avoid discrepancies, we recommend continuing to run the applications on the current version and in parallel, replicate and run these applications on Mule 4 in a lower environment. Once ready, switch from Mule 3 to Mule 4.
A common issue that comes up is with discontinued connectors or connectors that have not been upgraded to Mule 4. If a company has such connectors, I would suggest to try and contact the partner that developed that connector to see if they are planning to upgrade it. The alternative is to build a new connector from scratch which is not an easy fit.