Migrating from SharePoint to Drupal

SharePoint is Microsoft's web-based Content Management System (CMS) and includes many features, such as collaboration and document sharing. Tightly integrated with Windows, it is commonly used by organisations for their intranet portal. Though sometimes used for public-facing websites, it suffers from a number of limitations, including that it is quite difficult to customise, not to mention expensive.

Drupal, on the other hand, is a leading open-source enterprise-level content management system. It offers a high degree of flexibility and customisation, along with strong security, a robust API system, and many other features. As a result, many organisations are now considering making the switch to Drupal.

Benefits of Migrating to Drupal

1. Cost
   The most obvious benefit of moving from SharePoint to Drupal is the total cost of ownership. As a proprietary system, Microsoft charges annual license fees to use SharePoint - regardless of whether you are using their cloud based SharePoint Online or their on-premise SharePoint Server. Not only that, if you are using SharePoint Server then you also need to pay for the full Microsoft technology stack including SQL Server and Windows Server.
   
   On the other hand, by being open source, Drupal has no licensing fees whatsoever and is platform independent. You can benefit from free upgrades and the large library of freely available extensions that add additional features and capabilities. These factors combine to reduce the total cost of ownership for Drupal, making it very cost effective in the long term.
    
2. Flexibility and customisations
   Drupal is built for customisation, SharePoint less so. To use SharePoint as a CMS requires workarounds and customisations for even the simplest requirements. This is particularly true when it comes to customising the design and layout of the website. Not only is it difficult to customise Sharepoint, but it can be difficult and costly to find experienced SharePoint developers.
   
   In contrast, Drupal was designed more as a CMS framework and built to be extended and adapted. There are thousands of freely available contributed modules that add extra functionality and enable integration with third-party systems, allowing you to build a site that meets your specific business needs.
    
3. Speed of innovation
   Agility and speed to market is a key factor for many businesses, and they need a website they can launch and adapt quickly. SharePoint's inflexibility and customisation difficulties can be a barrier to moving swiftly.
   
   One of Drupal’s main competitive advantages over proprietary CMS vendors, such as SharePoint, is its innate flexibility which enables organisations to get to market faster. Its highly active ecosystem of developers allows for speedy bug fixes and rapid prototyping of new innovative features through custom or contributed extensions. In addition, releases containing new features and capabilities are made of the Drupal core platform every six months.

Migration Challenges

While Drupal offers numerous other benefits making it an attractive proposition, migrating away from a system such as SharePoint can be a challenging task. The larger and more complex the website, the more challenging this task becomes. The prospect of migrating thousands of pieces of content, media assets and users can seem quite daunting. Here are the main ones to watch out for:
 

1. Loss of HTML formatting
   This challenge is very specific to SharePoint. SharePoint allows you to easily export your content to XML or CSV files. However, in the process it converts all of your nice HTML formatting to plain text. Not only that, but all of your embedded images and videos are lost, and links to other pages or sites are removed. This might be a bit painful to edit and add back in for one page, maybe 10, but for 100? 2,000? 15,000? The scale of the task quickly becomes impracticable.
   
   Thankfully there is an alternative. SharePoint also provides a web service API, which allows for a programmatic approach to retrieving all of your content while keeping your HTML in place. 
    
2. Loss of SEO rankings
   When doing any migration, it is important to ensure that you do not adversely affect your site's rankings in Google and other search engines. Should any content change location or URL path during the website redevelopment process, a redirect should be put in place to direct the user, and search engines, to its new location. This will help reduce any negative impact on your site's search engine rankings.
   
   Other factors to consider include ensuring that items such as image alt text and any legacy metatags are migrated over correctly. Lastly, we would recommend that you review your analytics to identify your most valuable legacy pages in terms of traffic, links and backlinks, and pay particular attention to the migration of these pages.
    
3. Technical skillsets required
   If you are already using SharePoint, chances are that your in-house team or external agency are .NET developers and have little to no experience with Drupal and PHP. You may find that you need to hire new Drupal developers or get assistance from an external Drupal specialist digital agency such as ourselves. Drupal training courses should also be considered to retrain in-house staff.

Steps to migrating to Drupal

1. Get organised
   Before attempting any migration, whether it be from SharePoint or an another system, it is important to take stock of where you are. Start by doing a content audit of the website, identifying what content should be kept, what should be removed, and what needs updating. For each page removed you should also identify where visitors to that page should be redirected to after its removal.
   
   For content that is to be retained, it is important to identify where it will live in the new site architecture. If the URL path for the content is changing, then redirects will also need to be put in place pointing to its new location. This will help minimise any potential negative impact on your site's SEO.
    
2. Map your data
   After you have identified the content to be migrated, migration mapping will need to be defined for each type of content being migrated. Here each field, attribute and other properties that make up the content of a page are mapped from the source data structures to the new data structure in Drupal.
   
   We find the creation of spreadsheet, with one sheet for each type of content, very useful. Here you define all the source fields and properties, such as page title, body text, published date, author, etc and map it to its Drupal equivalent. For each we would include the machine names in each system, whether that particular field is to be migrated, if it is a required field, if it is a multi-value field, what data format it is (date, integer, etc) and so on.
   
   We also include some sample record ids or URLs for easy reference. This detailed level of mapping is invaluable later on when performing the actual migration.
    
3. Extract your data to XML or CSV files
   The SharePoint web service API can be utilised to retrieve the content and all of the associated metadata. Some coding skills are required here in order to develop the necessary scripts to automate the extraction of the data to XML or CSV files. We prefer structured XML over CSV, but both are valid options.
    
4. Import the data into Drupal
   Assuming your Drupal site has been built and configured the way you want it, and you're now ready to populate it with the legacy content, you will need to write the necessary import scripts. Drupal core provides the rather excellent Migrate module for this purpose. Here you can codify the mappings from your migration mapping spreadsheet to import the content from the XML files into Drupal. You can also use its API to import any redirects you need put in place.
    
5. Test, test, test
   Once you are confident that you have the migration scripts configured and working, it is important to test them thoroughly. We would suggest migrating a controlled batch of content on the development site first.
   
   The sample content for this controlled batch should be selected so that all types of content are covered, along with all possible data attributes that might be encountered. For example, there may be source data with varying date formats (yyyy-mm-dd, dd/mm/yy), optional fields or a variety of associated media.
   
   Having defined the control content, you can then test your migration and continue adjusting it until all tests have passed.