Twenty-eight vendor deadlines in September, and how much notice each one gave

Twenty-eight vendor deadlines in September, and how much notice each one gave

This month our news desk reported 28 changes that software vendors made to products businesses already use: a model switched off, a price raised, a default turned on, a feature retired, a licence narrowed. For each one we recorded two dates, the day the vendor first told its customers and the day something changed for them. The gap between the two is the notice a buyer actually got.

The median was 31 days. Six of the 28 gave a week or less, and three gave none at all: the change took effect on the day it was announced. At the other end, eight gave more than three months and two gave about a year. Notice, in other words, is not a standard that vendors share. It ranges from nothing to a year, even between two teams at the same company. So a buyer who waits to be told will sometimes be told too late.

What we counted, and how

The 28 changes are every vendor-initiated change our news section reported between 20 and 25 September 2026 for which both dates could be established from a published source. We left out security incidents and exploited vulnerabilities, where the "notice" is an attacker's timetable rather than a vendor's; regulatory decisions and fines; acquisitions; and two changes whose announcement gave no date at all. Those two are Cloudflare's end of 32-bit Windows and Intel Mac builds of its tunnel client, which it said will happen "in 2027", and Microsoft Purview's change to legacy Teams retention policies, which is dated only "October". They are not in the numbers, but they belong in the argument, and we come back to them.

The notice date is the earliest date we could find on which the vendor told customers, not the day we reported it. Where a vendor revised a date, as Google did for Meet's note-taking default, we counted from the notice that fixed the date that held. The effective date is the first day a customer would notice something different: a price that applies, a feature that stops, a default that flips. Where a change has several stages, as HashiCorp's wind-down of HCP Vagrant does, we used the first.

Two items are approximate and marked as such in the chart. GitHub first set out its timetable for removing Node 20 from Actions runners in September 2025 and revised it several times, so "about a year" is as precise as the record allows. Trae's cut to existing subscribers' allowances lands at the first renewal at least 30 days after notice, so 30 days is the minimum, not the typical case. None of the 28 changes involves a product from Rutba, our parent company.

Where the short notice comes from

The six changes with a week or less are not a random draw. Three of them sit in AI products, where the pace of releases has made retirement feel routine to the vendor, if not to the customer.

• Google limited Gemini 2.5 to existing users with immediate effect in a release note on 18 September. A team that had planned a new project on it found the door closed the day it read the notice.
• Qwen's image model moved from Apache 2.0 to a research-only licence with the release that introduced it, so there was no window in which the new version could be used commercially on the old terms.
• Microsoft's notice that it is retiring its Microsoft 365 companion apps gives 16 December as the retirement date. But the same page says security fixes have already stopped. The date that matters to a security team is the one that had already passed when the page was published.

The other three short-notice items are commercial or behavioural, and each is short for a different reason. Microsoft's partner notice that CSP promotions on Microsoft 365 E5, E7 and Copilot end on 30 September came seven days before the end. Resellers had heard about the E5 date since July, but a customer depending on their reseller to pass that on had a week. Google gave seven days' notice of the final date for Meet's note-taking default, having earlier said only "not before 21 September". And Twilio's change to what its Conference list API returns was posted a week before it takes effect, although the page's address suggests an earlier notice in July.

The pattern is that short notice rarely comes from a single, sudden decision. It comes from a date being fixed late, from notice going to a partner instead of the customer, or from the change that matters (security fixes stopping) sitting beside a later headline date.

The long tail is not generous, just early

At the long end, OpenAI told developers on 26 September 2025 that four older models would stop on 28 September 2026, and in March it gave six months' notice of removing the Videos API and Sora 2. Okta told customers on 5 August that three Classic Engine features would be switched off on 5 March 2027. GitHub's removal of Node 20 had been coming for a year.

Long notice creates its own risk. Six months is long enough for the person who read the email in March to have changed jobs, for the integration to have been handed to a supplier, and for the notice to have been filed as something to do later. When we reported the Sora removal the day before it happened, the useful point was not that OpenAI had been late but that the notice had been early enough to be forgotten. A year of notice protects a buyer only if somebody still owns the date when it arrives.

The middle of the distribution, from 30 to 48 days, is where most of the month's changes fall: model retirements in GitHub Copilot, rate limits on GitLab.com, the move of GitHub's ubuntu-latest runner label, Atlassian's list-price rise and Azure Functions' end of support for .NET 8 and 9. A month is roughly one sprint and one budget cycle short of comfortable. It is enough if the notice reaches the right person in its first week, and not if it spends two weeks in a shared inbox.

