Microsoft Entra memberOf Retirement: SMB Migration Plan

Microsoft Entra's preview memberOf rule operator is retiring. Microsoft says that after November 3, 2026, dynamic membership groups, dynamic administrative units, and entitlement-management auto-assignment policies using it will stop updating and retain their last known state. Businesses should replace affected logic before that date, not wait for an access failure. Microsoft's retirement guidance describes alternatives but does not provide a direct, one-for-one replacement. See the Microsoft retirement notice.

For an SMB, the immediate task is to find the rules, identify what depends on them, and prove that the replacement both grants intended access and removes access that is no longer appropriate. A successful sign-in alone is not a migration test.

What is retiring—and what is not

This change concerns the rule operator that builds membership from other groups. It is not a retirement of Microsoft Entra groups generally. Do not confuse it with Microsoft Graph's separately documented user memberOf relationship API, which reads existing directory memberships. A script reading that API is not, by that fact alone, an affected dynamic rule.

The preview label matters: do not build a new dependency on this operator while planning its removal. Treat the exercise as an access-control change, with named business and technical owners, rather than a simple syntax substitution.

1. Inventory all three configuration types

Record each tenant, the inventory time, the operator's approved scope, and whether every result page was retrieved. An MSP or co-managed IT team should keep client inventories separate. A permission error, inaccessible catalog, or interrupted export means incomplete inventory, not zero affected objects.

Start with read-only Microsoft Graph discovery. The following are v1.0 collection paths, not instructions to change a tenant. Have an authorized administrator approve the necessary read permissions and verify that their directory or catalog role covers the inventory.

On a small screen, scroll the table sideways to read all three columns.

Microsoft documents these in List groups, List administrative units, and List assignment policies. Follow every returned @odata.nextLink; a page-size setting is not an inventory limit. See Graph pagination guidance.

PowerShell discovery without a bulk-change script

For groups, use Get-MgGroup -All with -Property explicitly selecting Id, DisplayName, GroupTypes, MembershipRule, MembershipRuleProcessingState. For administrative units, use Get-MgDirectoryAdministrativeUnit -All with -Property explicitly selecting Id, DisplayName, MembershipType, MembershipRule, MembershipRuleProcessingState. Inspect rule text case-insensitively for memberOf, including paused configurations. These are inventory operations, not migration commands. Consult the current group and administrative-unit cmdlet documentation.

Access-package rules need a different inspection: identify automatic policies through automaticRequestSettings, then inspect specificAllowedTargets entries typed attributeRuleMembers for their membershipRule. Do not search only policy names or assume the rule is a top-level field. Microsoft's policy structure and attribute-rule target definition explain the nesting; its retirement guidance includes a ready-made read-only PowerShell policy scanner.

2. Map dependencies before choosing a replacement

For each finding, create one change record containing the object ID, exact rule, referenced source-group IDs, processing state, current membership or assignments, and export timestamp. Add the business purpose, technical owner, business approver, replacement approach, test cases, cutover window, and rollback owner. Store exports in restricted evidence storage, not a public ticket attachment.

Then trace the consumers. Check Microsoft 365 license assignments, Conditional Access inclusions and exclusions, Teams and SharePoint access, enterprise applications, administrative roles scoped to an administrative unit, and access packages. Ask application owners about integrations that reference an object ID rather than its display name.

Prioritize high-impact exceptions as well as grants. An obsolete Conditional Access exclusion can matter more than a missing collaboration permission. Microsoft documents that an exclusion overrides an inclusion; validate both sides of the policy. See Conditional Access user and group targeting.

Illustrative example: a staff member moves out of Finance. A frozen group might leave them in a finance access package while a new colleague never receives it. The migration must test both people. Matching yesterday's member count would not establish that either outcome is correct.

3. Choose a supported design, not a look-alike rule

Attribute-based rules when the business data is trustworthy

A department or governed extension attribute may express the original intent. Establish who maintains that attribute, how quickly it changes, what a missing value means, and who can edit it. Microsoft warns that dynamic-group security depends on attribute write permissions, including permissions in synchronized source directories. An employee-editable value is a poor basis for sensitive access.

User and device rules have different supported properties; a device rule cannot simply use its owner's user attributes. Validate the replacement against the supported dynamic-rule syntax and security considerations, rather than mechanically replacing memberOf with a department test.

Assigned membership when automation cannot express the intent

Assigned membership can be a controlled fallback when the organization lacks reliable attributes or the membership reflects individual approvals. It needs an owner, a joiner/mover/leaver process, a review interval, and explicit removal responsibility. A copied list without that operating process merely relocates the stale-access problem.

Where supported, converting the existing group preserves its identity; a new group requires a dependency-repointing plan. Follow Microsoft's membership-type conversion guidance. Do not blindly clear group-type settings or assume a Microsoft 365 group is interchangeable with a security group.

