Targeted Release Retirement: Nov 2026 Release Rings Guide

TL;DR: Microsoft is retiring Targeted release in January 2027, and in November 2026 admins lose the ability to change who is enrolled. Organizations that used it for pilot groups need to rebuild those rings with Standard release, Deferred release and Frontier now. This guide gives you a migration map and eight steps to finish before the freeze.

The Targeted release retirement looks small in Message center and is large in practice. Microsoft's post MC1490899 asks admins to act by October 31, 2026, because enrollment changes freeze in November. If IT and a few power users relied on Targeted release to see changes first, that early warning system disappears in January 2027 unless you replace it.

Targeted release is the Microsoft 365 option that let selected users, or a whole tenant, receive generally available updates before everyone else. Its replacement has three audiences: Frontier for previews before general availability, Standard release at general availability, and Deferred release, which holds eligible major updates for about 30 days.

Who is this guide for, and what will you have at the end?

This guide is for Microsoft 365 administrators, IT managers and change leads in organizations that use Targeted release today. By the end you will have a signed-off release preference for the tenant, a validation or business-critical exception group, a deliberate Frontier audience, and a weekly routine for deferred updates.

The rings matter more now because Microsoft is shipping more changes that affect daily work, such as the OneDrive hero links change and the SharePoint agents upgrade before March 2027. Both land more smoothly when a small group sees them first.

What do you need before you start?

You need an admin role that can manage release preferences, a security group for exceptions and a clear view of which services are in scope.

Standard release vs Deferred release: which one replaces your Targeted release setup?

Most organizations should pick Standard release for the tenant, unless they used Targeted release for a pilot group. In that case, put the tenant on Deferred release and assign the pilot group to Standard release, so validators still see major changes about 30 days before everyone else.

Use this migration map as your decision record. It adds an owner and a Frontier decision to Microsoft's guidance.

For education and nonprofit tenants, a 30-day Deferred buffer keeps major changes away from exam periods and fundraising campaigns.

How do you move from Targeted release to the new release preferences?

Record your current setup, choose a tenant default, add one exception group, decide on Frontier and update your change process. The eight steps take about two hours of admin time, plus agreeing who belongs in each group.

1. Find out who is in Targeted release today. In the Microsoft 365 admin center, go to Settings > Org settings > Organization profile > Release preferences. Record whether the tenant is set to Targeted release for everyone, Targeted release for select users or Standard release, and export the list of select users. Expected result: You know which row of the migration map applies to you and who your current pilot users are.
2. Create one Microsoft Entra ID security group for your exceptions. Create or reuse a dedicated security group, for example M365-Release-Validation for early validators or M365-Release-Deferred for business-critical staff. Keep it under 100 users, because each user in a group counts toward the 100-exception limit. Expected result: A named, owned group that holds the people who should get changes earlier or later than everyone else.
3. Open the general availability release preference. Go to Copilot > Settings > View all > Copilot Release Preferences: General Availability. Despite the Copilot menu, it controls release timing for Teams, SharePoint Online, OneDrive and other in-scope services. Expected result: The page shows your current tenant default, which is Standard release unless someone changed it.
4. Choose the tenant default from the migration map. Select Standard release if users should get features as soon as they reach general availability, or Deferred release if the organization needs about 30 more days to prepare for major updates. Expected result: The tenant default matches the decision you signed off in the migration map.
5. Add your exception group and save. If the tenant is on Deferred release, add the validation group under Standard release. If the tenant is on Standard release, add the business-critical group under Deferred release. Select Save. Expected result: The settings save. Allow up to 24 hours for the change to take effect.
6. Decide who joins Frontier. Go to Copilot > Settings > View all > Copilot Frontier and choose No access, All users or Specific users and groups. If you enable it, confirm Allow agents and plugins built by Microsoft under Agent > Settings > Agent and plugin access. Expected result: A deliberate Frontier audience. Features can take up to three hours to appear.
7. Set up a weekly Message center review for deferred updates. In Message center, filter for posts tagged Major update and Deferred feature, and use the Rollout timing column to plan. Give one owner a 30-minute weekly slot to triage them with the validation group. Expected result: A running list of upcoming deferred changes, each with an owner and a target date for user communications.
8. Update runbooks and notify stakeholders. Replace every reference to Targeted release in change, support and pilot documentation. Brief change management, the help desk, security and compliance teams and pilot users on the new audiences. Expected result: No process depends on Targeted release, and everyone knows which ring they are in.

In November 2026, Microsoft moves all three options into one unified Release Preferences experience in the Microsoft 365 admin center. Check your settings there once it appears.

