SharePoint is over 20 years old and so it’s not surprising that various legacy elements continue to float about or get created, even in SharePoint Online.
Legacy elements in SharePoint can be both a blessing and a curse.
- The blessing is that some core elements haven’t changed (or changed much) in a very long time – a site, document library and list, columns for example. There are just now more ‘bells and whistles’ around them.
- The curse comes with those things that were used or added by the organisation or third-party vendors in the past (or even recently), and then removed either by Microsoft or by the organisation as part of upgrades.
Over the years the main legacy elements that can appear in newer SharePoint Online sites and usually need to be fixed, are:
- Classic site templates.
- Legacy site features.
- Old metadata values that remain linked with items even though the choice or managed metadata values have changed.
- Metadata relating to content types that were added then removed from Office documents.
- Legacy permissions, including those that include people who no longer work in the organisation.
Some of these legacy elements may have been used or applied to on-premise SharePoint sites, at a time when customisation (to make sites look better) and complexity (because you could) were taken for granted.
This post explores the five legacy elements described above and approaches to removing or fixing them.
Classic site templates
A ‘classic’ site template is any template that is not one of the standard SharePoint Online templates:
- Modern team sites always linked with a Microsoft 365 Group – GROUP#0
- Modern communication sites – SITEPAGEPUBLISHING#0
I would add STS#3 to the list of modern sites (created from ‘More options’) because it provides the ability to create a modern team site not linked with a Microsoft 365 Group.
To find out what template is being used on any site, right click on the front page of any site, choose ‘View Page Source’ and search for “webTemplateConfiguration”.
There is a handy list of classic site templates on Vlad Catrinescu’s blog post ‘SharePoint Online Site Template ID list for PowerShell‘ dated December 2019.
The simplest way to leave classic legacy sites behind is to create a new modern site and migrate the content (usually only document libraries and lists) to the new site. Avoid migrating content AND structure or trying to upgrade a classic site because both will inevitably leave legacy elements in the background.
I am not convinced that there is any case for deploying classic site templates in SharePoint Online.
Legacy site features
Every new SharePoint Online site comes with a range of Site Collection and Site Features accessed from the Site Settings area.
The following are usually activated on all new sites:
- Site Collection features: Three-state workflow.
- Site Features (screenshot extract above): Following Content; SharePoint Recommendations; Site Notebook; Site Pages; Team Collaboration Lists; Workflow Task Content Type.
Many more features were activated in older versions of SharePoint, especially the SharePoint server and publishing features. These features can be activated automatically if both content AND structure is migrated from SharePoint on-premise sites to SharePoint Online.
The only additional features that I recommend to activate are:
- Site Collection features: Document ID (to give documents unique IDs), as well as Document Sets and Open in Client Application by default, if required.
- Site Features: SharePoint Viewers (so users can see who viewed something).
If you have a SharePoint Online site with any of the other features activated, it might be worth considering creating a new site and migrating the content there to avoid legacy elements causing issues.
Whatever features are activated, it is a good idea to have an agreed and documented approach for these features, based on a good understanding of their purpose.
Old metadata values that are no longer used
This type of legacy issue can happen with any SharePoint site and is surprisingly common.
The issue occurs when a value, from either a choice or managed metadata column is applied to content in a SharePoint list or library, and then the value is changed or removed from the choice or managed metadata options but it is not updated or removed in the library or list.
In the example below, the list of options for the choice column ‘Document Type’ are ‘Agenda’ and ‘Minutes’. If the value ‘Agenda’ has been applied to documents or list items, and is changed to (say) ‘Agendas’ or removed from the choice options, the original value ‘Agenda’ will continue to be applied to the documents or list items. That is, changes to choice or managed metadata values do not auto-apply retrospectively when the changes or removals happen.
This type of issue can cause problems and errors if the content from a library or list is moved to a new location; the legacy value is not recognised because it doesn’t exist any more and so either there is an error or the migration may have multiple errors.
The only way to prevent these errors is to review the list of metadata before moving them. This can be done quite easily, by either (a) filtering the columns and checking the values against pre-defined choice or managed metadata values, then fixing the metadata (removing, changing) before moving the content, or (b) exporting the metadata to a spreadsheet and checking it there first.
Another reason why legacy values can remain in library columns is because a content type with additional columns, that was previously applied to the library, is then removed or hidden (by changing the managing of content types in Library Settings – Advanced settings to ‘No’), leaving the columns and their values behind. This can have an additional unintended consequence as described in the next section.
Legacy content type metadata embedded in Office documents
Content types can be used to apply additional metadata to documents stored in document libraries.
Custom content types are added to individual SharePoint document libraries by enabling the management of content types via Library Settings – Advanced settings, ‘Allow management of content types’.
This setting makes the ‘Content types’ section appear in Library settings:
A new site or global content type (both appear) can then be added to the library.
Assuming the added content type includes additional columns (otherwise, why bother?), those columns will then appear in the list of library columns.
Metadata is then applied to the document. Note the Document ID.
Behind the scenes, this metadata is captured in the XML structure of Microsoft Office documents. For the file above, the metadata is store in two locations in the XML structure:
- The ‘custom.xml’ file contained within the docProps folder (screenshot immediately below)
- The file ‘item4.xml’ contained within the Custom folder, which also contains the Document ID. The file ‘item1.xml’ for this file also contains the full list of drop down options (‘enumeration value’) for ‘Document Type’ and shows that the ‘Date Received’ columns is set to ‘[today]’ as the default. This means the options can be changed directly from the properties of the Office document.
Any Office document that is assigned values in this way will retain those values in the XML structure even when the content type or column is removed. This may have implications when those files are moved to different locations.
Removing a content type
Note that a content type cannot be removed from a library while it is still in use. However, it can be ‘hidden’ if the option to manage content types is changed to ‘No’ in the Advanced settings of the Library Settings. This is not a great way to remove them from use as the columns will still be visible.
Better practice is to remove any values applied to any of the columns, delete the columns, then change the relevant content type from read-only to edit, and delete it.
What happens if documents with metadata are moved to a different location?
If there is a requirement to retain the same metadata when documents are moved from one SharePoint site to another, or even between libraries in the same site, the destination library must have the same metadata columns (and, if there are choices, values) as the source library. Otherwise, metadata will be lost.
But what happens if a document that had metadata previously applied including via a content type is moved to a different location?
The short answer is that, while the Document ID (if enabled) will be retained, the added metadata (from the previous content type) will appear to be lost.
As can be seen in the example below, the ‘moved’ document has the same Document ID but is now missing the original metadata because these were not included in the destination library.
However, the ‘custom.xml’ file contained in the docProps folder of the document in the new location has the same ‘legacy’ metadata contained in the original location, plus additional (and repeating) metadata. This metadata is not visible from the Properties pane.
This hidden legacy metadata has the potential to cause migration issues, or prevent the documents from opening – only allowing them to be ‘saved as’ to a different location.
Saving the document as a new document will (usually) remove that legacy metadata but will result in other core metadata such as ‘date created’ being removed and re-set.
Alternatively, open the ‘Info’ panel of the Office document, click on ‘Check for Issues’, and select ‘Inspect Document’. The ‘Custom XML Data’ section will show if there is any hidden XML. This is another way to remove any legacy metadata (and other potential issues).
Legacy permissions
All new SharePoint sites have the same default permission groups – Owners (full control), Members (add/edit) and Visitors (read only). These permissions should – ideally – remain inherited downwards by all document libraries, folders and items, as well as lists and items.
Permission inheritance will inevitably be modified (inheritance broken) at the library, folder, sub-folder/s and document levels and unique permissions applied.
Ideally, unique permissions set below the site level will be a sub-set of everyone who already has access to the site. Otherwise, whoever needs to access the content will need a link to the library, folder or document. The ‘Share’ option for folders and documents provides this type of link.
Managing legacy permissions
Managing, understanding and unravelling unique permissions can be one of the most time-consuming tasks for any SharePoint administrator or site owner.
Sometimes the easiest approach is to start again and reset all permissions back to the default inherited model. This can sometimes be achieved when content is migrated, as most migration tools (including ‘Move to’) will ask if the original permissions are to be retained or reset.
Undoing unique permissions needs to be done carefully as there may be good reasons for them to be that way. Starting at the site level will provide some idea of the original intention. In addition to the original permission groups, look for:
- Custom permission groups.
- Additional security groups, including mail-enabled security groups (that look like distribution lists).
- Names of people added separately from groups.
- Names of people who have left.
- Shared mailboxes (which do not provide access on their own, but send an invite).
Then start to work downwards. Often the site owner will have some idea of the permission structure, but if they have left and no details were left, the new site owner/s will need to work through the permissions for:
- Library and lists
- Folders
- Sub-folders (etc)
- Documents
One way to document this structure is in a spreadsheet where each row represents the level (site/folder/sub-folder/document/s) and each column represents the group or person and their access.
The existence of complex permissions in a single document library, especially at the folder level, is often a good argument for creating new libraries or sites.
The best way to avoid legacy permission issues and minimise support is to keep permissions simple.
Feature image – Pexels
Records about the world 
One thought on “Managing SharePoint legacy”