Blogs

You can't hire some guys and a van to move and unpack your MOSS 2007 crates unless you're sticking with MOSS in a new box. Hiring movers in that case makes about as much sense as moving out of your leaky attic down to your moldy basement. But that's one long flight of fancy (and stairs) for climbing out of your familiar MOSS instance and into your next house of information architecture.

For starters anyone who believes the moving guys with the van will know where to move your boxes is pure out-of-the-Microsoft-box rubbish. The queasy return of deja vu? It's settling in from the last upgrade cycle. Call it migrator's remorse.

Let's say you know how to redeploy site collections and navigation structures. The process places your custom metadata and the field properties they adhere to at risk. Even if best practices are plainly obvious (it's not) the migration process is a muddle. Deliver optimal performance around a sprawl of sites and collections? Try nailing down that priority when your permission structures, web-parts and style sheets are flapping in the breeze.

Those delivery guys who hoisted your content database into position on the shiny new RAID 10 server? They disappeared along with your page views. Those aspx pages you slaved over in '08 and '09? They're no longer displaying correctly either.

So how can our SharePoint 2010 migration treat that content database with the respect that our future user experience deserves? Over the next several postings we'll look under the hood and around the cab wheel at the virtual moving vans assembled by the top third-party migration tool vendors.

Our assessments will include some core migration requirements that are foundational to any move. We'll examine some value-added dimensions unique to specific offerings. Finally we'll consider several deal-breakers for putting some serious distance between our SharePoint 2010 purchase orders and the execution of our 2011 migrations.