We Moved Our Whole MSP to GDAP. Here Is the Checklist We Wish We Had.

Plenty has been written about what GDAP is. Much less has been written by MSPs who have actually finished the move. This post is the second kind: our team at Summit Technology, an MSP out of Salt Lake, migrated to GDAP internally in the fall of 2022, and these are the field notes, what we did in order, the structure we landed on, and the questions we had to answer the hard way so you do not have to.

If GDAP is new to you, start with the overview articles before reading further; this post assumes the basics.

One framing note up front: Microsoft changes timelines constantly (NCE, cough cough), but we treated this as a high-priority project anyway, because unlike some Microsoft mandates, GDAP delivers a real security benefit immediately.

The seven steps, in the order that worked#

1. Educate the whole team, not just the SME#

We assigned a GDAP subject matter expert, but stopping there is a mistake. Everyone needed a basic understanding of GDAP's benefits, transition timelines, and overall functionality, because the techs are the people most affected and the ones best placed to spot which processes would change. We also communicated timelines early so the customer conversion could be planned as a proper project.

Action items:

• Assign a SME for GDAP
• Hold a working session or sessions to educate your techs on GDAP

2. Pull real access data before guessing at roles#

We wanted concrete data on what techs were accessing and how often, because that data decides how to partition Azure AD roles across security groups and whether those groups deserve extra controls like PIM. Asking techs to self-document their access came up as an option; we wanted something more specific.

Like most MSPs, we had also created Global Admin accounts in customer tenants over the years, specifically for portals that DAP could not reach, like the security admin center, and we wanted the usage frequency on those too.

So we wrote a PowerShell script that captures the Azure AD sign-in logs from every customer tenant, looking for both our delegated sign-ins and the GA accounts living in customer environments. Note that pulling sign-in logs requires an Azure AD P1 license in the tenant; every customer of ours has at least Microsoft 365 Business Premium, so that was no obstacle.

A simple Power BI dashboard on top of that data shows which areas of M365 we touch most, sliced per technician and per customer:

We also reviewed and exported data from the Admin Relationships dashboard in Partner Center, which surfaces tenants we had not accessed in 30 to 90+ days, and folded that into the same report.

This stage also produced our open-questions list:

• What are the minimum roles we need to support our customers?
• How will GDAP affect our competencies?
• Will this affect anything with third-party integrations?
• How will this affect our access to Azure subscriptions?
• What is our distributor doing for GDAP?

Action items:

• Get real data on the resources your technicians interact with before choosing GDAP roles

3. Partition roles into security groups, then PIM all of them#

With the discovery data reviewed as a team, we drafted a security group structure with associated Azure AD roles, leaning on Microsoft's GDAP role guidance by task (opens in new tab). Our team is small (fewer than five), so we did not need more granularity than three groups; a larger team with specialized techs should split further.

Our distribution of roles:

• SG1: the roles our techs touch most, reader privileges wherever possible, so day-to-day work is never blocked.
• SG2: more privileged roles, accessed less frequently.
• SG3: Global Administrator. Not recommended with GDAP in general, but we discovered we needed it in customer tenants to perform on-behalf consent for app registrations (more on that below).

The original plan made only SG2 and SG3 PIM enabled. We changed our minds and PIM-enabled all three. That sounds like a productivity tax; in practice it is not, because:

• Techs can activate PIM for up to 8 hours, covering a workday
• SG1 still carries sensitive permissions (resetting passwords, deleting users)
• PIM means none of these roles are active after hours
• Higher groups can take extra activation controls, like enforced MFA

The ladder we settled on:

• SG1: PIM enabled
• SG2: PIM enabled + justification reason
• SG3: PIM enabled + justification reason + MFA push + approver

Action items:

• Determine which roles you need in customer environments
• Partition the roles across security groups
• Use PIM enabled groups for high-level roles. There is no reason not to: Microsoft is giving indirect resellers Azure AD P2 free for 2 years
• Define your naming convention for GDAP relationships
• Define relationship duration (2 years is the maximum)

4. Get the techs to sign off#

We reviewed the proposed groups and structure with all technicians before touching production. The goals: alignment, and pushing as many roles as possible up into the higher-control groups. Skipping this step buys you a mutiny three weeks later.

5. Pilot on one real customer#

We picked a customer with a medium volume of support requests, created a GDAP relationship in Partner Center, and manually accepted it in the customer environment. The pilot existed to answer four questions:

