Best way to migrate site content into a new SharePoint site

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!

From stackoverflow

• Backup and restore the content DB.

• Cmon, you can do better than that :)

  IrishChieftain : Hey George, I'll post some more details in here this evening. I had to do this recently and need to find my notes. In short, OOTB "content deployment" is not meant for moving entire environments.

• 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:

  http://msdn.microsoft.com/en-us/library/bb428899.aspx

  Anthony :-)

• Hey Anthony, 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 populated into the Authoring environment using Features. So we would need to populate the content separately, i.e. don't want a content db restore to contain those assets.

  Hope that clarifies

• 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?

• xmt15,

  It's just a matter of finding the most appropriate starting point.

  If we deploy to the Authoring environment, that means we need another environment to deploy from - one that has all our features and content already available.

  Because of that, I would rather create the Authoring environment "by hand", and just deploy our actual site content into it.

  I see where you're going with this though, in that case we might as well just author our content manually in the Authoring environment.

  Robert S. : This answer should go into the comments on on @xmt15's post. But I think you lack the rep for that.

  George Durzi : looks like I finally got enough rep to answer in the comments, thanks

• 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.

• 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.

  George Durzi : That's exactly the set up we're going for. When you restored from dev to authoring, what did you do to set up authoring initially?

• I came up with a neat approach that we're now using on our project.

  Check it out at http://blogs.claritycon.com/blogs/george_durzi/archive/2009/01/10/bulk-importing-content-into-a-sharepoint-publishing-site.aspx