SharePoint Upgrades -- Blueprints Anybody?

Current Rating:
(0 ratings)

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.

Report

Rate Post

You need to log in to rate blog posts. Click here to login.

Add a Comment

You need to log in to post messages. Click here to login.

Comments

Shelly Brown

I led my firms 2007 - 2010 upgrade over the weekend. My surprises were:
1. Visual upgrade - Intended to keep all sites in the 2007 look\feel, but did not catch in testing that any sub-site created from a 2007 look\feel would be in 2010 look\feel. Who knew?
2. Social networking - When people add folks to "My Colleagues" web part on My Sites, it sends an e-mail that users worry is a virus!
3. Site themes - WAY TO MANY choices for an enterprise enviornment. Should have removed all but the default to start!

I'm sure I'll have more lessons learned as we move forward! I have lots of ideas on managing the upgrade project, architecture and end user training as well.
Report
Was this helpful? Yes No
Reply
Marc Solomon

Shelly -- Thanks for the cautionary pointers. Sounds like less is more -- especially when more is overwhelming to begin with.
Report
Was this helpful? Yes No
Reply

This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International