Defaults that switch themselves on

Four of the 28 changes turn something on for existing customers unless someone turns it off. Google Meet's automatic note-taking for Business Standard and Business Plus, Twilio's failover of live transcription to a second speech provider, Microsoft Defender's user reporting of suspicious Teams messages, and pay-as-you-go billing on new Microsoft 365 Copilot Business licences. Their notice periods were 7, 30, 31 and 47 days.

These deserve more attention than a retirement, for a simple reason. When a product is switched off, someone notices, because something breaks. When a default is switched on, nothing breaks. Meeting notes start appearing, call audio goes to a second processor, reports start arriving in a mailbox, and usage starts accruing a bill. The customer who did nothing has, in effect, agreed. Two of the four send customer data somewhere it did not go before, which for a UK or EU business is a data-protection question, not a settings question. It may mean a new processor, a new retention period, or a privacy notice that is no longer accurate.

The practical rule is to treat an opt-out change as a decision with a deadline, not as information. The deadline is the last day on which "no" is still the default.

A deadline register: the method

Nothing in this month's list required inside knowledge. Every date was on a public page. What separates a team that was ready from one that was surprised is whether anyone was looking, and whether what they found went somewhere it would be acted on. A deadline register is the simplest way to make that happen. It is a single list, owned by one named person, of every dated change that affects software you pay for or depend on.

1. List what you depend on, not only what you buy. Start from your finance system's supplier list, then add what it misses: developer platforms and their runners, APIs your products call, AI models named in code, open-source components with hosted services behind them, and the products your suppliers run on your behalf. Nearly half of this month's 28 changes would reach a business only through its developers or an agency's code.

2. Name the page where each vendor announces change. For most vendors it is a changelog, a deprecations page, a lifecycle table or a partner announcements page, and it is rarely the same place as their marketing blog. Record the address. A register without the source pages turns into a list of vendors nobody checks.

3. Check on a schedule shorter than the notice you are likely to get. With a median of 31 days and about a third of changes under three weeks, a monthly check misses changes. A weekly check, even a quick one, catches almost everything in this month's set with time to act. Where a vendor offers email or RSS notices for its changelog, subscribe a shared address, not an individual's.

4. Record two dates for every entry, and the one that bites. Write down the announcement date, the effective date and, where they differ, the date that actually matters to you. The companion-app retirement is the example: 16 December on the page, but security fixes had already stopped. For an opt-out change, the date that matters is the last day to say no.

5. Give every entry an owner and a decision. "Noted" is not a decision. Each entry should end as one of: act by a date, accept the change, or escalate to the vendor or the reseller. Put the owner's name next to it, and move it when that person leaves.

6. Ask your resellers and suppliers what they have been told. Two of this month's changes reached partners before, or instead of, customers. If you buy through a reseller, managed service provider or agency, ask them each month for any vendor notices affecting your account, and write the question into the contract at renewal.

7. Keep undated announcements on the register. A change announced for "2027" or "October" has no date to put in a calendar, which is exactly why it gets lost. Record it with the vendor's words and a date to check again, and treat the arrival of an actual date as a new notice.

8. Review the register when you renew. A vendor whose changes consistently arrive with a week's notice is telling you something about how it will treat you. Notice periods are rarely in standard terms, but they can be negotiated for material changes, especially at renewal. A register gives you the record to ask for them.

What this count does not show

Twenty-eight changes in six days is a sample of what our news desk found and chose to report, not a census of every change vendors made. We report changes a buyer has to act on. Changes that are purely cosmetic, or that affect only a vendor's partners, are under-represented, and so are small vendors whose changelogs nobody reads. The median would shift with a different sample, and we would not treat 31 days as a statistic about the software industry. It is a statistic about the changes that reached us in one week, and the spread is the more reliable finding than the middle.

Our notice date is the earliest one we could find. A vendor may have told some customers earlier, in an account email or through a partner, that we could not see. In at least two cases in this set, earlier notice is likely: Microsoft's resellers had the E5 promotion date in July, and Twilio's Conference list change may have first been announced then too. For a customer who never received those earlier notices, though, the later date is the one they got.

We have not measured whether vendors honour their dates. Some of this month's items had already moved at least once, and Google's Meet default moved from "not before 21 September" to 29 September. A date on a changelog is a plan, and the register above works partly because it records when a plan changes.

Finally, notice is not the same as fairness. A week's notice of a promotion ending costs a buyer a discount. A week's notice of a model being switched off can stop a product working. The chart treats them the same, and a buyer should not.