Targeted Release is retiring. How to set up Frontier, Standard and Deferred release — and why you need a test tenant
From November 2026 you can no longer change who is in Targeted Release in Microsoft 365, and in January 2027 Targeted Release goes away completely. What replaces it, what happens to your pilot group, and why we recommend running a test tenant alongside production.
Many organisations have a simple way of not being caught out by Microsoft 365 changes: a few people from IT and the helpdesk are enrolled in Targeted Release, so they see new features slightly earlier than everyone else and have time to try them out and prepare support. That arrangement is ending. On 7 October Microsoft announced (MC1490899) that Targeted Release will be retired in January 2027 — and that from November 2026 nothing in it can be changed. The recommended act-by date is 31 October.
This article sums up what replaces Targeted Release, what happens to your current configuration, and why now is a good moment to take a step we have long recommended: running a test tenant alongside your production tenant.
What changes and when
| When | What |
|---|---|
| now | check who is in Targeted Release and configure the new release preferences |
| November 2026 | users can no longer be added to or removed from Targeted Release; a unified Release preferences page arrives in the Microsoft 365 admin center |
| January 2027 | Targeted Release is retired; its users receive features according to their new preference (Standard or Deferred) |
If you do nothing, you won’t miss out on new features. Users in Targeted Release simply fall back to your organisation’s default preference once it is retired. But you lose the head start you have relied on so far — your pilot group will see new features at the same time as everyone else.
The change applies to services that currently deliver features through Targeted Release: the Microsoft 365 admin center, Teams, OneDrive, SharePoint Online, Outlook on the web, the new Outlook for Windows and Office for the web. It does not affect Microsoft 365 Apps update channels for the desktop apps, Windows update channels or the Microsoft 365 Insider programme.
Three new options
| Option | What you get | What to keep in mind |
|---|---|---|
| Frontier | features before general availability (preview) | opt-in only, features may change, not covered by general-availability SLAs |
| Standard release (default) | features as soon as they are generally available | the recommended choice for most organisations |
| Deferred release | major changes around 30 days after Standard release starts | only changes Microsoft marks as deferrable are delayed; everything else arrives on the Standard schedule |
Frontier can be combined with Standard or Deferred. A user in Frontier gets early only what is part of Frontier; everything else follows their general-availability preference. Frontier is also no longer AI-only — it now includes non-AI features as well. You don’t need a Copilot licence to enrol users in Frontier, but without one they won’t see Copilot features.
What happens to your current configuration
Microsoft provides a simple mapping table:
| Today | Recommendation after the change |
|---|---|
| Targeted Release for everyone | Standard release; if you need more time for major changes, Deferred release |
| Targeted Release for selected users | Deferred release for the organisation, and add validation, support and pilot users (typically IT and the helpdesk) as exceptions to Standard release |
| Standard release for everyone | nothing, Standard is the default |
The second row is the most common one and worth thinking through. The principle stays the same as before: a small group sees new features ahead of the rest of the company. But the head start now works differently — the organisation receives major changes about a month later, and the pilot group gets them straight away.
What to watch out for
- Deferred doesn’t delay everything. Only major changes that Microsoft marks as deferrable are delayed (in Message Center they carry both the Major update and Deferred feature tags). Everything else — including major changes without the Deferred feature tag — reaches everyone at the same time.
- There are at most 100 exceptions. Every user added individually and every member of a security group counts towards the limit. A pilot group of a few hundred people won’t fit.
- Moving to Deferred can take things away. If you move users from Standard to Deferred, they may lose features that aren’t available in Deferred yet. Tell people in advance.
- Changes take up to 24 hours. Frontier takes effect within about three hours.
- Frontier is preview. Features may change or disappear, standard support commitments may not apply, and Microsoft states explicitly that they do not comply with ISO 27001, ISO 27002 or ISO 27018. Some may be paid only.
- Who can change the settings: the Office Apps Administrator, Security Administrator or AI Administrator role. Today the setting lives in the admin center under Copilot › Settings › View all › Copilot Release preferences: General availability (Frontier under Copilot Frontier); in November it moves to the unified Release preferences.
Why we recommend a test tenant
Release preferences decide when who gets a new feature. They don’t decide where you can safely try out what it does to your environment. For that we recommend running a second tenant alongside production — a test tenant. It is a small investment, and it covers what release preferences cannot:
1. Tenant settings can’t be tested on a handful of people. Sharing rules, Conditional Access, retention and DLP policies, Copilot spending policies and SharePoint settings apply to the whole tenant or to large groups. Changing them “live” means testing on the entire company. In a test tenant you can check the impact without risk.
2. More and more features arrive switched on and can’t be turned off. We have seen it repeatedly in our monthly overviews — the new Teams meeting controls and HTML pages in SharePoint can’t be disabled tenant-wide. A test tenant in Frontier shows you what is coming before production sees it. If production is on Deferred, even a test tenant on Standard release gives you about a month’s head start on deferrable major changes to prepare guides and the helpdesk.
3. Your own solutions need their own test. SPFx web parts, Power Automate flows, integrations with other systems, admin scripts. When Microsoft changes something they rely on, you want to find out in the test tenant, not from your users.
4. Preview features don’t belong with every company’s live data. Microsoft says that enrolling users of a production tenant in Frontier is safe, and admins have full control over who gets what. But for organisations certified to ISO 27001 or working with sensitive data, it matters that Frontier features don’t meet these standards. Trying them out in a separate tenant with test data is a cleaner solution than doing it in production.
5. The 100-exception limit. You can’t have a large pilot group in production. In a test tenant you don’t need exceptions — you can set both Standard release and Frontier for everyone.
What a test tenant should look like
- The same licences as production, just fewer of them. A few users on the same plans, so they see the same features. If you want to test Copilot, the test tenant needs a Copilot licence too.
- The same key settings. Sharing rules, Conditional Access, retention and SharePoint settings configured as in production. Otherwise you are testing something other than what will run live.
- Test data, not a copy of production. Personal data and sensitive documents from production don’t belong in the test tenant.
- An owner and a regular rhythm. A test tenant without an owner is unused within six months. It is enough for one person in IT to go through Message Center once a week and try out whatever affects you.
Recommended configuration
| Production tenant | Test tenant | |
|---|---|---|
| GA preference | Deferred release for the organisation | Standard release |
| Exceptions | IT, helpdesk and pilot users to Standard release (max. 100) | — |
| Frontier | off, or only a few people from IT | on for everyone |
The result is a three-tier head start: the test tenant sees previews, the pilot group in production sees generally available features straight away, and the rest of the company gets major changes about a month later, with support already prepared.
What to do now (ideally by 31 October)
- In the admin center, check who is in Targeted Release today (Settings › Org settings › Organization profile › Release preferences).
- Decide on the organisation’s preference — Standard or Deferred — and set exceptions.
- Decide whether, and for whom, to enable Frontier.
- Update internal documentation and processes that refer to Targeted Release.
- Let the helpdesk, security and compliance teams and the pilot group know.
- If you don’t have a test tenant, plan one.
Key takeaways
- Targeted Release retires in January 2027, and the freeze comes in November. Configure what you want to keep now.
- Move your pilot group to Standard release and give the organisation Deferred release. Mind the 100-exception limit and the fact that Deferred delays only major changes.
- Frontier is preview. It has its place, but without general-availability SLAs and without compliance with ISO 27001, 27002 and 27018 — use it in production only deliberately.
- A test tenant is a safety net that release preferences can’t replace. It lets you verify tenant settings, your own solutions and features that can’t be switched off — before they reach your users.
We handle release preferences, test tenants and ongoing tracking of Microsoft 365 changes as part of an environment review and a governance design. If you want help moving off Targeted Release, or setting up a test tenant that actually gets used, get in touch.
Sources: Microsoft Message Center MC1490899 (7 Oct 2026), Microsoft Learn — Plan for the retirement of Targeted release, Configure new Standard and Deferred release options, Get started with the Microsoft Frontier Program.