VMware SRM 8.7 EOL Oct 2025: How to Keep Support

What Does VMware Site Recovery Manager 8.7 End of Life Mean for Your Environment?

VMware Site Recovery Manager (SRM) 8.7 reached end of life (EOL) on October 11, 2025. For any organization still running this version, the vendor has stopped all active support, including bug fixes, security patches, and technical assistance. This is not a Long Term Support (LTS) release, so no extended support options are available from VMware.

The latest build in this line is 8.7.0.4, but no further updates will be issued. If you are still on SRM 8.7, you are now operating without vendor protection. This article explains what that means in practice, what risks you face, and what options you have to keep your disaster recovery environment stable.

What Still Works

Even after the EOL date, SRM 8.7 continues to function. Your existing protection groups, recovery plans, and replication configurations will still execute as designed. VMware has not disabled the software remotely. You can continue to perform planned migrations and disaster recovery failovers.

However, there is a critical caveat: VMware will not release any new code for compatibility with future vSphere releases, storage array changes, or operating system patches. If you plan to upgrade your vCenter Server or ESXi hosts beyond the versions that SRM 8.7 officially supports, you risk breaking the entire DR workflow.

What Stops: Patches, Security Fixes, and Support

When a product reaches EOL, the vendor stops:

• Security patches: Any newly discovered vulnerabilities in SRM 8.7 will never be fixed by VMware.
• Bug fixes: Known defects in the 8.7.0.4 codebase remain permanent.
• Technical support: VMware will not accept support requests for this version.
• Knowledge base updates: No new troubleshooting articles or hotfixes for SRM 8.7.

In a DR tool, these gaps are especially dangerous. If a critical bug prevents failover in an actual disaster, or a security hole allows an attacker to disable your replication, there is no vendor path to resolution.

Who Legitimately Stays on Version 8.7?

Some organizations deliberately remain on SRM 8.7 for valid operational reasons:

• Stable workloads: If your DR environment is static and all components (vSphere, storage, OS) are frozen at compatible versions, you may see no immediate need to upgrade.
• Locked application dependencies: Legacy applications that require specific vSphere or guest OS versions may force you to stay on the SRM version that supports that stack.
• Hardware constraints: Older certified servers or storage arrays that lack drivers or APIs for newer SRM releases can make an upgrade impractical.
• Budget cycles: Some teams simply run out of budget mid-compatibility window and defer the project.

While these reasons are understandable, they do not remove the risk. The decision to stay is a conscious acceptance of an unsupported state.

The Real Risks of Running Unsupported DR Software

After EOL, your SRM 8.7 deployment carries several concrete risks:

1. Zero-day vulnerabilities: New CVEs discovered after October 11, 2025, will remain unpatched. If an attacker compromises SRM, they could disable replication or inject false data into recovery plans.
2. Loss of integration: If you upgrade vCenter, ESXi, or your storage array, SRM 8.7 may cease to function correctly. The only test of this is a failure during an actual disaster.
3. Compliance gaps: Auditors and regulators often require vendors to support critical infrastructure software. Running EOL software can trigger findings and remediation demands.
4. No disaster recovery testing fails: If a test failover reveals a bug in SRM 8.7.0.4, you have no way to get a fix. You must either roll back or accept the defect.

How Third-Party Support Keeps SRM 8.7 Maintained

If an upgrade to a supported SRM version (such as 8.8 or later) is not feasible, third-party maintenance can extend the useful life of your SRM 8.7 deployment. Providers like 3rd Party Support fill the gap left by the vendor’s EOL:

• Security patches: We can develop custom patches for critical vulnerabilities, testing them against your exact environment.
• Bug fixes: If a defect emerges in SRM 8.7.0.4, our engineering team can create and backport a fix.
• Technical support: Direct access to engineers who understand SRM and your infrastructure stack.
• Compatibility assistance: Guidance on running SRM 8.7 with newer vSphere or storage versions, including workarounds when vendor APIs change.

This approach typically costs a fraction of what VMware charged for the last annual support renewal. More importantly, it keeps your disaster recovery tool verifiably functional and secure while you plan a longer-term migration.

Next Steps for Your SRM 8.7 Environment

If you are still running SRM 8.7, your first action should be to audit your current vSphere, storage, and guest OS versions against VMware’s compatibility matrix for SRM 8.8. Determine if an in-place upgrade is technically possible. If not, map out a migration plan that includes a supported third-party maintenance bridge.

Do not assume that because SRM 8.7 is still running today it will work during the next disaster. End of life is the point where vendor protection stops and your own risk management must take over. For organizations that need to stay on this version longer, third-party support is the most reliable way to maintain safety and operational continuity.

Learn more about third-party support for VMware SRM and how to keep your 8.7 deployment secure.