Migrating from SharePoint On-Prem to SharePoint Online? Some Concerns:

Many organizations are currently attempting to make a decision on their role utilizing cloud technologies.  As the technologies have matured, the cloud has become a much more attractive option for companies that want to simplify their footprint around the services they offer to their customers and internal end users.  This has become especially true with SharePoint.  With the 2013 SharePoint release, the overall footprint to host all of the functionality for SharePoint, and maintain redundancy, has helped to accelerate organizations decisions to lower their total ROI around the platform.  SharePoint Online can be an especially attractive option, but there are things to consider when you are ready to migrate from On-Premise to SharePoint Online:

SharePoint Online and SharePoint On-Premise are very different (and very alike)

The gap between what functionality is not available on SharePoint Online is very small.  If I were to show you a default SharePoint 2013 site and a default SharePoint Online site, it would be difficult to point out the differences in functionality.  But with On-premise, developers had a much freer reign to create a more custom experience for the end users, and many of those patterns will not migrate to SharePoint Online easily (even with a 3rd Party migration tool).  Here are few of those:

Custom Solutions

Many organizations leveraged the SharePoint platform in the past to provide much greater functionality and integrate much more tightly with other LOB applications with SharePoint 2007 and SharePoint 2010.  The typically came in the form of custom Full Trust solutions that were deployed into the Global Assembly Cache of the SharePoint Farm.  This provided the application the ability to communicate directly with SharePoint, with very few restrictions.  With SharePoint Online however, custom solution are highly restricted, and your custom Farm solutions will most likely need to be rewritten to support the SharePoint App Model.

Data View Web Parts

Starting with SharePoint 2007, and continuing into SharePoint 2010, it was fairly common practice to implement Data View Web parts to a SharePoint page when you wanted to customize SharePoint, without getting into the morass of managed farm solutions.  While many SharePoint users may not know what a DVWP is, (these could only be added using SharePoint Designer, not the UI) many SharePoint Admins and Developers deployed these to overcome limitations in list view web parts.  However, one of the gotchas of the DVWP, is that they are tied to a list or library using a GUID, instead of a path.  Therefore, if you wanted to migrate all of your pages to SharePoint Online, none of the DVWP’s would have a path to a list or library as the GUID would not exist.  This wouldn’t be a huge problem if you only used these on a couple of pages, but larger organizations may have thousands of these deployed in their environment.

Custom ASPX and HTML pages

With SharePoint Designer, SharePoint developers could also easily create standalone HTML or ASPX pages that did not reside in a list or library.  These loose pages could be designed using a number of web technologies that may not translate properly to SharePoint Online.  This is by design though, in order to protect the entire SharePoint Online platform, the ability to block ‘Malicious’ or ‘rogue’ code is paramount to keeping the service healthy.

Custom Branding

With the changes between branding patterns from SharePoint 2007/2010 to SharePoint 2013, there was already a migration challenge in implementing highly customized Master Pages and CSS.  With SharePoint Online, it becomes even more of a challenge.  As SharePoint Online is accessed through an internet connection, speed and performance become a much greater concern than accessing SharePoint over a LAN.  Having an optimized Branding strategy that conforms to the limitations of using the SharePoint Online platform is very important.

These are only a few concerns that should be considered when making the jump from On-Premise to SharePoint Online.  Having a deep discovery of your environment, or well documented patterns and practices can help ensure the migration will be a smooth experience.

Leave a Reply