Progress Kemp LoadMaster support, licensing and lifecycle

What actually changed when Progress acquired Kemp

Less than people fear, and more than nothing. The product line is the same: LoadMaster appliances, virtual LoadMaster, and the LoadMaster OS. What changed is everything around it, which is why the searches for this are mostly people trying to find something that moved.

Licensing and support now run through Progress systems rather than Kemp's own, which is the practical difference most administrators meet first: the portal you used to log into is not the portal any more, and the support path is Progress's. The branding on documentation and datasheets follows the same pattern.

For a working LoadMaster none of that requires action. It matters at exactly two moments: when you need support, and when you need to renew or move a licence. Both are much easier if somebody established where your account now lives before the day you need it.

MELA reached end of life in November 2025

This is the item on this page with a date that has already passed, and it is a licensing change rather than a hardware one.

Metered Enterprise Licensing, the pooled model where capacity was drawn from a shared entitlement across multiple LoadMaster instances, went End of Sale on 3 January 2025 and End of Life on 30 November 2025. That is a deliberate exception to Kemp's usual five-year policy, so anyone who was licensed that way has already had to move to a different model.

If that describes you and the move was made in a hurry, it is worth checking what you actually landed on. Pooled licensing exists because instance-by-instance licensing is awkward when you run several, and a rushed migration off it tends to produce either more licence than you need or a set of instances licensed inconsistently.

LoadMaster for Bare Metal is no longer sold

LoadMaster for Bare Metal was the option to run the LoadMaster OS on your own x86 server rather than on a Kemp appliance or as a virtual machine. It went End of Sale on 3 January 2025.

Existing deployments stay supported to their End of Life date under the standard five-year policy, so this is a planning item rather than an emergency. What it does close off is growth: if you standardised on bare metal and expected to add more, that route is gone and the choice is now appliance, virtual or cloud.

Worth knowing alongside it: the VLM-500 and VLM-3000 virtual models also went End of Sale in January 2025, replaced by the VLM-1G and VLM-5G.

The five-year rule, and how to use it

Kemp publishes a standard support policy of five years from a product's End of Sale date. In that window you get bug fixes, maintenance releases, workarounds and patches for critical bugs, plus hardware spares and replacement units through the RMA process.

That makes the arithmetic straightforward once you know your model's End of Sale date: add five years and you have the date support stops. An LM-X40, End of Sale July 2023, is supported to roughly July 2028. An LM-X3, End of Sale February 2024, to roughly February 2029.

The table above gives the models we could verify directly. Kemp lists 47, going back to 2007, so check yours against their policy page rather than assuming absence from our table means anything. If your model is older than the ones listed, it is very likely already past support.

What a LoadMaster actually needs looking after

Four things, and they are the four that get missed because the appliance keeps working while they rot.

Certificates. A LoadMaster usually terminates TLS, which means it holds certificates that expire. An expired certificate on the load balancer takes the application down as effectively as an outage, and it is entirely predictable.

Firmware. Updates carry security fixes, and a load balancer sits at the perimeter of an application, so it is exposed by design. Progress publishes security advisories against LoadMaster; if nobody is reading them, nobody is patching against them.

High availability that has actually been tested. HA pairs fail over cleanly in theory and, in our experience, surprisingly often do not in practice, usually because a configuration change was made on one unit and never replicated. A failover you have not tested is a belief, not a control.

The licence. It expires, and when it does the consequences are immediate rather than gradual.

Staying on LoadMaster or moving to something else

The alternatives that come up are F5, HAProxy, NGINX and NetScaler, plus the native load balancers in Azure and AWS. We are a Progress Kemp partner, so weigh what follows accordingly, but the honest version is that the decision is rarely about the load balancer.

LoadMaster's position has always been capability that is close enough to F5 for most mid-market workloads at a considerably lower price, with a much shorter learning curve. If your requirement genuinely needs F5's depth, you will know, because something specific will be driving it.

HAProxy and NGINX are excellent and free at the point of use, and the cost lands somewhere else: in the engineering time to build, secure, monitor and maintain them, and in the person who understands the configuration becoming a dependency. That is a good trade for organisations with the platform skills, and a poor one for organisations without.

The move worth considering seriously is not to another appliance but away from the pattern: if the applications behind the LoadMaster are moving to Azure, a native load balancer or Application Gateway may cover it and remove a box entirely. That is a genuine option and it is the one an appliance vendor's partner is least likely to raise, which is precisely why it is here.