Ordinary nesting is not a universal workaround. Microsoft lists restrictions for group-based licensing, application assignment, and Microsoft 365 group nesting. Check the actual consumer against Microsoft's directory service limits before substituting a nested-group design.

4. Handle administrative scope and access packages separately

Administrative units: validate who can administer which objects, not just who appears in a list. Adding a group to an administrative unit does not automatically place that group's users inside the unit's administrative scope. Confirm intended and prohibited administrative operations with appropriately scoped test accounts. See administrative-unit scope semantics.

Microsoft documents that switching a dynamic administrative unit to assigned membership retains its current members. That is a starting snapshot, not a substitute for owner review and future membership maintenance. Follow the administrative-unit conversion procedure; do not reuse a group conversion script against a different object type.

Entitlement management: Microsoft's current notice says affected policies enter quarantine starting November 3. The policies remain, but automatic additions and removals stop until memberOf is removed from the rule. Arrange the alternative assignment approach before removing an old policy. Do not edit the system-managed evaluation group or introduce overlapping automatic policies for the same users; Microsoft warns that overlap can cause access loss. See the automatic-assignment policy guidance.

Also preserve the intended removal behavior and any grace period. Those are separate settings, not consequences to guess from the replacement rule. Review automatic-request settings with the access-package owner, then test the assignment and the downstream resource permission.

5. Pilot against expected access—not just an old export

Keep before-and-after exports, but have owners approve the expected population independently. An existing list can already contain an error. Use object IDs for comparison, flag unexplained additions and removals, and keep exception decisions alongside the diff.

Our recommended pilot includes these cases:

• Joiner: a newly eligible user or device receives the intended membership and downstream access.
• Mover: a changed department or responsibility removes old access and grants only the new scope.
• Leaver: loss of eligibility produces the expected removal; do not replace established account-disable procedures with this test.
• Negative case: an ineligible account, missing attribute, or out-of-scope administrator does not gain access.
• Exception: an approved special case remains explicit, owned, and time-bounded rather than hidden in a broad rule.

For supported replacement dynamic-group rules, use Entra rule validation with representative users or devices, but separately verify the actual service outcome. The original memberOf rules do not support that validator. Microsoft's rule-validation tool checks expressions; it does not certify a complete licensing, Teams, SharePoint, or access-package migration.

Allow for asynchronous processing. Microsoft's processing guidance notes that dynamic membership updates can take more than 24 hours in some circumstances. Do not schedule the only pilot on November 2 or declare success immediately after saving a rule. Check the per-group processing status and downstream results.

6. Make cutover, rollback, and support ownership explicit

Choose a small, representative first wave and a business-approved observation window. Re-export immediately before the change, record the exact configuration applied, and proceed only when the pilot's expected grants, removals, administrative boundaries, and service checks pass. Stop the next wave for unexplained membership drift, access loss, excessive access, or unverified inventory scope.

A rollback plan should identify the object/configuration to restore, how to reconcile membership changes made during the window, and any temporary owner-approved assignments. Restoring a retired memberOf expression after the cutoff cannot be treated as a way to restart its processing. Have a supported fallback ready. Do not blindly restore every exported member and accidentally re-grant access to a departed employee.

Tell the service desk which services and user groups may be affected, when changes occur, what symptoms to collect, and who can authorize an exception. Explain that users should not create duplicate access requests or work around security controls while IT investigates. Give business owners a clear escalation contact and a status-update time.

Retain a compact audit packet: discovery completeness, original and replacement rules, scoped membership/assignment exports, owner approvals, test evidence, exception expiry dates, cutover timestamps, and recovery decisions. Set retention and access according to company policy. These records support an audit; they do not by themselves establish compliance.

7. Monitor until the new process proves itself

After cutover, review membership differences, policy processing errors, license-assignment failures, unexpected sign-in or access problems, and access-package grants and removals. Check at the end of the change window, the next business day, and through at least one relevant joiner/mover/leaver cycle. Assign a person to investigate each unexplained difference.

Before November 3, repeat the read-only scan across all three surfaces and reconcile every remaining finding with the exception register. An exception needs an owner, an expiry, a supported temporary control, and an understood business risk; it is not permission to rely on frozen automation indefinitely.

The finish line is a documented access process that continues to make the right decisions—not an empty spreadsheet column. If your team needs help reviewing Microsoft 365 dependencies and coordinating a controlled change, explore ITECS Microsoft 365 consulting or discuss your migration scope with ITECS.

Editorial note: Prepared with AI assistance using Microsoft documentation checked September 24, 2026. Examples are illustrative. No customer tenant was inspected or changed for this article. Recheck Microsoft guidance and your tenant's permissions, licensing, and supported configuration before implementation.