For the past few months, I’ve been working a lot with SharePoint and PowerShell. I’ve been moving large numbers of site collections between different SharePoint 2007 databases.
I’d like to take some time today to dispel two common misunderstandings about this kind of work which I’ve had to learn the hard way…
DISCLAIMER: ALWAYS, ALWAYS, ALWAYS BACK UP YOUR SOURCE AND DESTINATION DATABASES BEFORE ATTEMPTING COOL MERGECONTENTDBS STUNTS!
Myth 1 – Large Site Collections
I was told over and over that site collections that were larger than 15 GB could not be moved with MergeContentDbs. Although there is a risk of failure when doing so (KB article), the success rate when moving large site collections has been 100% in my experience. We’ve been able to move sites up to the size of 150 GB(!) multiple times without any issue. Don’t ask me why we have a 150GB site to begin with, just note that this can be done successfully.
The T-Rex is a metaphor for a 150GB site collection. Wolverine is a metaphor for me ^^
Myth 2 – PrepareToMove
The command PrepareToMove has traditionally been used to disable profile synchronization before a site is moved between databases. After an infrastructure update back in 2009, Todd Carter wrote a blog post telling developers to stop using the PTM command. The issues caused by the infrastructure update has since been fixed and the SharePoint experts I’ve consulted at Microsoft since recommend the use of PTM, especially when dealing with larger number of sites.
The mythbusting here concerns the documentation of the command on TechNet. According to TechNet, the only way today to enable PTM is by supplying the command with a specific URL to the Site Collection in question.
In our project, where we handled tens of thousand of site collections, the addition of 30-50 seconds per Site Collection due to PTM was not an option. When I studied the command closer, both in PowerShell and on a source code level, I discovered that the command does not need a specific URL in order to set Moving = true. A database reference is just as good. In this way, we were able to cut 300 hours of execution down to less than 300 seconds of execution.