January 21, 2008
Microsoft has extensive documentation available in the TechNet technical library regarding planning and executing migration.
And when I say extensive, I mean extensive. Now I'm going to reveal a dirty little secret about myself: I like to work and play by the 80/20 rule. That means that when I'm presented with a problem, I like to find a solution that is the most effective and efficient, not necessarily the most elegant. Microsoft's documentation provides you with the best practices and most elegant approaches for migrating and moving sites, but honestly, not every scenario demands elegance.
Recently, I've had two clients present me with scenarios regarding SharePoint migration and relocation. In both scenarios, we chose approaches that are not presented by Microsoft documentation, but are completely reasonable nonetheless: moving site items and documents, rather than sites, site collections, web applications, or servers. The bottom line is that we ripped the items out of one server and loaded them onto another. In one case, the goal was to upgrade from WSS v2.0 to WSS v3.0, and in the other case the goal was to move information from one server to another.
As you read this, remember that this "rip and load" approach is effective and efficient in the right scenarios--it's not designed to be elegant! But this route is not "advertised" as much as I think it should be, because it does work and, in some cases, it actually adds value.
How to Do It
The technical procedures we followed were really quite simple. To move a document library, we opened the library in Windows Explorer, copied all the documents and subfolders to a folder on our disk, opened the target document library in Windows Explorer and copied the files to it. The middle step (the local disk) was purely because we decided it would be beneficial to have a file system-based backup of the documents--we could have simply copied directly from one document library to the other. For a list, we exported the list to an Excel worksheet. On the target server, we imported the data as a new list. If the list had custom columns in the source, we created the list on the target then imported the data. See? I told you it wasn't elegant. But it worked! No messing around with prescan.exe, database backup and restore, stsadm.exe, or anything else, really. Just a straight transfer of documents and items.
When to Do It
It worked partially because, in both scenarios, there was no real SharePoint customization. And that leads me to an interesting point. When clients talk to me about upgrading SharePoint, one of the first questions I ask is, obviously, "How much customization have you done?" The word customization is probably not the right word to use because, inevitably, every customer says that they have customized SharePoint. Sometimes what they mean, however, is that they've changed the silly SharePoint logo on default.aspx to their logo, that they've added lists and libraries, and maybe they've added custom columns. Customization in the context of an upgrade or migration, however, really should be called development, or extension: adding new functionality to SharePoint, not just new data. That's when you really have to consider a more elegant approach to migrating or moving a site. If it's just data, you have this quick and dirty option on the table.
There is at least one significant issue that arises when you move or migrate using this "rip and load" approach: You lose a lot of metadata. When you import documents or items into the target site, you're now the creator. Version history and checkout status is lost. Folder and item security permissions are lost (but of course those didn't exist in WSS v2 anyway). You get the picture. But in some scenarios, including the two I faced last week, it didn't matter.
Why to Do It
So why did we opt for "rip and load," this kludgy transfer of data? First, it was faster because second, it required very little preparation and planning. Third, it was low risk. The original server and data was still there, until we ascertained that the change had been made successfully.
Most importantly, moving data this way made us consider the data itself. The "upgrade" scenario presents a great example. The WSS v2 site had been used as a company intranet, hosting announcements, shared corporate documents and photos, and for very limited collaboration. Much of the data was outdated or unnecessary. Pulling it into Excel forced us to take a step back and look at the data and decide what was and wasn't necessary to maintain. It was a quick and useful exercise. And it wasn't just the data that was outdated, it was the structure of the data. What used to be stored in a dozen document libraries by users who didn't know any better, or who were limited by WSSv2's lack of folder- or item-level security, could now be consolidated into one or two document libraries. Lists that had been created and customized (using the word lightly) with additional list columns could be rebuilt in the new server with site-level columns and content types.
The bottom line is, moving the data allowed us to revisit the data, the structure, and the (sometimes outdated) practices that had been used, and to apply newer, better practices. Oh, and a nice side benefit, when the data was loaded into a sparkling new WSSv3 web app, it looked like WSSv3.
Another Unmapped Route
So while we moved the documents and items from one site to another using the "rip-and-load" method (I should trademark that term, huh?), don't forget there is another unmapped route: exporting a library, list or site as a template with content, and loading it into the target location as a new library, list, or site from the template. That approach works really well if you're staying on the same version of SharePoint, and if the library isn't too big. By default, site templates are limited to 10MB (if I recall off the top of my head) but there is a trick, mentioned in a To The SharePoint newsletter last year, to extend the limit using stsadm.exe (search the Web for the keyword "max-template-document-size" for information).
I'm not Ashamed
So we didn't go through days-long, or weeks-long, planning. We didn't do an in-place upgrade, a gradual upgrade, a database migration, or really much of anything except achieve the goal in a very short time. And we didn't lose our entire Sunday.
Got Dirty Little Secrets?
If you have found "dirty little secrets" for working effectively in SharePoint, be sure to come to the Office & SharePoint Pro site and post them as tips!!
