Recent developments in the VMware ecosystem illustrate how this plays out in practice: after Broadcom’s acquisition of VMware, support for the widely deployed vSphere 7 platform is being retired, with security patches and updates ending and customers pushed toward new bundles and licensing models on an accelerated timetable. You can see the same dynamics playing out in the SAP ecosystem. SAP has set an end-of-support date of 2027 for its legacy ECC ERP platform, yet Gartner estimates that at current migration rates nearly half of ECC customers—around 17,000 organizations—will still be on the legacy system by that time, with more than a third remaining even in 2030. Those numbers underscore how end-of-life timelines can effectively force customers’ hands unless they have planned for sunsetting risk in both their technology roadmaps and their contracts.
Core technology can be sunset in a variety of ways, including the cessation of upgrades by the developer, security patches no longer being provided or hardware incompatibility with new software versions. Bespoke software may also become end-of-life if the underlying operating system is no longer supported. Customers of many core operating systems, processing engines or compliance tools may have invested heavily in integrations, training and change management for a tool, only to discover that those sunk costs buy little leverage once a sunset notice arrives. When a major software solution reaches its end of life, businesses relying on it must navigate a complex landscape of contractual obligations, data migration, compliance concerns and operational continuity. Too often, organizations are taken by surprise by their software vendor, leaving them little time to find a new solution, and with no contractual protections that would have helped them transition smoothly.
Software sunsetting should be considered by both clients and vendors from the outset of the contractual relationship, with proactive and ongoing risk allocation, management and governance. This article examines how to anticipate and manage that risk through contract terms, governance mechanisms and practical exit strategies so that a vendor’s product roadmap does not become your business continuity crisis.
Pre-Contract Best Practices
Protection against an unexpected sunset event starts before you enter into the contract, as you should understand who you are partnering with, where their business is heading and how central your solution is to their long-term plans.
Start with market-level diligence. This includes understanding the maturity and life cycle of the relevant technology market, typical product lifespans, consolidation trends and whether the category is evolving toward replacement platforms or bundled offerings. A structured request for proposal (RFP) process can be particularly valuable at this stage, to compare features and pricing, as well as to surface differences in vendors’ long-term roadmaps, investment priorities, exit strategies and willingness to commit contractually to ongoing support. RFP questions should probe expected product longevity, historical sunset practices, dependency on third-party technologies and the availability of migration paths, rather than focusing solely on current functionality. This broader market view helps clients assess whether a solution is positioned as a long-term strategic platform or is more likely to be displaced or retired within the anticipated contract term.
It will also be key for clients to understand the internal dependencies on the solution, and how other systems, software, tools or integrations may be impacted by the sunsetting of the proposed solution. Conducting internal third-party risk assessments may already be a regulatory requirement depending on the client’s industry (e.g., financial services), but should be conducted in any event as a best practice.
Once down-selection of a particular vendor has occurred, perform a targeted assessment of the vendor’s ability to continue operating and investing in its offerings. Key inquiries include the vendor’s operating history, customer base, and any recent changes in ownership, strategy or senior leadership that may signal a shift in product focus. For public companies, earnings calls and filings can indicate which products are being positioned as growth platforms and which may be candidates for consolidation or de-emphasis. For private companies, it is reasonable to request high-level financial and operational information, such as funding status and runway where appropriate to gauge whether the vendor can realistically support a long-term engagement.
Reference checks provide an additional practical lens. Ask for references that use the product in a similar manner, at a similar scale and in the same industry. In speaking with those references, explore not only overall satisfaction but also the level and consistency of support, adherence to service level commitments, the cadence of product updates and whether the vendor appears to be investing in the solution at a meaningful level. Customers often have a clear sense of whether a product is treated as a strategic platform or as a legacy offering receiving minimal incremental attention.
At all stages in your relationship with the vendor, insist on transparency regarding the product roadmap. Escalate questions to senior product and business leadership (not merely the sales team) to walk through the roadmap for the specific solution under consideration. Questions should address where the product sits in the broader portfolio, anticipated enhancements over the next 10+ years, and any initiatives to re-platform, consolidate or replace the offering. Ask for written roadmap materials where available, and ensure that key assurances about ongoing support and investment are reflected, to the extent possible, in the contract rather than left as informal statements.
Taken together, diligence on the vendor’s stability, the product roadmap and the experience of existing customers may provide an early indicator of sunset risk. If these inquiries suggest that the product is peripheral to the vendor’s long-term strategy, that is a strong signal to reconsider the selection or, at minimum, to negotiate significantly stronger contractual protections.
Contractual Best Practices
Once a vendor is selected, the primary lever for managing sunset risk is the contract itself. In many cases, the vendor’s standard contract gives them broad rights to discontinue services, offers limited transition support, and says little about replacement options, interoperability or long-term access to data. While it may seem obvious that the best protection against software sunsetting would be to prohibit the vendor from doing so, this does not often happen in practice given the fast pace of technological developments and vendors requiring the freedom to run their businesses as they wish. It may also not be in the client’s favor—vendors’ legacy software may no longer be market competitive, and replacement software may also be required in order for the client to comply with changing regulatory requirements. Well-drafted contracts can allocate risk and responsibility across the life cycle of the solution. The following sections outline key contractual tools that can significantly reduce the operational and legal impact of a vendor’s decision to retire a critical system.
- Clearly Defined Sunset Clauses. Contracts should include well-defined end-of-life provisions that outline the vendor’s obligations during the decommissioning period, including notice periods, continued support, security updates and data migration assistance. Clients should require strong contractual sunset protections, such as:
- Vendor Commitment to Maintenance and Improvement: Vendors should be contractually obligated to maintain, update and improve the software for the term of the contract, or for a minimum period of time that is specified in the contract.
- Advance Notice: Vendors should provide sufficient advance notice before discontinuing a software solution, allowing clients ample time for transition planning. To the extent the contract does not already grant the client at-will termination rights, clients should be able to exit the contract if the solution is being sunset.
- Equivalent Replacement Solutions: If a vendor sunsets a software solution mid-contract, they should provide and implement a technically and functionally equivalent replacement solution at no additional charge to the client. The client should not be required to take up additional solutions or software to make the replacement solution work.
- Protection Against Rebranded Software: If a vendor rebrands or resells a substantially similar software product, clients should be entitled to receive the new product or service without additional fees under the existing contract.
- Continuous Maintenance and Support: Vendors must provide maintenance and support for any replacement software under the existing support fee structure, including any renewals.
- Extended Support Options. Transitioning business critical software solutions is not always a short and straightforward process. This can be due to a number of factors, ranging from gaps in technical expertise or shortages of human resources to third-party systems, connections and solutions that are dependent on the software solution that is being transitioned—or vice versa. While lengthy advance notice periods before the vendor can sunset a software solution are useful, an added layer of protection for the client is to ensure that the vendor offers extended support for the software solution is being transitioned. This is typically included in the contract in the form of a provision requiring the vendor to maintain and support not only the most current release of the software solution, but also a previous release (or two). Where the software solution is reaching the end of its life, the vendor should permit the client to remain on the software solution for a limited time to allow the client to maintain security patches or critical updates after formal discontinuation.
- Data Portability and Transition Assistance. Contracts should mandate data portability provisions that ensure clients can extract their data in a usable format to allow for transitioning to either the vendor’s replacement solution, a new provider’s solution or to an in-house solution. Typically, vendors will be required to provide transition services for a specified period of time to ensure a smooth migration to the replacement solution. The fees and scope of such services should be predetermined to avoid disputes down the line.
- Third-Party Escrow Arrangements. Software escrow agreements could be considered to provide access to source code or support tools if the software is discontinued. In a typical software escrow arrangement, the vendor deposits source code and related technical materials with an independent third party, which agrees to release those materials to the client only if specified “release events” occur (such as the vendor’s insolvency or where the vendor’s services fall below agreed service levels). This mechanism was designed to protect licensees of on-premise software who would otherwise have no recourse if the vendor ceased operations. However, traditional source code escrow is often less effective in a modern environment where most core systems are delivered as multitenant, vendor-hosted cloud services. Even if the source code is released, the client typically lacks the infrastructure, third-party licenses, deployment tooling and specialist staff required to stand up, secure and maintain a production-grade instance of the application. The operational reality is that escrowed source code, without the surrounding hosting environment, DevOps pipeline and vendor know-how, may have limited practical value. For many cloud solutions, it will be more meaningful to focus on business continuity through other contractual commitments.
- Compliance and Regulatory Considerations. Contracts should address regulatory compliance obligations, ensuring that clients can meet any applicable sector specific regulatory requirements even after software support ends. For example, banking and financial‑services regulations (such as the EU Digital Operational Resilience Act, or “DORA”—see our previous client alerts on DORA here, here, here and here) require institutions to maintain business continuity, disaster recovery and operational resilience so that critical functions (like core banking) remain available, with tested plans for system failures, migrations and vendor changes. Supervisors can criticize or penalize institutions that lack a viable plan if a critical vendor sunsets a system, especially where this threatens customer access, data integrity or compliance functions. As a result, vendors are often required to take on some of the risk of end-of-life-ing critical tools as a cost of doing business with financial institutions.
- Termination For Convenience. Clients should resist the notion that a broad vendor termination-for-convenience right is “market,” particularly for core services. Similar concerns arise with “termination-for-convenience–like” provisions, such as a vendor’s unfettered right to discontinue software without providing a replacement, or a right to decline renewals. A vendor that has chosen to commercialize and contractually commit to a solution should not expect a free option to withdraw from that commitment while the client continues to perform and rely on the service. Granting such a right shifts the business risk of the vendor’s product and portfolio decisions onto the client and undermines the core purpose of a multi-year agreement: operational stability and predictability. Where a vendor insists on some form of discretionary termination, it should be the exception, not the rule, and should be narrowly tailored—with long notice periods, robust transition obligations and possibly software escrow rights—to reflect that the vendor is unwinding a commitment it willingly made.
Post-Contractual Best Practices
Outside of the contract language, clients should also ensure that internal risk mitigation strategies are put in place to mitigate the risk of sunsetting. These may include the following:
- Open Lines of Communication. Clients should proactively monitor vendor roadmaps and maintain open dialogue with vendors to anticipate software life cycle changes and prepare for potential sunsetting. And, as Pillsbury’s Technology Transactions team always says, an ounce of vendor management is worth a pound of legal disputes—so avoid throwing the contract into a drawer to gather dust. Instead, monitor the vendor’s performance against service levels over time, hold them to their support commitments and take a strong stance when notice periods or time commitments are not honored. Periodic check-ins, perhaps annually or at contract renewal inflection points, are a great time to ensure the train is still on the right track.
- Backups and Data Migration. Prior to sunsetting, it is important to ensure that all essential data is properly backed up, transferred or archived in compliance with legal and operational requirements.
- Evaluating Alternative Solutions. Clients should explore alternative software well in advance of the sunset or termination date, ensuring that any new solutions are evaluated for compatibility, compliance and long-term viability.
- Legal Recourse and Contractual Enforcement. If a vendor fails to meet contractual obligations regarding software sunsetting, clients should be prepared to enforce their rights through negotiation, mediation or legal action if necessary.
Specific Considerations for On-Prem to Cloud Migrations
Additional challenges arise where the software solution is being transitioned from an on-premises hosted solution to a cloud-based platform. When a software solution provided by the vendor is hosted by a third party, the client rarely has a direct contractual relationship with the hosting provider. The following issues will need to be taken into consideration:
- Service Levels. Vendors often disclaim responsibility for e.g., platform uptime, shifting accountability to the hosting provider. This may leave the client without adequate contractual recourse in the event of service level failures by the vendor. Clients can mitigate this risk by requiring the vendor to remain fully responsible for service levels regardless of any failures by the underlying hosting provider, by requiring failover backups or temporary alternative hosting arrangements, and by aligning contractual SLAs with, at minimum, the commitments the hosting provider offers the vendor. The contract should provide meaningful remedies tied to measurable uptime and performance metrics, such as service credits or termination rights for the client.
- Higher Fees. Vendors are likely to require that any hosting costs are passed through to the client. This can be done either by building the costs into the vendor’s fees, or as an additional line item on the vendor’s invoices. Where the hosting provider increases the hosting costs, vendors will rarely be willing to absorb such costs—exposing the client to additional fee increases that may not have been anticipated. The vendor may shift to the financial structure of the deal to a “minimum commitment” model. This is often because cloud providers tend to incentivize long-term reserved instances or similar capacity commitments, and vendors may respond by imposing corresponding minimum spend or volume commitments on their customers. Likely, the commitment is binding even if the client’s actual usage declines or the business shifts. Clients can mitigate the risk of higher fees by requiring transparency into the basis for any minimum commitments, capping pass-through infrastructure charges and disallowing unilateral increases tied to the vendor’s hosting arrangements. Where some level of commitment is unavoidable, clients should negotiate rights to adjust or renegotiate commitments based on actual usage, or vendor failures, as well as meaningful termination and transition options if the underlying hosting model materially changes.
- Audit Rights. Under an on-premise license, clients may have negotiated broad rights to audit the vendor’s security controls, system configurations and even underlying logs within their own environment. In a multitenant cloud architecture, those same rights may no longer be feasible; the vendor may lack authority from its cloud provider to permit customer audits of the physical infrastructure, and extensive access or intrusive testing can raise security and confidentiality concerns for other tenants. As a result, clients may see their direct audit rights narrowed to document-based reviews, certifications (such as SOC reports) and limited technical testing in segregated environments. Contract terms should therefore focus on structured third-party assurance (e.g., independent audits and certifications), incident and vulnerability reporting, and the right to review and enforce remediation of material exceptions, rather than assuming that on-premise style audit rights will simply port over.
- Subcontracting Risk. Cloud-based delivery also tends to increase the number and importance of subcontractors involved in providing the service, including infrastructure providers, managed security services and specialized tooling. Each additional provider can introduce its own security, privacy and resilience risks, as well as potential jurisdictional issues where data is stored or processed across borders. Under frameworks such as the GDPR, the use of sub-processors of personal data triggers specific obligations, including transparency about their identity and location, appropriate data processing agreements, and mechanisms to ensure equivalent protections and onward transfer safeguards. Clients should therefore insist on a clear subcontractor and sub-processor regime in the contract, including a current list of critical providers, notice and objection rights for material changes, and confirmation that all subcontractors are bound by obligations at least as protective as those in the main contract.
- Hosting Providers’ Policies. Hosting providers will also often require their acceptable use policies or end-user license agreements to be flowed down by the vendor into its client contracts. These are often non-negotiable. In addition, cloud vendors often include strong suspension rights, which will be flowed down to the client in the hosted environment and create significant risk for business continuity. Clients should insist that the vendor clearly identifies all hosting provider policies that will apply, provides copies (or stable references) and commits to notifying the client of any material changes to the same. Clients should require the vendor to contractually buffer them from arbitrary or premature suspension by the hosting provider. The vendor should commit to obtain from the hosting provider reasonable notice and an opportunity to cure before any suspension affecting the client’s environment. The contract should state that, as between the parties, the vendor remains responsible for compliance with those policies in operating the service, and that any new or changed hosting provider terms may not materially degrade the service or impose additional obligations on the client without its consent. Where a policy change nonetheless has that effect, clients should negotiate a right to seek adjustments to the service, pricing or, if necessary, to terminate the affected services without penalty.
Conclusion
Software sunsetting is a predictable feature of modern technology life cycles. By incorporating comprehensive contractual safeguards and proactive post-contractual strategies, clients can mitigate risks, ensure compliance and facilitate smooth transitions. Legal teams play a crucial role in drafting robust agreements and guiding organizations through the complexities of software decommissioning. Staying ahead of the curve in contractual negotiations can make all the difference in ensuring business continuity and legal protection.