SharePoint Provisioning

Automated creation of destination SharePoint sites, document libraries, Teams, channels, shared drives, and S3 buckets. Instead of clicking through twenty SharePoint admin-center pages before a migration can begin, describe the destination shape in MigrationFox and let the engine call the right platform API for each resource.

What triggers provisioning

Provisioning is never implicit. MigrationFox only creates a destination resource when you ask it to, through one of three entry points.

The Restructuring Wizard

If you are moving from a mega-site or a flat Google Drive structure into a proper set of SharePoint site collections, the Restructuring Wizard proposes a target layout (one site per top-level folder, one library per sub-folder, and so on) and provisions every site and library in the plan before any file moves. You can edit the plan before execution — rename, drop, or regroup any proposed site — and the provisioning step honors the edited shape.

The Provisioning tool on any project

Inside any MigrationFox project, open the Provisioning tool and:

1. Pick the resource type (SharePoint site, Team, document library, shared drive, S3 bucket).
2. Select the credential to use.
3. Enter the name and any resource-specific options (site template, channel type, membership).
4. Click Create. MigrationFox calls the platform API and adds the newly created resource to your project’s resource list.

This is the standalone path — useful when you are pre-staging destinations before any migration job is scoped.

Inline provisioning from the migration wizard

When selecting a destination path inside the migration wizard, if the folder or library you want does not yet exist, you can create it on the spot without leaving the wizard. The new resource appears in the destination picker and the job proceeds.

Site creation via Microsoft Graph

MigrationFox creates SharePoint sites through the Microsoft Graph API. The specific call depends on the template you pick (see Template selection), but the default shape looks like this:

• A group-connected team site backed by a Microsoft 365 group. This is the default and the shape most migrations land on.
• A Documents library ready immediately. Created as part of the site, accessible under the standard /Shared%20Documents path.
• Permissions inherited from the group. Whoever you add as a group member has site access; removals flow through the same group.
• Additional libraries provisioned separately. The Documents library is always present; extra libraries are created with their own Provisioning calls after the site exists.

Provisioning a site is asynchronous on the Microsoft side. The Graph call returns immediately with a site ID, but the site itself takes anywhere from a few seconds to about a minute to be fully ready for upload. MigrationFox polls the readiness endpoint before starting uploads against a freshly provisioned site, so you do not need to sequence the steps manually.

Slug-rename handling

SharePoint has a hard constraint: two sites in the same tenant cannot share the same URL slug. If you try to create a site at /sites/marketing when /sites/marketing already exists (even if the existing one was deleted recently and is still in the tenant’s recycle holding period), SharePoint refuses the creation or silently appends a number to the slug.

MigrationFox handles this explicitly so that batch provisioning does not leave you with a mix of expected and auto-renamed URLs:

• Pre-check before creation. Each proposed slug is queried against the tenant before the Graph create call. If a conflict exists, the provisioning step stops and shows you the conflict on the plan review.
• Explicit rename choice. You decide the alternative slug (for example marketing-2026) rather than accepting an opaque marketing1 that SharePoint would have chosen for you.
• Conflict detection for deleted-but-retained sites. SharePoint holds deleted site URLs in a recycle state for 93 days by default. A newly-deleted site’s slug is not available for reuse until the hold expires or a tenant admin purges it manually. MigrationFox flags this case clearly rather than looping on a create-that-will-never-succeed.

Template selection

Three site templates are commonly used for migration destinations. Each has a different Graph provisioning path and a different permissions model.

Prerequisites

Provisioning calls happen under the credential you pick at creation time. The role requirements on the destination side are:

• SharePoint Administrator role on the destination tenant — required for all site provisioning paths (group site, communication site, classic).
• Global Administrator is a superset and also works but is more access than needed. Prefer SharePoint Administrator for least-privilege setups.
• Teams Administrator if you are provisioning Microsoft Teams (the Team creation uses a different Graph surface than the site creation, even though they share the underlying group).
• Group.ReadWrite.All delegated scope (or application equivalent) on the OAuth credential, because group-connected sites are created through the Microsoft 365 group creation API.

