We have completed a number of migrations recently, including several from SharePoint 2003 to either Office 365 or SharePoint 2016. With such an old platform, one is bound to have challenges and any SharePoint migration requires significant planning and testing to ensure content comes over appropriately.

With SharePoint 2003, there are a few additional quirks due to the original architecture of the platform that we have run into that need some additional planning and testing.

Good Luck with Database Migration

In theory, you can do a straight database migration of your SharePoint 2003 content database to SharePoint 2016. However, there is no direct route – you have to migrate through each version of SharePoint. From 2003 to 2016, these means you need to hop from 2003 to 2007 to 2010 to 2013 to 2016.

In our experience, leveraging a good third party tool such as Metalogix will help because these tools allow for a direct copying from SharePoint 2003 to 2016 with no steps in between. We have used this approach successfully and recommend it for very old versions of SharePoint.

Weird URL Structure

SharePoint 2003 doesn’t have the modern friendly URL structures and site paths that you see in modern web sites or later versions of SharePoint. If you do an inventory of sites, you will see a lot of URLs that are not user friendly such as http://xxx.com/C1/C16 or http://xxx.com/C3/C20. In our experience, these URLs are not even consistently organized hierarchically, e.g. you cannot assume that C1/C16/default.aspx is a subsite of C1/default.aspx.

This will pose a challenge when migrating because it means your sites will need to be remapped as they are copied over – ideally replacing these arbitrary URLs with more friendly ones.

This is also a change management problem because SharePoint 2003 didn’t have any concept of social bookmarks or favourites. End users now likely have bookmarks in their browser or email that will no longer work properly. As these URLs change, you’ll need a communications strategy to ensure that end users can still find their sites.

One Page per Site

SharePoint 2003 didn’t have the WCMS features of future versions such as SharePoint 2007 or 2010. Each site in 2003 is a collaboration site only with one default page per site. In future versions of SharePoint, you can have publishing turned on and enable multiple pages per site.

As a result, you’ll see lots of site proliferation as users created a new site every time they needed a page. When you move to the latest version of SharePoint, you’ll have to make some decisions on how to rationalize all these sites into a simpler site map that can now support multiple pages in a single site.

Invalid Users and Permissions

How many employees in your organization were working there in 2003? When we inventory SharePoint 2003 farms, we find many cases where site permissions are assigned to users who no longer work for the organization. In addition, we find key fields such as Created By or Modified By where the user in SharePoint 2003 doesn’t exist in the new SharePoint 2016 environment.

Using a good third party migration tool, we can remap these users so that we can flag them for further analysis. For example, we can create a user called “Invalid” and map any documents or sites that have invalid permissions to that user so that we can find these documents and update them. We can also provide these tools with mapping so that if in SharePoint 2003 I’m “cwoodill” and in SharePoint 2016 I’m “chriswoodill” we can map the old user permissions to the new account.

Lots of Customizations

SharePoint 2003 was pretty limited, which led to many customizations as users added their own branding, site templates, and views. These customizations included custom site templates, list templates, site definitions, etc. In moving to the latest versions of SharePoint, many of these customizations can be retired or replaced with new techniques and designs.

However, this doesn’t solve the challenge of having thousands of sites which are currently utilizing these customizations and will need to be updated to leverage either new out of the box functionality, migrated customizations or new customizations.

Migrations are Always High Risk

Migrations are always high risk because they involve a significant amount of technical challenges as well as testing requirements. With SharePoint, there are multiple layers in the platform that need to be migrated including settings, permissions, customizations, sites and content. Each of these can require significant testing especially for sites that were heavily customized.

Having migrated several SharePoint implementations in the past 12-18 months, I can attest that migrations are not easy and require significant expertise. If you need help with yours, feel free to contact me and we can share our experience.