Can you picture it – you’re driving down the motorway when all of a sudden, you see one of your rear wheels overtaking you, bouncing down the road. If only you had kept up the annual service and kept on top of the maintenance to identify and replace wearing parts before they failed. Unfortunately, when things break, it isn’t the time to think about maintenance.
Integration is not much different. It often becomes some of the most critical pieces of technology within an organisation. Integration platforms connect core systems, enable APIs, and allow data to flow across the business. But once the platform is established and integrations are running smoothly, the focus naturally shifts toward delivering new capabilities and leveraging the awesome new platform you’ve worked so hard to implement.
However, integration platforms are still software products, and like any software they follow defined release cycles and support lifecycles and require maintenance. Over time, versions move through support phases and eventually reach end-of-life. When this happens, organisations can find themselves in a difficult position if upgrades haven’t been planned ahead of time.
I’ve seen it too many times – everything is running smoothly, the team is busy working on new features, and suddenly panic stations. A version update is required which will pull resources away from planned work to implement and regression test the update.
For platforms such as MuleSoft and Solace, staying within supported versions requires some level of planning. Without it, teams can quickly find themselves scrambling to upgrade environments just to remain within the vendor’s support window.
The Importance of Planning Platform Upgrades
One of the most common challenges organisations face with integration platforms is leaving upgrades too late.
When a platform is first deployed, the runtime version is typically current and fully supported. Over time, however, new projects are delivered, additional integrations are added, and attention shifts toward new capabilities rather than platform maintenance. Months or years later, the organisation may discover that the runtime version running across multiple environments is approaching the end of its support lifecycle.
At this point, the upgrade is no longer a simple platform activity. Instead, it becomes a large and often urgent piece of work. Every API, integration, and environment needs to be assessed and potentially upgraded within a limited timeframe.
The associated regression testing piece of this is also often underestimated. While vendors like MuleSoft do a significant amount of testing to ensure backwards compatibility, particularly across runtime versions, Java upgrades, and connectors, there is always an element of risk when upgrading an integration platform. Subtle changes in dependencies, connector behaviour, or JVM versions can surface issues that only appear in specific implementations. This means organisations still need to validate their own integrations thoroughly, especially where custom logic or complex transformations are involved.
Beyond the immediate disruption, there are also hidden costs that organisations often don’t account for. Planned work is paused or delayed while teams focus on upgrades. Skilled resources are diverted away from delivering value to the business. In some cases, organisations need to bring in external expertise or vendor support to accelerate the upgrade, adding further cost. What could have been a controlled, incremental activity quickly becomes an expensive and time-consuming exercise.
A far better approach is to treat runtime upgrades as a normal part of platform maintenance. When upgrades are planned ahead of time and aligned with the vendor’s release cadence, they can be introduced gradually and tested properly. This allows organisations to remain within supported versions without disrupting ongoing development work.
Understanding Product Release Cycles
Most enterprise platforms release new versions regularly to introduce new features, performance improvements, and security updates. To balance innovation with stability, many vendors offer different types of releases designed for different use cases.
MuleSoft, for example, provides two primary release streams for its runtime: Long Term Support (LTS) releases and Edge releases. Each serves a different purpose, and understanding the distinction is important when deciding how to run a production integration platform.
Edge releases provide access to the newest features as they become available. They are released more frequently and allow organisations to adopt improvements earlier. However, because these releases are intended to deliver new capabilities quickly, they typically have shorter support lifecycles and have a higher potential to introduce bugs. This means environments running Edge versions may need to be upgraded more frequently in order to stay within supported versions and are less suited to environments where stability is paramount.
For some organisations, this trade-off is acceptable. Teams that are actively building new capabilities, need early access to features, or have strong automated testing practices may benefit from adopting Edge releases.
Long-Term Support releases take a different approach. Rather than focusing on rapid feature delivery, LTS versions prioritise stability and longevity. These releases are typically published less frequently but come with significantly longer support windows. They include many of the features introduced in earlier Edge releases but package them into a version designed to remain stable for enterprise production environments.
For most organisations running an integration platform, particularly those supporting multiple business-critical systems, LTS releases are the better choice. They provide the most stable platform, a predictable release lifecycle, and reduce the operational overhead associated with frequent runtime upgrades. Unless there is a compelling requirement for features only available in the latest Edge release, it is highly recommended that organisations stick to LTS releases.
MuleSoft Release Cadence and Support Windows
MuleSoft provides a clearly defined release cadence for the Mule runtime, which helps organisations understand when new versions are introduced and how long they will remain supported.
Each runtime version by MuleSoft progresses through several support phases during its entire lifecycle, with the length of each stage dependent on the release stream. Initially, the version enters a period of standard support upon its release. During this phase, MuleSoft provides full product support along with updates that address bugs, security vulnerabilities, and stability improvements.
After the standard support period ends, the runtime transitions into extended support. During this time the version may still be supported, but the level of maintenance and updates becomes more limited. This support level is typically intended to give organisations additional time to plan and execute their upgrade strategy.
Eventually, the runtime reaches its end-of-life date. At this point the version is no longer supported by MuleSoft. Security updates and fixes are no longer provided, leaving organisations running these versions exposed to potential operational and security risks. This is clearly a situation that should be avoided.
For more information model, see the MuleSoft Support Policy.
The MuleSoft documentation provides detailed information about runtime versions, release dates, and support timelines. Reviewing this information periodically can help platform teams ensure they remain within supported windows and avoid last-minute upgrade efforts.
Current MuleSoft Release Cycle – as at April 2026 – (https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence)
As you can see, the LTS releases offer a much greater support window. For example, the 4.9 LTS Release has 18 months of Standard Support, followed by a further six months of Extended Support. By contrast, the 4.9 Edge Release is limited to nine months Standard Support, followed by three months of Extended Support.
Solace Release Lifecycle
Solace follows a similar release structure and lifecycle approach for its event broker platform. Similar to MuleSoft, Solace provides two streams of releases: Rolling Releases and Long-Term Support Releases.
Rolling Releases, similar to MuleSoft’s Edge releases, are intended for new feature introduction and occur every two weeks after the LTS release. Rolling releases are supported for two years but will not receive updates through Maintenance Releases.
Long-Term Support (LTS) Releases are production-ready releases available in June each year with maintenance releases every two weeks. LTS releases are supported for two years and will receive updates through Maintenance releases.
For organisations using Solace as part of an event-driven architecture, keeping track of these release timelines is just as important as managing API runtimes. The event broker is often responsible for handling large volumes of real-time messaging between systems, and running unsupported versions can introduce unnecessary operational risk.
Understanding the Solace release schedule and planning upgrades accordingly ensures that the platform remains stable, secure, and fully supported.
Current Solace Release Cycle – as at April 2026 – (https://solace.com/support/support-dates-for-release-versions/)
Treating Platform Upgrades as Routine Maintenance
The most effective way to manage runtime lifecycles is to treat upgrades as a routine operational activity rather than a major transformation project.
By aligning platform upgrades with vendor release cycles, organisations can maintain a healthy platform without disruptive large-scale upgrade programs. Selecting Long Term Support versions for production environments helps reduce the frequency of upgrades while still ensuring the platform remains current and supported.
As upgrades become a regular activity, it also becomes easier to justify investment in improving how they are delivered. One of the most effective ways to reduce the impact of upgrades is to invest in automated testing. This includes unit testing using tools such as MUnit, as well as functional and API-level testing using tools like Postman or similar platforms. At a broader level, application-level testing and regression suites can provide confidence that integrations continue to behave as expected after a runtime upgrade.
Over time, this investment pays off. Instead of upgrades being high-risk, manually intensive efforts, they become repeatable and predictable. Testing becomes faster, confidence increases, and the overall cost of maintaining the platform decreases.
Maintaining visibility of runtime versions and their support timelines is also important. In practice, this means more than just knowing what version is running in production. Platform teams should actively track vendor release notes, subscribe to update notifications, and regularly review published support timelines. Maintaining a simple register of runtime versions across environments, along with their support end dates, can provide a clear view of upcoming upgrade requirements. Some organisations also incorporate this into platform dashboards or governance processes to ensure it remains visible.
Ultimately, keeping integration platforms within supported versions is not just a technical concern. These platforms often underpin large parts of an organisation’s digital infrastructure. Ensuring they remain supported, secure, and stable is a fundamental part of maintaining a reliable integration capability.
