Share via

Migrating from SharePoint 2010 to O365 in the Real World

  • Article

 

I’m working with a customer who has 7000+ sites hosted in an On-Premise SharePoint 2010 farm.  The farm has about 78 custom WSPs deployed throughout the farm. We 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. 

The following steps were used to evaluate the farm.  These are necessary in the Planning stages to determine what will/can be moved. 

  1. Capture the Inventory of your sites and the Information Architecture. The inventory should capture the following:
    1. List of Web applications
    2. List of Site Collections
    3. List of Sites
    4. List of Features and their Associated Site Collections/Sites (Important for STEP 2)
    5. Size of each site
    6. Last Updated Date for the site items. (Will help identify dead sites)
  2. Capture the inventory of your Solution Packages (WSPs) and download.
  3. Use a tool like SPCAF https://www.spcaf.com/ to evaluate.  SPCAF will provide a report for migration to the cloud and thus the recommendation to use the tool.   (This tool was invaluable in getting the evaluation of the WSPs done in a timely manner. )  We classified each WSP into one of the following buckets, the timelines are based on our teams capacity to convert the items.
    1. Low (2-4 weeks) - Converting simple SharePoint artifacts like web parts, Content Types/Branding to the new model.
    2. Medium (4-6 Weeks) - Solutions with complex deployments/configurations.  This would include things like rewriting a Visual Studio Workflow and or converting Event receivers.  This could also include those solutions with numerous Web parts and other artifacts which need to be converted.
    3. Medium-High (6-10 Weeks) - Solutions which will need some re-architecting and/or alternate configurations due to artifacts and/or services which are deployed directly to the SharePoint server.  An Example here would be a web service which was deployed to the ISAPI folder as this will not be allow in O365  we will need an alternate place for deploying this solution and the ability for the sites leveraging these solutions to access the new deployment location (preferably Azure).
    4. High (10+ Weeks) - These should be full on rewrite which will require some requirements gathering and building of a project backlog.  They will require architecture design of the solution/app and would typically be a large solution/project with multiple components
  4. Once the WSPs are classified we evaluated the Sites from Step 1 and matched those up with the sites which were using the custom features in the WSPs from Step 3.  This gives us a report on which sites contain customizations and which ones do not.  We now have an idea on which sites will be trouble Winking smile
  5. We now needed to determine which sites get migrated first.  We created a set of buckets for Site Classification:
    1. Low – No Customizations Required.  These sites were migrated first. 
    2. Medium – Small customizations which could be completed quickly such as the Low & Medium solutions from Step 3 above.
    3. High – Any customizations which will take some time to migrate.
  6. We them formulated the schedule for migration based on the above information.  We are using a migration tool to do the pushing of the data to O365 as part of our Testing and eventually our Execute stage.

 

SharePoint Artifact Migration Recommendations

Once we had our Inventory we classified each of the custom artifacts with a plan of attack for migrating these items to the Cloud.  Because Solution Packages (WSPs) are not allowed in O365.  These packages and their associated SharePoint Features will need to be broken down and converted to the SharePoint App Model where applicable.  Many of the guidelines for converting these solutions reside as part of the O365 Patterns and Practices recommendations.  Below are he guidelines we used for the various artifacts:

  1. Provisioning/Web Templates/Site Templates – Any web templates and site templates as well as the process for provisioning new sites should leverage the guidelines from the O365 Patterns and Practices team.
  2. Branding & Layout –Contains the deployment of CSS, JavaScript, master pages, page layouts and the associated content types.  The migration of these items should follow the guidance from the O365 Patterns and Practices team.  (https://www.microsoft.com/en-us/download/details.aspx?id=42030)
  3. Workflows  -  Custom workflows created in Visual Studio which use code behind to complete tasks. Workflows which were built with Visual Studio will need to be converted to the SharePoint 2013 declarative workflow model.  These workflows will need to be rebuilt from scratch.
  4. Content Types – These were custom content types which were deployed as a part of a WSP Solution. Content Types should be evaluated to determine if they can reside in a Content Type Hub.  This will provide the content types to all Site Collections subscribing to that hub and provide a safe location for management of the enterprise content types which were previously deployed as WSP solutions. Secondly, Content Types can be deployed using CSOM and the App Model APIs available for use in the O365.
  5. List Templates – custom list templates and in some cases their associated implementations which are deployed as part of a WSP Solution.  List Templates can be deployed via the CSOM APIs and by leveraging the Application model APIs.
  6. Web parts -  Custom web parts which are deployed as WSPs. All Web parts will need to be recreated as SharePoint 2013 App Parts.  This will bring these solutions into the App Model configuration and allow for the deployment of these Web Parts into the Cloud.
  7. InfoPath Forms – InfoPath forms which contained code behind and or required full trust in order to work.  Administrator/Full Trust Info Path forms will should be rewritten as SharePoint Hosted Applications.  This will allow the required flexibility needed for the forms while allowing the use of the form on multiple sites as needed through the SharePoint 2013 App Model.
  8. WCF/Web Services – WCF Services which were deployed to the Web Front End servers which contained calls to the SharePoint APIs.  These services need to be redesigned/built as SharePoint Provider Hosted Apps. 
  9. Web.Config Modifications – Changes to the Web.config on the Web Front Ends which were needed to enable functionality by custom code. These modifications will need to be identified and the associated solutions which required them will need to be refactored into a supported model.  Most likely these solutions will become Provider Hosted Applications for which the required customizations can be made without deploying anything to the SharePoint servers.