Technical personnel usually understand the substantially different set of factors included in a computing platform migration from those associated with individual software solutions. But business stakeholders in the plan should also gain an understanding if plans are to be correctly architected, meaning built in a manner promising success.
SharePoint is a computing platform upon which other applications operate. When SharePoint is looked at from this angle, it is directly comparable with other computing platforms built to support successful efforts at enterprise content management (ECM), enterprise document management (EDM), and even plain Intranet computing. The list of other solutions in this category includes PostNuke, Drupal, Plone, and many others. Perhaps it is even fair to say Office 365 is a next generation of this type of computing platform.
If nothing else, the enormous scale of any plan to migrate from one version of SharePoint, to another must be understood by each of the segments of the migration team, if the plan is to be successfully implemented. This urgency is absolutely mandatory when the migration plan not only calls for a change in computing platforms (for example, from SharePoint 2007 to SharePoint 2010), but also a change in the network architecture underpinning the before and after states. This change in network architecture (and I argue, how applications are actually served, and services consumed) is the case when the migration starts with SharePoint server on-premises, and ends with SharePoint Online, Office 365.
In a very short, but content rich blog post to MSDN, Karim Kameka captures the massive extent of this type of migration. The title of Kameka’s post is Migrating from SharePoint 2010 to O365 in the Real World. In my opinion this blog post should be on the short list of any business stakeholder in a comparable migration plan.
The task Kameka sketches for his readers includes “7000+ sites hosted in an On-Premise SharePoint 2010 farm. The farm has about 78 custom WSPs deployed throughout the farm.” Despite the enormous scale of applications running on this SharePoint 2010 platform “[Kameka and his team] had very little source code from each of the WSPs as this customer was a perfect example of how not to do SharePoint Application development. We had solutions raging from the deployment of custom CSS to others involving web services deployed to the ISAPI folder on the WFEs. Needless to say many recommended practices were not followed.”
It is my hope project stakeholders will carefully consider the ramifications of a decision to make this type of move prior to actually embarking on one after reading Kameka’s post. Further, they may then understand why a decision to implement a hybrid computing scenario in lieu of a complete migration often makes more sense.
©2015, Ira Michael Blonder & Rehmani Consulting, Inc. All Rights Reserved