Forum Discussion
MSSP migration to Unified portal: how are you sequencing your customer portfolio?
Following the automation and SOAR discussion, I wanted to open a conversation specifically focused on the MSSP and multi-tenant side of the migration, because this is where the coordination challenges are an order of magnitude higher than the technical ones.
A few things I am working through before writing this up as Part 5 of the migration series.
On Workspace Manager: Microsoft's own documentation now points you away from Workspace Manager at the point of onboarding to the Defender portal, directing you to Microsoft Defender multitenant management instead. For MSSPs who built their operating model around Workspace Manager, this is a significant structural change. For those implementing now, the recommendation is to go straight to the multitenant portal. I am interested in what the transition has looked like in practice for teams who were mid-flight on Workspace Manager when this became clear.
On access delegation: one of the more honest framings I want to include in the article is around the GDAP plus Unified RBAC gap. A Microsoft employee confirmed in the RSAC 2026 thread that Unified RBAC support for GDAP in the Defender portal is on the roadmap with no firm date. MSSPs choosing between Entra B2B and the governance relationships model today are making an architectural call that is difficult to reverse. I want to present this accurately, and real experience from practitioners will sharpen that framing.
On the connector deployment constraint: you cannot deploy connectors from a managed workspace configured with Azure Lighthouse alone, you also need GDAP. This makes a layered delegation architecture, Lighthouse plus GDAP plus B2B or governance relationships, necessary rather than optional. I am curious whether MSSPs are already running this layered model or whether most are still trying to make Lighthouse work as a single mechanism.
On migration sequencing: the question I want to ask specifically is how teams are structuring their customer portfolio migration. Are you running waves based on customer complexity, based on contract renewal timing, based on customer risk appetite, or some other factor? And when something goes wrong in one tenant's migration, how are you containing the impact on the rest of the programme?
Sharing the full article once it is written. Happy to discuss anything above in more detail in the thread.
1 Reply
I’d sequence by technical risk, not renewal date. Start with two or three cooperative tenants that represent the access patterns you actually support—single workspace, multi-workspace, and Lighthouse/GDAP—but avoid your largest customer. Use each as a canary and require an exit checklist: workspace onboarding complete, analyst access validated, incidents and alerts visible, automation/playbooks exercised, connectors checked, and rollback ownership documented.
Then migrate waves of similar tenants rather than a mixed batch. Keep each wave small enough that one engineer can pause it, and don’t start the next wave until the previous one has passed 24–48 hours of monitoring. Contract timing can choose among equally ready customers; it shouldn’t override technical readiness.
I’d also keep Sentinel permissions on Azure RBAC wherever GDAP groups are required, because Microsoft’s current unified RBAC documentation says assigning permissions to GDAP user groups isn’t supported. Track each tenant with the Sentinel Deployment and Migration workbook plus a named go/no-go owner.
