将单个SharePoint 2007网站集拆分为多个并迁移至SharePoint 2016

Hey there, let’s walk through how to split that massive 600GB SharePoint 2007 site collection and migrate it to a well-structured SharePoint 2016 environment. This is a heavy lift, but breaking it into manageable steps will make it doable.

Before touching any migration tools, lay the groundwork to simplify the process:

• Run a full content audit: Map out the site collection’s structure—identify active subsites, archived content, and which document libraries/lists are eating up the most space. Use SharePoint 2007’s built-in usage reports, or use STSADM commands (since 2007 relies on this) like stsadm -o enumsites to pull size stats per subsite. This audit will be your roadmap for splitting.
• Trim redundant content: Delete expired documents, old versions (if not required for compliance), and empty the recycle bins. Even trimming 10-20% of that 600GB will save hours of migration time later.
• Backup everything: Take a full SQL Server backup of the content database, plus a SharePoint site collection backup. You’ll want a safety net if anything goes wrong during splitting.

You’ve got two solid options here, depending on your budget and technical bandwidth:

Option A: Manual Split with STSADM (Free) #

• Export subsites individually: Use the stsadm -o export command to pull out subsites (or groups of subsites) into CMP files. For example:

  stsadm -o export -url http://oldsp2007/rootsite/sales -filename "C:\SPExports\SalesSite.cmp" -includeusersecurity -haltonwarning
  

• Create new site collections in 2007: Spin up blank site collections matching the template of the subsites you’re splitting out. Then import the CMP files with:

  stsadm -o import -url http://oldsp2007/newsalessite -filename "C:\SPExports\SalesSite.cmp" -includeusersecurity
  

• Repeat this until you’ve split the 600GB site into smaller, manageable chunks (aim for 50-100GB per site collection—aligns with SharePoint 2016’s best practices).

Option B: Third-Party Migration Tools (Efficient) #

If you’ve got budget, tools like ShareGate or AvePoint cut down on manual work. They let you split the site collection during migration (no need to mess with STSADM first) and automatically handle dependencies like broken links, list associations, and permission mappings. For 600GB of content, this is often worth the cost to avoid human error and reduce downtime.

Direct migration from 2007 to 2016 isn’t supported, so you’ll need a step-up upgrade:

• First, upgrade to SharePoint 2010: Set up a temporary 2010 environment. Attach your split 2007 content databases using Mount-SPContentDatabase, run the database upgrade wizard, and fix any compatibility issues (check ULS logs or the upgrade report for errors).
• Next, upgrade to SharePoint 2013: Repeat the process—attach the 2010 content databases to a 2013 environment, run the upgrade, and validate all sites load correctly.
• Finally, move to SharePoint 2016: Attach the 2013 databases to your target 2016 farm. First run Test-SPContentDatabase to catch any remaining compatibility issues, then use Mount-SPContentDatabase to complete the upgrade.
• Pro tip: Third-party tools often support skipping intermediate versions, letting you migrate directly from 2007 to 2016 if that’s a priority.

Once everything’s migrated, make sure it’s working as expected:

• Verify permissions: Test user access, document editing, and site-level permissions to ensure they match the original environment.
• Check content integrity: Cross-reference document counts, list items, and test internal links (use SharePoint 2016’s "Site Collection Health Check" or a tool’s link validator to catch broken links).
• Optimize for 2016: Configure distributed caching, set up search crawls, and implement an archiving strategy (move inactive content to a dedicated archive site collection or OneDrive for Business) to keep performance snappy.

• Downtime planning: Manual splits and upgrades will require downtime—schedule this during off-hours. If using third-party tools, leverage incremental migration to move most content first, then only sync changes during a short window.
• Database size limits: SharePoint 2016 recommends content databases stay under 200GB (100GB is ideal for performance). Make sure your split site collections align with this.
• Customizations: If your 2007 site uses custom web parts or workflows, you’ll need to recompile and deploy them to 2016 first. Use Get-SPFeature in 2007 to list custom features, then test them in a staging 2016 environment before migration.

内容的提问来源于stack exchange，提问作者Henry B