Last week I had the opportunity to attend an event that AvePoint held in the Netherlands with Ordina, which covered migration and governance in SharePoint 2010. The workshop also included a presentation on SharePoint Governance, led by Dan Holme, Microsoft SharePoint MVP and AvePoint’s Chief SharePoint Evangelist. I took the valuable takeaways from the workshop into a subsequent partner discussion afterward concerning a migration to SharePoint 2010.
During the discussion, the partner asked me the value of AvePoint’s migration products in relation to SharePoint’s native upgrade functionality. It’s easy to want to immediately dive into a feature-by-feature argument. However, virtually anyone who has ever bought a software tool knows that if the seller immediately goes into the features argument, the buyer closes and the deal is gone. It’s important to instead frame the conversation in terms of the specific business and technical problems facing the customer, and explaining how our solution fits into addressing those needs.
First, let’s just look at the word “upgrade” versus “migration”. To me, these two are totally different. In my experience, an upgrade essentially means, “I don’t want to change the way the business works with the solution.” The upgrade is a technical approach to solve technical issues. In the case of an upgrade from Microsoft Office SharePoint Server (MOSS) 2007 to SharePoint 2010, I want 64-bit versions of Microsoft SQL Server. So an upgrade can be feasible, and this will be driven completely by IT.
But then looking back on my project management training, one central question comes to mind: Why do you start a project? A project will be started because there is an itch, a pain that business or IT wants to cure. When it comes to moving onto SharePoint 2010, it usually means the business wants to take advantage of new features in SharePoint 2010 that aren’t available in MOSS 2007. It also means that in moving to a new software platform, they may want to rethink the way they have structured its information architecture in order to satisfy evolving, changing business needs. In my experience, a restructure is not something the upgrade will do for you. To me that is the main difference between a migration and an upgrade.
And as Dan constantly highlighted during his presentation, in order for a well-governed deployment, you must ensure that the structure follows and enables SharePoint usage. So, if you want to use new functionality in SharePoint 2010, most likely your MOSS 2007 structure is no longer valid. So in most of the projects where we do an upgrade, a migration would likely be a better fit. I’ve found that this is very easily understood when the conversation is about migrating from another legacy enterprise content management system, such as Lotus Notes, EMC Documentum, or Oracle Stellent, to SharePoint 2010. However, I’d argue that in many cases it should be the same when you want to move from a prior release of SharePoint to SharePoint 2010.
It’s easy to launch into a laundry list of features, but it’s important to avoid that and instead frame the conversation in terms of the actual business need at hand. It completely changes the perception of the true value of our migration solution, and gives the potential customer an even better chance of success in their migration project.