Microsoft retires Targeted Release: your test ring is now paid for by everyone else

If you keep a handful of users in Targeted release so you hear about changes before the rest of the company does, that mechanism is ending. What almost nobody is covering is how Microsoft proposes you rebuild it: not by moving your test group forward, but by holding everyone else back. Same effect, but somebody else pays for it now.

On 7 October 2026 advisory MC1490899, "Microsoft 365: Targeted Release retirement", appeared in the Microsoft 365 Message center, tagged Major change, Admin impact and Retirement, with an act-by date of 31 October 2026 and the affected services in the header: Exchange Online, the Microsoft 365 suite, SharePoint Online, OneDrive and Teams. That same day Microsoft updated three documentation pages —the retirement notice, the Standard and Deferred configuration page, and the Frontier one— all three carrying the same ms.date: 2026-10-07T00:00:00.0000000Z and, more tellingly, the same commit identifier. They were written together and they have to be read together.

Three dates, and only one has a day

The configuration page puts it like this, verbatim, in a notice box: "In November 2026, administrators can no longer add users to, remove users from, or modify Targeted release enrollment. In January 2027, Targeted release will be retired and no longer available to use." November is the lock; January is the end. Neither carries a day. The only day Microsoft has committed to in writing is the 31 October in the Message center advisory, which is that advisory's way of saying "before November".

What lapses on 31 October is your ability to edit the list, not the service. After that your Targeted release users keep getting what they were getting —"Users assigned to Targeted release will remain in Targeted release until its retirement"— but you can no longer add or remove anybody. If new people join the validation group in December, they do not join. That is the whole of the urgency, and it is enough to look at this week rather than on the eve.

Targeted release was never early access, and that changes the arithmetic

There is a nuance here that slipped past most of us, ourselves included until we read it cold. The sentence is buried in the Frontier page, inside a notice box, and it is the one that organises everything else:

Frontier is for access to pre-GA features and Targeted
release is for access to features early within general
availability.

Targeted release did not hand you features before they existed for the public: it put you in the first wave of the general rollout. It is a small difference on paper and an enormous one in practice, because it means the value of Targeted release was never testing prototypes. It was something humbler and far more useful: having five people trip over the change before the other two hundred did, on code that was already supported and already in production. An early-warning system made of colleagues.

And there is the problem, because in the new model you cannot choose the first wave. The three options, with the definitions from the configuration page, are: Frontier, which comes before GA but which the comparison table itself classifies as "Pre-GA, not fully supported"; Standard release, which is GA and is everybody's default; and Deferred release, which is "Same functionality as Standard release, delayed 30 days after Standard release (GA) for major updates". There is no rung marked "GA, but you first". There is GA, what comes before GA without full support, and what comes after.

Microsoft's recommendation, read slowly

The retirement page carries a mapping table so you know what to move to. The row that matters is the second one, for anyone who had a validation group, and it is worth reading in full because everything is in there:

Targeted release for select users

  To preserve using an early production validation group
  while giving your broader organization additional time
  to prepare:
  - Choose Deferred release
  - Under "Assign users or groups for standard release",
    add validation, support, or pilot users.

Read it again. Your validation group does not move: it stays on Standard, that is, on plain old GA. What moves is the rest of the company, which goes to Deferred and receives major changes thirty days late. Microsoft is honest and writes it in the same sentence —"while giving your broader organization additional time to prepare"— but the framing is generous: that is not "additional time", it is the only way left to preserve the gap, because if you cannot move anybody forward, all you have left is holding the others back.

And there is small print that trims quite a lot of what that price buys. Deferred does not delay everything: it delays major updates, and the same page explains how to spot them: "In the Message center, features included in deferred release are tagged as both Major update and Deferred feature." Both tags, not one. Anything without them lands on the same day for your validation group and for everybody else, so for those changes your ring does not exist. In case the breadth of the filter is in doubt, the list of examples Microsoft gives for a major update includes everyday things like "changing a user's inbox, meetings, delegations, sharing and access that might result in help desk calls" or "a new service or application deployed with default settings turned on". It is wide, and the page opens it with a "might include", so it is not closed either: you cannot assume that what is absent from it fails to count as a major update, or the other way round.

One hundred

It is the number that made us stop while reading the configuration procedure, and the one most people will find out about late. The sentence, in full:

You can add up to 100 exceptions to Standard release or
Deferred release. Each user in a security group and each
user added individually count toward the 100-user limit.

