Move Site between site collections

on Tuesday, January 26, 2010

How To: Move a single Site between Site Collections


I'm hearing a lot of this question in many variations and I figured it's time to solve it once and for all. The problem is well known: trying to move a WSS Site between 2 different places (such as Site Collections) is still not something we're doing with a click of a button. There is no real and easy of doing so and I've heard about many "nasty" solutions (such as Backup/Restore for entire Site Collection, Copy-Pasting everything with the Explorer View and many other messy evils).

It looks like multiple teams in Microsoft have been tasked with this issue since we actually got 3 different ways to solve it:

  • SharePoint Designer Backup/Restore - Definitely the easiest way to move sites around but only WHEN IT WORKS (since that's not a very consistent feature in SPD). To use this method, simply go to Menu --> Site --> Administration --> Backup Web Site and enter the URL of the WSS site you want to move. You can also include/exclude other subsites in the archive you're creating. Restoring it to the new Site Collection is done with the Restore Web Site feature in SPD. Again, remember this is not too consistent so always try to restore before deleting an original site (Even when you get the "Backup Operation was completed successfully" message!). 
  • Stsadm.exe export/import - The stsadm.exe admin utility is not a new tool but in the 2007 it has many improvements. Now, we can use stsadm as a way to import and export single sites. By the way, this is actually how Share Point Designer creates the archive in the mentioned SPD method. Don't get confused with the backup/restore operations in stsadm.exe - those operations were already available in 2003 but they are used for entire Site Collections rather than a single site (and in our case it's a major overkill). Sounds great huh? Well, just like the SharePoint Designer way, it could easily become a MAJOR NIGHTMARE when it's not working so let me give you some tips. I hope this will reduce the amount of time spent CURSING THE HELL of our beloved stsadm's command line window and the its log file.
  1. The default cabsize value is 25 Mb which is VERY lame for big sites! Always define ur own cabsize (up to 1 GB...)
  2. It is highly recommended to add the “-haltonwarning” or “-haltonfatalerror” parameters. You'll be able to see a list of possible problems before proceeding with the creating on the archive.
  3. If still encounter failures and you don't understand WTF that could be, You might want to try the –nofilecompression switch. Somehow, exports tend to fail in much bigger numbers when you try to compress them.

And to sum it all up, here's the complete command with all of the available switches for exporting/importing with stsadm.exe:

stsadm -o export -url <URL to be exported> -filename <export file name> [-overwrite] [-includeusersecurity] [-haltonwarning] [-haltonfatalerror] [-nologfile] [-versions <1-4> 1= Last major version for files and list items (default), 2= The current version, either the last major or the last minor, 3= Last major and last minor version for files and list items, 4= All versions for files and list items] [-cabsize <integer from 1-1024 megabytes> (default: 25)] [-nofilecompression] [-quiet]

stsadm -o import -url <URL to import to> -filename <import file name> [-includeusersecurity] [-haltonwarning] [-haltonfatalerror] [-nologfile] [-updateversions <1-3> 1= Add new versions to the current file (default), 2= Overwrite the file and all its versions (delete then insert),3= Ignore the file if it exists on the destination] [-nofilecompression] [-quiet]

  • Content Deplyoment - Ok, now we're really talking! Let the real fun begin! This is probably the coolest and by far the most elegant way for synchronizing content between Site Collections. Although this is for a Site Collection level - it's a great way to make a lasting connection and keep moving new content between environments. Before using this method, you need to be familiar with two core conceptual objects: Paths and Jobs. A Path is set of definitions that represents a connection between the source environment and the destination environment. The path contains information about which source web application and site collection you are deploying, authentication information for the destination environment, and the web application and site collection on the destination MOSS. However, a path by itself doesn’t actually deploy any content - it's only a set of definitions. In order to sync the environment, you must create a Job. Each job is associated with a path, and determines exactly which sites in the source site collection will be deployed and on what schedule.

Now the really cool thing about this method: It uses the same logic and internal audit/log files as the Index jobs. That means that you can define a job that only deploys the changes since the last successful deployment and this could for a single item/document level. Great for saving bandwidth and time. Furthermore, if there are no changes since the previous job, the deployment will complete without redoing any unnecessary work. Of course, full deployments every time can be configured if that’s what you really want but this is not necessary in most cases.

    Awesome hug? Although this is for Site Collection level, I think it addresses the main scenario that is main reason for wanting to move a list or a whole site between places: Replication between the Testing environment to the real Production environment. Using this method, you can define it once and deploy testing versions whenever you think you're done playing and it's time to publish your changes. You can find the Content Deployment management interface under the SharePoint Central Administration site. One aspect of content deployment that you should be aware of is that it will only deploy content, not any dependent assemblies/controls/webparts, etc.  Administrator is responsible for moving the assemblies for controls and webparts to the destination farm.

In conclusion - We're dealing here with 2 types of scenarios: If we're talking about moving an entire site ONCE between Site Collections - the SPD and stsadm.exe ways are preferred and you should just use them. If you're talking about synchronization between two environments and it's something that should happen every once in a while - we'll need that lasting connection that is provided through Content Deplyoment.