Scenario:
I have a client who has a departmental site within their site collection, which is used for document management, and therefore has about 600 MB of documents (I'm guessing). Although the site is already a WSS 3.0 site, it's on a legacy farm. The IT department has spent significant time and money investing in a better MOSS installation, with more complete taxonomies, 3rd party tools, etc. I need to move the site to a different site collection on a different server in a different farm.
Options for Migrating Content:
In general, there are several methods for moving content or site structure from one location to another. I've put together a table describing my options, and whether I thougt it would meet my goals.
|
Central Admin Backup and Restore |
If you use the Central Admin backup and restore screen, you only have the option of backing up an entire content database. In my case, I only wanted one particular subsite within a site collection. |
|
stsadm -o backup |
This does basically the same thing as what you do through the browser in CentralAdmin. Again, I needed just one site, not the whole site collection. |
|
|
From SharePoint Designer, you can choose to backup and restore particular objects as a SharePoint Web Package (an .fwp file, not to be confused with a SharePoint solution package .wsp file.) However, this option would allow me to export the list and library definitions, but not their content. |
|
Site Template
From SharePoint Designer, or within the browser, selecting the "Save Site as Site Template" option.
|
This caused problems because there's a cap on how much content can be saved in a site template.
You can change this with the following stsadm command, however: stsadm -o setproperty -propertyname max-template-document-size -propertyvalue 50000000, with the last number being whatever upper limit you wan to set.
This option would probably work, but I went with the next option.
|
|
Backup and Restore from SharePoint Designer |
The solution I decided to go with was to back up the content from SharePoint Designer using the "Backup Web Site" and "Restore Web Site" options under the Site --> Administration menu.
This option would ensure that I would get all the assets I needed, and would allow me to save the site to the file system, which I could physically move to a location where I could import it into the other site collection, using SharePoint Designer. |
After spending considerable time waiting for the export process to finish, I discovered not one, but about 30 .cmp files had been created, each about 25 MB, and when I tried to run an import against the first file, I got an error saying it couldn't find a file called exportsettings.xml in my TEMP directory.
I finally ran acros
this post by Boris Gomiunik that described how you can modify the size of the .cmp (i.e. CAB file), expanding it so it can contain up to 1024 MB, using the -cabsize switch on the stsadm -o export command.
The key is that it can save UP TO 1024 MB. After trying the stsadm command several times, I was still getting over thirty 25 MB files. I did some more searching and found his follow-up article
here, which points out that the phrase "up to" means you need to use 1023 as your cab size.
Problem solved, right? Well, normally, the export process compresses your files into a nice CAB file with a CMP extension. However, I got an error message saying my computer had run out of memory during the compression process. To get around this, I used the -nofilecompression switch on the export command. When you use this option, you get a folder with the name you specify in the export command, the folder containing the individual exported elements of your site. It worked like a charm.
The follow up to using the -nofilecompression switch is that SharePoint Designer looks for a file with a CMP extension. Since I had used the -nofilecompression switch, I had a folder instead of a file. All this meant is that to import the content into the new site collection, I needed to run the stsadm -o import command (also with the -nofilecompression switch) instead of trying to use SharePoint Designer.
In conclusion, thee's a reason why my Twitter friend
Dan Usher signed me up for an e-mail alias at SharePointDestroyer.com. Hopefully the next version of SharePoint Designer will not be as clunky to work with.