If you are weighing who should join Frontier, our comparison of Copilot Chat, Cowork, Code and Autopilot explains what early adopters will actually be testing.

What are the most common mistakes, and how do you fix them?

The most common mistake is treating Frontier as a like-for-like replacement for Targeted release. Most others come from assuming Deferred release delays everything.

• Putting the old pilot group into Frontier only. Frontier features are previews, not generally available changes. Assign the group to Standard release with the tenant on Deferred release, and add Frontier separately.
• Expecting Deferred release to hold every change. Only features tagged Major update and Deferred feature are delayed, and tenant-wide changes can reach everyone at once. Keep your weekly review and feature-level controls.
• Using a large group as an exception. A 300-person department exceeds the 100-user limit. Create a smaller, purpose-built group.
• Moving users from Standard release to Deferred release without warning. They may lose features that haven't reached Deferred release yet. Tell them before you save.
• Leaving the decision until November. After the freeze you can't edit Targeted release assignments. Complete steps 1 to 5 this week.

Release rings work best on a governed tenant. Our governance checklist for a Copilot-ready intranet covers the permission hygiene that makes any rollout smoother.

How do you check that the new release rings worked?

You can tell the new rings are working when the settings page, the group membership and real user experience all agree. Check all three after the 24-hour propagation window.

• Reopen Copilot Release Preferences: General Availability and confirm the tenant default and exception group are saved.
• Confirm the exception group has fewer than 100 members and a named owner.
• Pick the next Message center post tagged Deferred feature and confirm a validation user receives it before a Deferred release user does.
• If you enabled Frontier, confirm a Frontier user sees agents marked (Frontier) in the Agent Store within three hours.

How do you measure the value of Deferred release and your validation group?

Measure Deferred release by the help desk demand and lost time it prevents. Track tickets per major update, days of lead time before users are affected, and the share of deferred updates validated before they reach everyone.

Here is a worked example using a 2toLead illustrative model; replace the assumptions with your own numbers. A 1,200-person professional services firm sees eight deferred-eligible major updates a quarter. Without preparation, each one generates 40 how-do-I tickets at 15 minutes each, which is 10 hours per change and 80 hours a quarter. At a loaded cost of $55 an hour, that is $4,400 a quarter.

If the 30-day window, a validation pass and a two-line user briefing halve those tickets, the firm saves 40 hours. Validation costs about one hour per change, or 8 hours a quarter. The net is 32 hours and $1,760 returned each quarter, roughly $7,000 a year, before counting employee time no longer lost to surprises.

Report these numbers alongside your adoption measures. Our guide to Copilot adoption metrics that prove value shows how to present time returned in a way finance leaders accept.

Targeted release was a calendar. The new model is a set of audiences, and someone has to own them.

What do IT leaders ask about the Targeted release retirement?

What happens if we do nothing before November 2026?

Users assigned to Targeted release keep receiving its features until it retires in January 2027. After that, they follow your Standard release or Deferred release preference. Microsoft won't change your release preference settings for you, so a tenant that never set one simply defaults to Standard release.

Is Frontier the replacement for Targeted release?

No. Frontier gives early access to preview features before general availability, while Targeted release gave early access within general availability. The closest match to a Targeted release pilot group is a tenant on Deferred release with a validation group assigned to Standard release.

Can we defer individual Microsoft 365 features?

No. Deferred release only delays features tagged in Message center as both Major update and Deferred feature. Other updates arrive on the Standard release schedule, and some tenant-wide changes reach all users at once regardless of audience.

Does the Targeted release retirement affect Microsoft 365 Apps update channels?

No. Microsoft 365 Apps update channels, Windows update channels and Microsoft 365 Insider programs are not affected. The change covers services such as the Microsoft 365 admin center, Teams, OneDrive, SharePoint Online, Outlook on the web, new Outlook for Windows and Office for the web.

How can 2toLead help?

2toLead helps organizations in professional services, healthcare, education, nonprofit and government turn Microsoft 365 changes into governed, measurable outcomes. In a fixed-scope, two-week Release Rings Reset Sprint, our Microsoft MVP team will:

• Audit your Targeted release setup and sign off a migration map
• Configure Standard, Deferred and Frontier audiences with owned security groups
• Set up a weekly Message center triage routine
• Update change, support and pilot runbooks
• Hand you a quarterly scorecard for tickets per major update and hours returned

For the full background, read Microsoft's plan for the retirement of Targeted release.

To see what the new rings will deliver, the Microsoft 365 E7 Frontier suite overview and our October 2026 Copilot Adoption Newsletter are good next reads.

Find more practical guidance on the 2toLead Insights hub, or book a Release Rings Reset Sprint.

No hype. Just practical, governed AI that actually gets adopted.