Blogs

I have a piece out this week in KMWorld where I interview John Mongell, an IT consultant with Boston-based RSM McGladrey and well acquainted with the initial tire-kicking and eventual blocking/tackling connected to SharePoint deployments.

In it Mongell espouses the major steps forward in the new release. But then retraces those steps with the sobering news that no one's ready to parade those footprints out in public. The pre-release code to marquee Microsoft shops has been available for close to a year. Yet try Googling "SharePoint 2010" "case studies" and you get a lot of channel fluff -- no hard tangibles. No enterprise references.

Perhaps that's at least part of the lengthier explanation why no one is selling any primers or macros, or project management planning tools that attack the particulars of this upgrade cycle.

The question is fair game for implementers great and small whether taking the leap from 2003, MOSS, or diving off the deep-end of the first-timer pool.

I know what you're saying. There's a ton of blogosphere stuff on tools and features. There's even some hard, tangible directionals on configuring servers (64 bit or bust), application upgrade paths (nothing less than SQL 2008 please) and compliance with upgrade requirements (gotta run those pre-upgrade checks to ensnare those database orphans)! But when you get to the heart of the application, (a.k.a. the user experience?) the chatter runs silent.

Can you imagine a world where the complexities of satisfying these new hardware and software requirements was lumped together as one stream of work? Well, anything that falls below that line is referred to in this high-level IT-centric roadmap as "content database." Even worse, any tweaking done in a prior version -- even with the out-of-the-box toolset is relegated to the gray area of customization.

In the upgrade cycle, customization is where past investments go to die. Fair enough. But when those tweaks are as basic as which columns turn up in a View and what properties those columns contain ... well that's about as basic a design decision as it is critical to the day-to-day functioning of a healthy SharePoint enterprise.

Or how about the themes and masterpages established in the prior version? Beam it up to 2010 in one grunting database jerk-and-lift and your transporter device has Spocks ears sticking out of Kirk's eye sockets. It's a not so special effect guaranteed to underestimate a lot of post deployment cost and pain.

Does anyone have a pre and/or post migration map on the level we're addressing here? Feel free to teleport to the SharePoint manager practioners among us.