As others have said, not all the HEART areas apply to every scenario. I've often found some subtle overlap and have at times chosen to leave one out as it gives less value than others.
That said, as Michael points out, you could look at retention at a high level, contract renewal, but conversely, you could look at a lower level, perhaps by feature.
You could investigate whether users find workarounds for holes in the system, or look for alternatives to perform a subset of features in a way that feels more optimal to them. You could interpret this kind of information in many ways, it could be something that is fed back as feature requests or workflow optimisation within the existing solution. It could be that splinter groups within the org resist using the solution and insist on non digital equivalents etc. It could be that through discussion, whilst using the product, users secretly pine for a competing product they prefer?
If none of this is true, you could still address retention, but treat it more like a goal of the other HEART areas, e.g. Is happiness high enough within the userbase that during the next contract renewal the solution will be extended, or have issues be uncovered which mean competitors would be evaluated.
Depending on your relationship with the incumbent provider, you could use this information to feed into their product roadmap, or cite problems that may result in non-renewal.