How do I upgrade to SharePoint 2016?
Upgrading a SharePoint environment to the latest version can be a long and complicated process which can get messy if not planned for properly. We advise sharing the risk with a partner unless you have in-house SharePoint expertise. ClearPeople have the right experience, follow a robust methodology, and are happy to be your trusted advisor throughout this journey.
ClearPeople have achieved success in countless SharePoint upgrades and hence have developed our own methodology to streamline the process and reduce risks.
The methodology we follow typically includes the following stages:
- Assessment and Planning
- Testing and Building Proof of Concepts (PoC)
- Content Preparation and Migration
- Adoption and Support
Let’s discuss each stage, highlighting why it is needed and explain the typical scenarios.
What’s the first step?
The first stage is Assessment and Planning. During this stage we will investigate your current SharePoint farm and perform a readiness assessment. On completion we will provide you with a feasibility report which includes our plan of action, a roadmap and any potential risks.
This is when our consultants will collaborate with your main stakeholders to understand how you interact with SharePoint within your business. This typically requires a mixture of business and technical meetings or workshops. Following this, our consultants will run an in-depth assessment to gather all the required information to produce the feasibility report.
During this stage we will ensure that the migration is properly planned, and that all parties clearly know what is required of them. Preparation is a must and is the most important stage for a successful migration. Collaboration and communication is key as together we will make sure that we cover your current system from every possible angle.
During this stage we will assess the feasibility to migrate customisations, third party solutions and other configurations specific to your business. In the feasibility report we will highlight our findings and include recommendations for the next stages.
What relevant documentation will we provide?
The feasibility report includes a breakdown of your current environment and associated recommendations. It outlines a feasible roadmap and potential approaches for your migration while ensuring that we consider your business priorities.
What other optional tasks do we recommend?
The content audit is an optional exercise but one that we would highly recommend, especially if there is a lack of governance or the information architecture has grown organically without controls in place. This exercise will help you review your current content and make decisions regarding which information you need to migrate, and which you would rather leave behind or archive. This is a typical activity that one would opt to go through when moving house, and similarly when moving to a newer version of
It’s common that users feel their system needs improvement. Most of the time it’s about search and making the findability of documents easier and more efficient. At times, fixing this requires an improved underlying information architecture and better organisation of data, not just improving search itself. This exercise is recommended as it’s quite common that clients prefer to sieve through unused documents and spend less effort on migration by migrating useful documents only.
Besides planning and documentation, what else can we do to reduce risks?
The next stage is to create and test a PoC. It’s often the case that as part of the preparation for migration some areas of higher risk need to be tested. The aim is to mitigate risks and highlight limitations in advance. This will also help you to make more informed decisions while finalising the planning stage.
So primarily we will consider key areas highlighted during the assessment stage, build the required Proof of Concepts and test to further confirm the feasibility of our approach.
Depending on the requirements, we could potentially need a deployment of a SharePoint 2016 Farm. At this stage we have a choice of building a throwaway pilot or getting you ready with a development or a User Acceptance Testing (UAT) environment. This ultimately depends on your design requirements.
What’s next once planning is complete?
Once the testing stage is complete and the documentation is amended to reflect the latest findings, the next activity is to build the target environments. This includes both the underlying infrastructure and installation and configuration of SharePoint 2016. We would always recommend having a staging (or UAT) environment as well as a production environment. In the case of Office 365, we would recommend having separate tenants in order to have complete separation of environments since some configuration can be common to multiple sites.
We always advise implementing a UAT environment, especially if you are planning to migrate your systems in a phased approach. This is because you would potentially be building new features on your new UAT while gradually migrating systems from your previous SharePoint environment.
Once the SharePoint 2016 platform is ready, we will deploy any custom solutions and configure the platform to match what you have in your current environment. This is where it can get tricky, especially if work is required to make the custom solutions compliant with SharePoint Online or SharePoint 2016. There are other considerations to keep in mind that could lead to some rework of your solution. For example, wanting the improved features of the later SharePoint version or SharePoint Online such as using Content Search web parts instead of the old and very slow Content Query web parts.
What should we take into consideration while migrating content?
Once the platform, SharePoint and required configuration are all in place, the next task is to prepare scripts to facilitate the actual migration of content. It is usually advisable to script the migration in order to improve reliability, and reduce risk of manual error. This is typically true no matter which technical approach is followed for migration.
From a technical point of view this is where the roadmap can take two distinct paths. The first path involves using a third party tool for migrating the content. The second path involves the Microsoft native supported way of doing a “database attach” migration to upgrade the database schema, then verifying the visual upgrades and approving the upgrade on a site by site basis.
Both paths have benefits depending on the scenarios involved, and when migrating to SharePoint Online only the first option is possible, as the database attach method is not possible with Office 365. This is also true when jumping multiple versions at once. However, here there is the option to implement an intermediate temporary farm and usually the determining factors depend on type of customisations, amount of content and so on. For instance, if your current implementation of SharePoint is completely out of the box, then the recommended and more simple approach would be to use the native database attach method. Obviously, the recommended approach could be a mixture of both methods depending on what there is in each specific web application and site collection.
Additionally, at this point, clients often consider improving their information architecture and opt to invest in redesigning their implementation before migrating. Usually there are a number of factors that lead to this decision. The most typical feedback we hear from end users is that navigating for documents is confusing, or search results are never as expected, and thus there is a clear need to improve the underlying information architecture.
When this is necessary migrating can get a bit complicated as the destination of the documents won’t be just a like for like ‘lift and shift’ but will require specific rules matching the new information architecture. It is very typical that in such scenarios the clients opt to ‘lift and shift’ with a like for like information architecture in a separate site collection, and then move documents gradually at a later phase to the new site collection having the new and improved information architecture. Also keep in mind that at this point you have the option to get rid of old and useless data and migrate only the useful content.
How will we be certain that the migration went well?
This stage often overlaps with the previous stage, and usually happens when the migration is not like for like, or if certain customisation cannot be migrated freely and need some fixes. For instance, there are scenarios where pages would need tidying up due to older components which might not be relevant anymore and thus need to be removed manually or by script after the page is migrated. This is also the case if metadata and default values need to be fixed after migration. It is almost impossible to avoid having to tidy the migrated content.
What is required once the migration is complete?
The last stage, Adoption and Support, is an important one that is not always given enough importance for reasons such as cutting down the cost of a migration. At times this is fine, depending on the in-house skills you have available. However, this is often not the wisest choice and it would often be too late to fix things once you notice the effects of not taking this stage seriously.
Success is determined by a range of factors, which typically include increased system usage, happy and satisfied content editors and improved efficiency of daily tasks. However, simply put, just because all of the data is on the new system it does not mean that all content owners are satisfied, happy and comfortable with the new system. Content owners always take a while to get used to new features that change the ways they do their daily tasks. Hence, very often, until they get used to it, they might easily think that there is something wrong with the system. Concerns typically arise from unexpected changes or users not knowing how to use the new features rather than due to technical faults during the content migration.
With this in mind, you can see that it is crucial for content owners to have the right support when using a new system so that they can get up to speed as quickly as possible, and without the risk of having users lose trust in the new system just because it is a change.