We are frequently asked for guidance on Testing Plans for SharePoint Site Migrations, so have put together this general guidance. While the complexity and nature of migration projects vary massively, and the implications naturally vary with each use-case, we have compiled this list of tests that are generally worthwhile in most migration scenarios. In addition to these tests, any specific custom functionality that has been developed into your site should be thoroughly tested. In all non-trivial migrations, you should expect that some of these tests will identify issues and remediation will be required.
Site Structure Consistency
This is a check of the Site Contents, to ensure that the expected set of SharePoint lists is present in the target site. The item counts should also be verified, and would typically be expected to be the same – although in the cases of system libraries such as Site Assets and Site Pages there may be inconsistencies due to the changing way the site functionality and default user experience is implemented compared to previous versions of SharePoint Server. In such cases, the target site would typically have more items than the source.
This check applies to all sites. In some cases, sites may be split or amalgamated as part of a migration, in which case the check should be that the required subset of lists and libraries are present in the target.
Site / Site Collection Configuration
This check ensures that all the required non-default settings applied at Site or Site Collection level have been appropriately applied. This would include any of the following that may apply:
- Audit Settings
- Search Settings
- Information Management Policies
- Site logo and description
- Site Customisation or Branding e.g. custom Master Pages
This check applies to all sites or site collections where custom settings are applied. Complex sites will require significant checks whereas for smaller or more straightforward ones, this check will be brief.
User Experience Consistency
This is a check that the site behaves in the way expected – that the landing page renders correctly, that it is well-formed and that the basic functionality is either consistent with the source or with any modifications or changes that have been designed or introduced.
This would typically consist of ensuring HTML and Web Parts on the site pages appearing as they should and behaving as they should. While the function of a web page obviously varies considerably, examples would include:
- Simple formatting of the page headers, content, tables, buttons and other layout options
- Any embedded links working and navigating the user to the right place
- Web Parts presenting the correct content, especially if they utilise any search or filter properties or reference external content
- Any forms working correctly, accepting data, presenting value-selection options and drop-downs as they should
- Any workflows triggering accordingly and behaving correctly
- The page responds in a suitably performant manner
This check applies to all sites; however, the extent of the necessary testing often depends on the number of different pages and areas within the site and the complexity of what they do.
List Structure Validity
This is a check of the structure of each list and library within the site. For default site artefacts such as the Site Pages library, and for basic document libraries, this will be a simple check that any non-default settings have been preserved. For custom lists and more complex customised libraries, this will include:
- Check that all list columns and content types are present:
- In complex Information Architectures, this in turn may lead to checks of Site Column and Site Content Type definitions and their settings, and a check that settings all inherit properly from their parent objects
- Check that the column settings, default values, and any calculations or validation are correct and preserved
- Check that any advanced settings in use have been replicated, e.g.:
- Information Management Policies
- Version settings
- Incoming Mail settings
- Metadata settings
- Audience settings
- Check that all Views are present and show the required columns and rows
This test should be performed for all custom lists, or lists with custom settings, or where advanced settings are in use. This will be an extensive process for large and complex lists. But in most cases, it will be straightforward. On default lists with no custom settings it is unnecessary.
List Content Validity
This is the check that the content within each list is valid, accurate, and consistent with the source. This will capture if any items are missing or obsolete. It can also highlight that test data has been left in the target site or that users have been modifying the target content prematurely.
For small lists with only a few columns and less than a hundred items, this can sometimes be done by eye. For larger lists and lists with numerous columns, we recommend a scripted validation process that extracts the data and performs an item-by-item comparison with the source to capture any discrepancies in values.
It is particularly important to verify the modified date for each item so that it is consistent between the source and the target, so to ensure you have the latest version of all items. A modified-by comparison can also be useful; however due to requirements for identity mapping and place-holding of deleted users during migration this is often of limited value. If historical versions of your data must be retained for audit or compliance reasons, verifying the Version count is an important test: migration tools and processes can lose some previous versions on some occasions.
Some migration tools offer this functionality built-in, to some extent. For a stronger or more custom experience, this is typically written in PowerShell; with anomalies reported into a CSV report for human review.
In the case of document libraries, it is also advisable to check that a sample of documents open normally and that none have been left in a checked-out state by your migration process.
The depth to which this test should be carried out depends largely on the importance of the data within the list in question. Where the data represents items in an important business process; such as tickets in a support queue, compliance documentation, overtime claims, or stock inventory; this should be done very thoroughly. More cursory and spot-check -based checks may often be suitable for less important or less sensitive data.
Access and Permissions
This is to check that for each unique permissions set in your site, the appropriate permissions have been successfully migrated. We would also always recommend verification of both the suitability of permissions granted and the necessity for each occurrence of broken permissions inheritance, as part of a data hygiene check prior to or during migration. It is possible to report on broken permissions inheritance and permissions granted by PowerShell script, allowing comparison and verification.
This check should be performed at the root level for all sites. More detailed checks are likely to be necessary where the data is more sensitive and permissions are more fragmented.
Navigation and Links
This check is to ensure that the site navigation is working correctly. This would include both navigation links around the site or site collection itself, but also to any grouped or related sites that may be included in the site navigation.
Links elsewhere from which your users reach your site, where known, such as an Intranet or other corporate directories, other web sites, links automatically added to user Favourites or workstation shortcuts should also be updated.
Any connections to the site from external devices, such as OneDrive Sync client, should also be modified. Any apps that consume data from the site, such as Business Intelligence applications perhaps, should have the URL updated
Finally, most simplistically but also most importantly, the new URL should be communicated to the users; who may navigate to it with a personal Favourite/Shortcut or simply by memory.
This check is applicable to all sites but will have more implications for important sites that are used by a large user community.
Publishing or Promotion/Demotion test
If your site is configured as a Producer or Consumer in a Content Publishing configuration, this should be verified and tested. If any other method of promoting, demoting, synchronising or automatically updating content is in place, this should be thoroughly tested. This is a specific use-case and will not apply to the majority of sites.