What a vendor still owes customers between an EOL announcement and end of support

Does an EOL announcement change what you owe?#

An end-of-life announcement does not by itself change what a software vendor owes; the customer contracts do. Each customer's master agreement, order form, support policy and data processing addendum set out the service levels, notice periods, renewal terms and termination rights that apply until those contracts end or are validly changed.

Some contracts give the vendor a right to discontinue a product on notice, or tie support to a published lifecycle policy that the vendor may update. Others promise support for a fixed term with no exit. The first task for the general counsel is to sort customers by the paper they actually signed, including older templates that long-standing customers never replaced.

Public statements matter too. Lifecycle pages, release notes and sales promises about support horizons can shape customer expectations and, depending on wording and law, legal exposure.

The obligations checklist#

The obligations checklist below covers the commitments vendors most often carry through the sunset window. For each one, find the source document, confirm what it requires and decide which record will prove you met it.

Security fixes during the sunset window#

Security fixes during the sunset window are the obligation customers care about most and vendors most often underestimate. Even where a contract promises only commercially reasonable support, a known vulnerability in an announced-but-supported product draws scrutiny, and regulations in some sectors may expect customers to run supported software.

Plan for three things: keep a working build pipeline for every supported version, keep engineers who understand the old code available until the final date, and watch third-party components, because a vulnerability in an embedded library can force a release in a product nobody is actively developing.

Decide in advance how you will handle a critical issue that arrives a short time before end of support. A written severity policy, published with the announcement, avoids improvising under pressure.

Data export and deletion: show your work#

Data export and deletion are where a sunset becomes visible to every customer, so vendors that publish a clear route get fewer disputes. Large vendors' announcements show the pattern. When Atlassian scheduled removal of the Bitbucket Cloud issue tracker and wiki for August 20, 2026, it gave customers two routes for issues, a zip export or a move into Jira, and pointed them to cloning each wiki's separate repository. Autodesk first switched BIM 360 Team and A360 Team files to read-only, offering a copy route into Autodesk Docs or a local download, and retired both products completely at the end of 2023.

After termination, deletion duties take over. The Atlassian Customer Agreement, for example, provides that following expiration or termination, unless prohibited by law, Atlassian will delete customer data in accordance with its documentation. Check what your own agreement and DPA promise, including backup exceptions, and keep proof of each step.

Escrow, refunds and other money questions#

Escrow and refund terms are the money questions that surface late if nobody reads them early. Many source code escrow agreements list events such as the vendor ceasing to support the product as release conditions, so an end-of-life announcement may trigger notice or release steps. The exact wording, cure periods and dispute process decide what happens.

Prepaid fees are the other exposure. Customers on multi-year prepaid maintenance or subscriptions that extend past the end-of-support date may be entitled to pro rata refunds or credits under their order forms. Model the total before announcing, and decide whether to offer credits toward a replacement product instead.

A notice plan customers can rely on#

A notice plan customers can rely on states the dates, the commitments and the route forward in one place, and then repeats them consistently. Inconsistent messages between support, sales and the website create arguments about which promise applies.

Notice timing should follow the longest notice period in any active contract, plus time for customers to budget and migrate. Customers with annual budget cycles need to hear before the cycle in which they would plan a replacement, not after it has closed.

• 1Publish the end-of-sale, end-of-support and end-of-life dates for each product and version.
• 2State exactly what support, security fixes and compatibility work continue until each date.
• 3Explain the data export route, formats and the last date exports will be available.
• 4Describe migration options and any credits or discounts on offer.
• 5Name a contact for contract questions and a separate one for technical questions.
• 6Send notices through every channel the contracts require, and keep delivery records.

Illustrative: sunsetting an on-premises scheduling server#

Illustrative: a fictional vendor sells shop floor scheduling software to small machine shops and decides to retire its on-premises server edition in favor of its cloud product. The general counsel sorts customers into three groups: newer contracts with a discontinuation clause, older ones promising support for the paid term and a handful with escrow agreements.

The vendor announces dates well ahead, commits to critical security fixes until end of support and publishes a database export tool with documentation. It notifies the escrow agent, offers credits toward the cloud product and refunds prepaid maintenance beyond the end date for customers who decline.

Every notice, export download and customer reply is logged in the CRM. When one customer later claims it was never told, the vendor produces the dated delivery record from the CRM.

What happens to the product's records after end of support#

The product's records after end of support, including support tickets, bug histories, release notes and code reviews, remain the vendor's own business records, while customer content inside them stays subject to customer contracts and deletion duties. Decide what to keep, under which retention schedule, before the tools that hold them are cancelled.

Some vendors later license those records to AI developers. When SourceX is involved, the package moves through the SourceX five-step transaction, whose stages are Supply, Rights, Preparation, Approval and Delivery, and it opens with a fit check that asks only for metadata. Customer content found in tickets is removed in Preparation, and a SourceX Evidence Packet ties the released package to its provenance, licensing rights, permitted use, privacy record and release authorization.