The second sentence is the important one, and it is the one that disarms every administrator's reflex. The reflex is: "I will point it at a security group and manage it from Entra ID without coming back here." You can, and it is a good idea for maintenance, but it does not buy you scale: group members count one by one against the same cap of a hundred. A security group with a hundred and twenty people is not one exception, it is a hundred and twenty, and twenty of them do not fit.

For most of the companies we work with, a hundred is plenty: a healthy validation ring is between ten and thirty people. It bites in two places. If you had Targeted release switched on for a whole department —sales, or the entire Barcelona office— and that department runs past a hundred, your current list does not fit and you have to decide who gets left out. And because the list is a budget of people rather than of groups, adding somebody "just in case" stops being free: you have to choose, and choosing forces you to have a written criterion, which is precisely what almost nobody has.

Where the switch lives now (and why you will not find it)

The two paths are not in the same place, and the second is not where you would look for it. To see who is in Targeted release today, the retirement page sends you to Settings > Org settings > Organization profile > Release preferences. To configure the replacement, it sends you to Copilot > Settings > View all > Copilot Release preferences: General availability; and for Frontier, to Copilot > Settings > View all > Copilot Frontier.

The control that decides when your company receives changes to Teams, OneDrive, SharePoint Online, Outlook on the web, Office for the web and the admin center itself lives, today, inside the Copilot menu and is called Copilot release preferences. It matters for a practical reason rather than an aesthetic one: whoever owns change management will open Org settings, see Release preferences still sitting there, and walk away convinced there is nothing to do. And the same documentation warns that this screen is provisional too —"The current experience for managing Standard release and Deferred release preferences will be retired when the unified release preferences experience becomes available", in November. You will configure it in one place so that in a month it is somewhere else.

The configuration page adds three short, consequential things. The roles that can touch it are Office Apps Admin, Security Admin or AI Admin; if the change calendar in your organisation is owned by somebody holding none of the three, the change has no owner. It is not instant: "It can take up to 24 hours for the following changes to take effect in Microsoft 365", which is the reason not to leave it to six in the evening on the 31st. And the note at the end, the least amusing one: "If you move users from Standard release to Deferred release, they might lose access to features that aren't available yet in Deferred release" —moving somebody into the cautious ring can take away something they already had.

What is NOT included (and where a lot of people will lose an afternoon)

Before anybody panics about the whole estate: this is smaller than it looks. The retirement page bounds the scope by name, and the most reassuring sentence is the one about what it does not touch:

That leaves Frontier, the option most people will tick out of curiosity and the one that fits worst as a validation ring. Not because it is bad, but because it is designed for something else, and its own legal box says so plainly: "As preview features, Frontier experiences may be modified, suspended, or discontinued, may not be covered by standard support commitments or service level agreements", with the addendum that "Certain Frontier experiences may only be available on a paid basis". Something that can be suspended and may fall outside the service level agreement is good for evaluating and forming an opinion; it is not good for deciding whether your invoicing process survives the change. One more requirement worth knowing before promising anybody anything: Copilot-related Frontier features ask for a Copilot licence —"Users without a Microsoft Copilot license aren't presented with Copilot-related Frontier features".

The deliverable: half an hour before the 31st

This does not need a project. It needs one person with the right role, half an hour, and writing it down. In this order:

In one week we have written three times about the same shape of change: a default that moves on its own and only hurts where nobody had written a decision down. On 2 October, memory integrity switching itself on precisely where nobody had touched anything; on the 3rd, DLP alerts leaving the incident queue. That the vendor changes things is normal, that is what a service is. What is worth remembering is that the default is calculated for the average of millions of tenants, and your company is not the average. Failure is inevitable; an outage is a design decision. Here there is not even a failure: there is an advisory published on 7 October, twenty-four days until the act-by date, and a screen with two dropdowns.

What we are not claiming

Conflict of interest up front: we charge for this. That said, the expensive part is not the configuration. It is two dropdowns and your own people move them in half an hour. What costs money is answering who goes first and who goes behind when that question has never been answered in writing, and no screen resolves that. Sitting down with the estate in front of you and the names on the table is modern workplace work; turning the result into a change calendar that is still alive when whoever built it is on holiday is consulting work. If that answer is already written down at your company, today is half an hour of work and you need nobody. If reading "Copilot > Settings > View all" made you think you have never been in there, write to us.

Sources