• What notifications does the customer get?
• Are we blocked from portals we need?
• Can we still access our Azure subscriptions?
• Is there functionality we were not expecting?

We documented everything. Overall it went well, apart from Partner Center sometimes refusing to load (go figure).

Action items:

• Create a GDAP relationship with one customer to test the changes
• Remember the GDAP relationship can be terminated as a rollback
• Do not remove the existing DAP relationship yet; GDAP takes precedence over DAP while the two coexist

6. Prepare the cutover#

After testing we adjusted the security groups and roles where needed, then handled the operational pieces:

• Set a date to move all customers to GDAP using the bulk migration tool
• Worked out exactly what notifications customers would receive and sent communications ahead of the change
• Established a break glass GA account in every customer tenant. GDAP relationships need renewing at least every 2 years, so you want a GA in the customer environment to do it. We used PIM in each customer tenant to make that account a Global Admin eligible user with MFA, meaning no perpetual GA rights. Customers on E5 already had PIM; for the rest we bought one Azure AD P2 license each, at $9 per month, cheap for what it buys
• Set a date to remove DAP relationships (Microsoft has stated it will do this for you at some point)

7. Bulk migrate everyone else#

With testing green, we used Microsoft's bulk migration tool to move all eligible customers to GDAP. The tool is only available until the end of November as of this writing, and we covered how to use it, and how CIPP compares, separately.

Action items:

• Use the bulk migration tool or CIPP to move customers to GDAP at scale

The questions we had to answer the hard way#

What do customers actually see?#

When a GDAP relationship is accepted, every Global Admin in the customer tenant receives this email:

Microsoft's support docs also show a termination notification email:

Who receives a GDAP termination notification:

• In the partner organization: people with the Admin agent role
• In the customer organization: people with the Global admin role
• Proactive emails also go out 30 days, 7 days, and 1 day before a GDAP relationship expires

One gotcha: if you work through a distributor, customer Global Admins get double the emails, because the distributor establishes its own relationship too. Warn customers before they ask.

Will integrations break?#

Yes, if you rely on app registrations. Any vendor using an app registration, or any automation you built on one across customers, breaks when DAP is removed. Full details in Vendor Integrations will Break with GDAP. This is also why our SG3 exists: on-behalf consent needs GA.

Do competencies survive?#

Untouched. As long as you hold the reseller relationship with the customer, competencies continue. Through a distributor, they associate your MPNID (now the PartnerID) to the customer and establish you as the reseller.

What about Azure subscriptions?#

GDAP changed essentially nothing here for us. PECs still require at least a Contributor role on the subscription itself, and subscription access is still dictated by the roles assigned on the subscription. We continue to manage all customer Azure subscriptions through Azure Lighthouse.

What is your distributor doing?#

Ask. Your distributor should be communicating GDAP plans and timelines; press them on which roles they intend to provision by default and what migration tooling they are using. Every control you put in place means very little if the distributor's relationship into the same tenants is sloppy.

The honest verdict#

Parts of this were genuinely frustrating, almost entirely because of Microsoft's API performance: Partner Center pages taking minutes to load, GDAP relationships not appearing, security group assignments stuck in pending. It improved, but one full week of the project was largely lost to it.

We also think Microsoft fumbled the tooling. A migration this important deserves a flow built into Partner Center, not a standalone tool with a shelf life. If the goal is compliance with the GDAP transition, make the transition easy to understand and perform.

None of that changes the conclusion: GDAP is a genuinely good change. Supply chain risk is one of the biggest threats MSPs carry, and GDAP finally gives a real way to manage it. The MSPs in forums saying "I will just assign every AD role so I keep the access I have today" are defeating the entire point. This is not NCE, where the work bought you nothing. The work here buys you a smaller blast radius on day one.

Resources we leaned on#

• Microsoft Operations Readiness Resource Gallery (opens in new tab)
• GDAP introduction, Partner Center docs (opens in new tab)
• GDAP relationship analytics (opens in new tab)
• Least privilege roles by task (opens in new tab)
• Monitoring admin relationships (opens in new tab)
• GDAP FAQ (opens in new tab)
• Adding GDAP relationships
• Leveraging PIM with GDAP
• Vendor integrations will break with GDAP
• GDAP bulk migration demo, CIPP vs Microsoft