🏢 Source environment
Understand what you're migrating from — version, topology, and current health all drive tooling and complexity decisions.
What is the source platform and version?High risk
SharePoint 2010/2013 have deprecated features and classic publishing sites that cause significant migration failures. On-prem versions also lack direct migration paths for certain content types.
⚠ SP 2010/2013 carry significant risk: classic publishing, InfoPath forms, deprecated web parts, and broken upgrade paths are common. Plan for extended assessment time.
What is the destination?Baseline
⚠ Tenant-to-tenant migrations require additional identity mapping, external sharing re-configuration, Teams/OneDrive coordination, and licensing for both tenants during cutover. This significantly increases scope.
How many site collections / sites are in scope?Scope driver
Site count determines wave planning, licensing costs, and staffing. Even rough estimates help early scoping.
How much total data is in scope (GB / TB)?Scope driver
Data volume drives migration tool selection, wave scheduling, throttle management, and timeline. SPO has a 25 TB tenant soft limit and site collection limits of 25 TB each.
Has a content inventory / discovery scan been run?Critical
Many migrations are scoped on assumptions, then derailed when scanning reveals 3x more content, unsupported web parts, or broken permissions. A pre-migration scan is non-negotiable for accurate scoping.
⚠ Without a full inventory, your scope estimate has high variance. Recommend including a discovery/assessment phase in this engagement before fixed-cost migration work begins.
📁 Content types & structure
The type and age of content is often the biggest migration complexity driver. Many issues only surface when tools begin processing content.
Are there publishing sites or classic team sites with custom page layouts?High risk
Classic publishing sites and page layouts (master pages, .aspx) do not migrate to modern SPO. These require manual redesign as modern Communication or Team sites. This is often the single largest effort item.
⚠ Publishing sites and classic page layouts require complete redesign — migration tools cannot convert them. Each site needs manual effort. This must be called out explicitly in SOW scope.
Are InfoPath forms in use?High risk
InfoPath is retired and not supported in SPO. Forms must be rebuilt in Power Apps or similar. Even "simple" InfoPath forms can take significant effort to re-create if they have rules, data connections, or submission logic.
⚠ InfoPath forms will NOT migrate. This is a hard blocker for any site using them. A separate rebuild workstream in Power Apps is required — add to risk register.
Are SharePoint Designer (SPD) workflows in use?High risk
SPD 2010 workflows are deprecated. SPD 2013 workflows have no direct path to Power Automate. Both require manual rebuild. This is routinely underestimated — a single complex approval workflow can take weeks to rebuild and test.
⚠ SPD workflows require rebuild in Power Automate. There is no automated conversion tool. Catalog every workflow and estimate rebuild effort per flow — this can easily exceed the document migration effort.
Are there custom content types, site columns, or managed metadata?Medium risk
Custom content types migrate but often require re-mapping in the destination. Managed metadata (term stores) needs to be pre-staged in the target before document migration or metadata will be lost or broken.
What is the average age of content? Is there stale / archived content?Scope control
Migrating everything is almost always a mistake. A content archiving or cleanup phase before migration dramatically reduces size, cost, and risk. Many organizations have 60–80% stale content.
Are large files (>15 GB individual) or deep folder hierarchies present?Technical risk
SPO has a 250 GB file size limit (migration tools sometimes hit errors below that). Deep paths (>400 characters) fail silently. Both are common failure sources that won't be caught without a scan.
⚠ High-risk technical items
These areas are the most common causes of migration failures, delays, and scope creep. Ask these even if the customer seems uncertain — unknown answers are themselves a risk signal.
Are there third-party or custom web parts / add-ins deployed?High risk
Classic web parts do not migrate. Custom add-ins (SharePoint Add-in model) are also deprecated. Modern SPFx web parts do migrate but must be re-deployed to the target app catalog. Third-party products (Bamboo, Nintex, KnowledgeLake, etc.) need separate licensing and reinstallation in the target.
⚠ Classic web parts will break. Third-party add-ins need re-licensing. SPFx web parts need app catalog re-deployment. Every custom/third-party web part must be inventoried and assessed individually.
Are there external users or guest access configurations?High risk
External users do not migrate. Guest accounts need to be re-invited in the target. In a T2T migration, all external sharing links break. Customers with partner portals or vendor-facing sites often don't realize this until go-live.
⚠ All external sharing links and guest accounts will be invalidated. A guest re-invitation plan and external user communication strategy is required — often overlooked until too late.
Are there apps, integrations, or systems that connect to SharePoint via URLs, APIs, or mapped drives?High risk
Any system with hardcoded SharePoint URLs will break after migration — ERP integrations, mapped network drives, Power BI datasets, Power Automate flows pointing to source, custom apps, LOB connectors. This is consistently underestimated.
⚠ Every integration must be inventoried and have a cutover/re-pointing plan. Include integration owners in communication and cutover planning. This often requires work outside the migration team's control.
Is Nintex, K2, or another third-party workflow platform in use?High risk
Nintex, K2 (now Nintex Automation Cloud), and similar tools require separate migration approaches — they are not handled by standard SharePoint migration tools. Nintex has its own migration tooling but it's complex and often incomplete.
⚠ Third-party workflow platforms require a separate workstream. Contact the vendor (Nintex, etc.) for their migration path. Do NOT include this in standard migration tooling scope without validating support.
Are there Delve profiles, MySites, or OneDrive for Business content in scope?Medium risk
OneDrive personal sites and MySite host content are a separate migration workstream from SharePoint team sites. Tools and licensing differ. Often forgotten until a user asks where their personal files went.
Are there Teams-connected sites or M365 Groups in scope?Medium risk
Teams-connected SharePoint sites cannot be migrated in isolation — the M365 Group, Teams channels, mailbox, and Planner are all linked. Moving just the SharePoint component breaks the Teams integration. These require a full group migration approach (e.g., using SPMT Groups or third-party tools that handle the full workload).
🔒 Security, compliance & sensitivity
Regulated content, sensitivity labels, and retention policies can stop a migration in its tracks or create legal liability if handled incorrectly.
Are Microsoft Purview sensitivity labels or AIP/Azure Information Protection labels applied to content?High risk
AIP labels (legacy) do not always transfer correctly and can cause access failures in the destination. Sensitivity labels tied to encryption can render files inaccessible if keys aren't present in the target tenant. This is a silent failure mode.
⚠ Encrypted files with AIP or sensitivity labels can become inaccessible during migration. A Purview/compliance team member must be involved in planning. Validate key availability in the target before starting.
Are there active Purview retention policies or holds on SharePoint content?High risk
Retention policies and litigation holds may prevent deletion, modification, or movement of content. Migration tools may skip or fail on held items. Legal/compliance sign-off is required before migrating held content.
⚠ Active retention policies and legal holds are a migration blocker. Compliance team must define how held content is handled. Do not migrate held content without explicit legal/compliance approval.
Is the content subject to regulatory compliance (HIPAA, FINRA, FedRAMP, GDPR, etc.)?High risk
Regulated industries have data residency, audit trail, and chain-of-custody requirements that affect how migration is performed and documented. Some regulations require content never leaves a specific geographic boundary during transit.
Are DLP (Data Loss Prevention) policies active that could block migration traffic?Medium risk
DLP policies that scan content being uploaded to SPO can throttle or block migration jobs, especially for financial data, PII, or health records. These need to be scoped out or temporarily suspended with compliance approval during migration windows.
Is there audit log data, version history, or eDiscovery data that must be preserved?Medium risk
Version history migrates with most tools but has limits (SPO caps at 500 versions per file by default, SPMT caps lower). Audit logs do NOT migrate — they stay in the source. eDiscovery holds require separate handling.
👥 Identity, permissions & access
Permissions are one of the most common post-migration support issues. Understanding the permission model up front is essential.
How are permissions structured — inherited or unique/broken inheritance?High risk
Unique permissions (broken inheritance) at the item or folder level multiply migration complexity exponentially. Tools handle them differently — some skip or flatten permissions. Sites with thousands of unique permissions are among the hardest migrations to execute correctly.
⚠ Highly complex permission structures are a major migration risk. Run a permissions report before scoping. Some tools cannot faithfully replicate item-level permissions — validate tooling capability against actual permission depth.
Are users being migrated to a new domain or UPN during the migration?High risk
If UPNs change (e.g., user@oldcompany.com → user@newcompany.com), all permission mappings break and ownership metadata is lost unless an identity mapping table is provided to the migration tool. This is a T2T migration specific problem that often becomes the critical path.
⚠ UPN changes require an identity mapping CSV that maps source to destination accounts for every user who has contributed to or has permissions on SharePoint. This is often a major pre-work effort requiring HR/IT coordination.
Are SharePoint groups, AD groups, or M365 Groups used for permissions?Medium risk
AD security groups may not exist in the target tenant. M365 groups may need to be pre-created. SharePoint groups migrate but their membership may need to be re-validated in the target.
Are there service accounts or app registrations with SharePoint permissions?Medium risk
Service accounts used by apps, reporting tools, or automated processes need to be re-provisioned in the target with equivalent permissions. Often these are undocumented and only discovered when an app breaks post-migration.
⚙ Customizations & integrations
Custom development and third-party solutions are the most common source of post-migration surprises. Each one needs an individual migration plan.
Are there custom solutions (.wsp farm solutions) deployed to the farm?High risk
Farm solutions are server-side code that cannot migrate to SPO. Full-trust solutions are a hard stop. Each must be re-architected as SPFx extensions or modern apps, or decommissioned. Farm solutions are a key reason migrations from older versions take far longer than expected.
⚠ Farm solutions are a hard stop for cloud migration. Every .wsp must be inventoried, assessed for modern equivalency, and either rebuilt as SPFx or decommissioned. This is high-effort and often requires developer resources outside the migration team.
Are there custom branding / themes (master pages, CSS overrides)?Medium risk
Classic master pages and CSS injection techniques do not work in modern SPO. If the org has significant brand requirements, a modern theme and custom header/footer SPFx extension must be built in the target.
Are there Power Apps or Power Automate flows integrated with SharePoint?Medium risk
Power Platform connections use environment-level connectors tied to specific SharePoint URLs. After migration, every Power App and Power Automate flow must be updated to point to new site URLs. Environment ownership also needs to be verified in the target tenant.
Are there Power BI reports or datasets connected to SharePoint lists or libraries?Medium risk
Power BI reports using SharePoint as a data source will break if the source URL changes. These need to be identified, re-pointed, and re-published after migration. Often maintained by a separate BI team who isn't in the migration communication chain.
Is SharePoint used as a document source for any LOB system (ERP, CRM, contracts, HR)?High risk
LOB systems (SAP, Salesforce, Dynamics, Oracle, etc.) that reference SharePoint document libraries via hardcoded URLs or managed connectors will break silently after migration. These integrations are often undocumented at the SharePoint level and only discovered when the LOB system users report missing documents.
🗓 Project constraints & readiness
Delivery constraints shape how the migration is structured. Hard deadlines and resource gaps are as risky as technical issues.
Is there a hard deadline or business driver for the migration?Schedule risk
Hard deadlines (contract expiry, license cliff, data center decommission) are the #1 cause of migration shortcuts that create long-term problems. Understanding the driver shapes the risk trade-offs conversation.
What is the target timeline or go-live date?Planning
What migration tooling is mandated or preferred?Tooling
Some customers are locked into a tool (BitTitan, Quest, Avepoint, etc.) due to existing contracts. SPMT is free but limited. ShareGate is excellent but per-user licensed. Tool selection significantly impacts cost and capability.
What is the target tenant's current state?Readiness
Migrating into a tenant that isn't configured (no governance, no security baselines, no information architecture) often means migrating into chaos. Target readiness is a hard dependency.
Is there a change freeze, blackout period, or network constraint affecting migration windows?Scheduling
Change Advisory Boards, fiscal year-end freezes, or limited network bandwidth for migration traffic can make night/weekend-only migration windows necessary, dramatically extending overall timeline.
Has the customer's internal team been identified and committed to the project?People risk
The most common project delay cause is customer-side resource unavailability — SharePoint admins who own the source, IT leads who must approve network changes, site owners who must validate post-migration. If they're not committed, the project stalls.
Additional notes / anything the customer mentioned that doesn't fit aboveNotes
📊 Scoping summary
Review your risk flags and get a structured summary you can copy into a SOW or discovery document.