The credential you use for provisioning does not have to be the same credential used for the subsequent migration. A common pattern: provision under a tenant-admin service principal, migrate under a lower-privilege user credential scoped to the specific sites that were just created.

Batch provisioning

For migrations that create dozens of destination sites (typical output of a Restructuring Wizard run on a large mega-site), MigrationFox provisions in sequence rather than all at once. Sequential creation is deliberate:

• Graph throttling. Site-creation is on a tighter throttle bucket than read calls. Parallel creation at scale triggers 429 Too Many Requests and forces backoff, which is slower overall than paced sequential creates.
• Group-provisioning eventual consistency. A freshly created Microsoft 365 group needs a few seconds before its members list is queryable for the next step. Sequential creation gives the platform time to settle between calls.
• Deterministic failure reporting. If one site in the batch cannot be provisioned (slug conflict, credential scope issue), the batch stops with a clear pointer to the failing site rather than producing a jumble of successes and failures in indeterminate order.

Known limits

• Provisioned resources cannot be renamed after creation through MigrationFox. Renaming a site URL or a group display name is a tenant-admin action that happens outside the migration workflow. Plan the slugs up front.
• Nested site collections are not a SharePoint concept. Every site collection lives at the tenant root (/sites/...). If your plan has an apparent hierarchy (Team A → Team A / Sub-team), that translates to two sibling site collections at the SharePoint level, not parent and child.
• Custom themes and site chrome are not applied at provisioning time. The created site uses the tenant default theme. Theme application is a post-provisioning step you run separately.
• Sensitivity labels are not automatically applied. If your tenant requires sensitivity labels on all sites, apply them after provisioning and before the first migration upload.
• Classic subsites under a site collection cannot be provisioned through the modern Graph API. If you genuinely need classic subsites for legacy compatibility, create them separately via SharePoint admin.

Troubleshooting

Symptom	Likely cause	Fix
Provisioning returns “slug already exists” for a site I am sure I never created	The slug was used by a site that was deleted but is still within SharePoint’s 93-day retention hold, or the slug matches an auto-generated vanity URL from the tenant’s early days.	Check SharePoint admin center → Deleted sites and purge the held site, or pick a different slug.
Site appears to create successfully but uploads fail immediately after	Graph returned the site ID before the underlying provisioning finished. MigrationFox polls readiness on its own creations, but a site created through a different channel (PowerShell, admin center) may not be ready yet.	Wait 30–60 seconds and retry, or use MigrationFox’s Provisioning tool which polls readiness automatically.
Group-connected site is created but the Team does not appear	The group was created but the Team creation call (a separate Graph operation) failed, commonly because the credential lacks Teams Administrator scope.	Grant Teams Administrator to the service principal and run the Teams provisioning step again. The group-connected site remains in place — the Team is added on top of it.
Permissions on the provisioned site do not match expectations	Group-site permissions flow from group membership. If you add users to the SharePoint site directly instead of the owning group, membership gets out of sync.	Manage membership through the Microsoft 365 group (Entra admin center or Teams), not through SharePoint site settings.
Bulk provisioning stops part-way with 429	Graph throttling during parallel creation.	MigrationFox paces creates sequentially by default. If you are seeing this, the job may have been configured with a custom parallelism that exceeds the throttle bucket. Revert to default pacing.
Credential works for read operations but fails at provisioning with 403 Forbidden	Read scopes (Sites.Read.All, Group.Read.All) are not enough. Provisioning requires write scopes.	Grant Sites.FullControl.All and Group.ReadWrite.All (application permissions) or the delegated equivalents, then reconsent.

Related

• Blocked file types — the tenant policy that can block uploads after a site is successfully provisioned
• SharePoint site pages — the canvas-page migration step that runs after site provisioning and content upload
• Skip junk files — scan-time filtering that reduces the data volume hitting the newly provisioned sites