Best way to migrate site content into a new SharePoint site

4
votes

My team is working on a project to migrate a .com site into SharePoint.

After all our look and feel assets, master pages, content types, and page layouts are created, we need to actually "move" the actual site pages into SharePoint.

I'm trying to come up with the most effective way to do this. Our topology consists of an Authoring and a Production environment. We plan to use SharePoint Content Deployment to populate Production from Authoring.

However, we obviously need to do some sort of initial population of the Authoring environment. I don't want to use Content Deployment to populate Authoring from a development environment because I don't want to initially create Authoring from a Blank Site definition.

Here are the options I came up with, would love some feedback on which you think would be the best approach:

  • Create the site content in a development environment and use a tool such as SPDeploy to migrate it into the Authoring environment

  • Create the content directly in the Authoring environment

  • Use a technique similar to how you can provision List Item instances in a feature. We would create and populate all of our content using Features

    • I'm not sure if this is actually doable, but got the idea because of how I know you can create List Item instances when provisioning a List in a feature. After all, our Pages library is a list of Pages - however there are multiple content types involved.

Thank you for your suggestions!

3
sharepointmigration
George, Can you explain why your "authoring" environment is separate from your "production" environment? My experience is with a Publishing site, where all "author" content would be added via the browser interface. When creating a development VM, I would backup and restore the content DB to get a fresh copy: msdn.microsoft.com/en-us/library/bb428899.aspx – IrishChieftain
We want all content authoring to happen on the intranet, behind the firewall. The "authoring" .com site will live in its own web application on the intranet. We would set up content deployment to populate the Production environment, which lives out in the DMZ. We don't want content authors to directly modify the content in the Production environment. We designed this topology based on guidance from Microsoft for internet publishing sites. The challenge here is how to initially populate the Authoring environment with content, i.e. from our dev environment. All our branding, etc., will be popula – George Durzi

3 Answers

1
votes

If it is just a matter of migrating files, you could actually use the content migration framework. The core classes of this framework are the SPExport and SPImport classes in the Microsoft.SharePoint.Deployment namespace. You can with fairly little code export individual files to disk and import them again to a new location. Alternatively, try the SharePoint Content Deployment Wizard on CodePlex here: http://www.codeplex.com/SPDeploymentWizard. It will save you the coding.

0
votes

Backup and restore the content DB.

0
votes

Can you clarify on why you don't want to use content deployment to create your initial Authoring site? Why do you not want to start with a blank site definition? It would get overwritten in the deployment process anyway. What about stsadm -export / -import?

I'm sorry, but I'm still not clear on the whole situation. You have a development environment (presumably where structure is created, but not any content destined for production), an authoring environment (which I understand as a locked down environment where content is entered and approved), and then a read-only production environment to which approved items are deployed. If this is the case, then I can say that I have a similar setup on one of my projects.

In my case, I initially developed the site structure in my dev environment, then backed up and restored to authoring and prod. Subsequent structural changes to both environments are made by hand. Authoring is structurally almost exactly the same as prod. Only the security is different. Several times per day content is deployed from authoring to prod. We make content changes directly in the authoring environment.