Upgrading SharePoint — What You Need To Know
For anyone with responsibility over a SharePoint environment, upgrading is a fact of life. The three-year release cycle ensures older versions are regularly falling out of support, and shiny new features are often not designed to be backwards compatible. As great as it would be to be able to upgrade at the click of a button, the technical complexity of the platform, coupled with its tendency to become the cornerstone of an organisation’s collaborative capacity, make the process decidedly un-trivial.
Fortunately, with careful planning and forethought, the process needn’t be as daunting as it may first appear. In this article, I’ll outline a number of common considerations that go into planning and executing a major SharePoint upgrade, and in doing so draw on our wealth of experience in helping clients deal with this process.
It goes without saying that each real-world case has its own individual complexities, but knowing how to approach and plan effectively for an upgrade will maximise the probability of success every time.
What’s the Destination?
The first decision to be made is into which version of SharePoint to upgrade; do you make use of SharePoint Online or stick with an on-premises version of SharePoint?
Comparisons of the pros and cons of each have been done before. Suffice to say SharePoint on-premises offers more control over the farm (server architecture, hardware specifications, ability to host custom server-side solutions etc.), but carries more responsibility for internal IT staff regarding patches and security updates. On the other hand SharePoint Online requires relinquishing some of that control to Microsoft, with the benefit of always having access to the latest features and patches without the effort required to apply them.
In keeping with Microsoft’s ongoing focus on the delivery of Software as a Service (SaaS), their main drive appears to be towards the uptake of SharePoint Online. However, the upcoming release of SharePoint 2019 indicates their continuing commitment to on-premises, as does the ability to configure a ‘hybrid’ environment — a SharePoint environment consisting of both an on-premises farm and an online tenancy simultaneously.
Lift and Shift?
An upgrade is a brilliant opportunity to improve the way content is structured and managed within SharePoint. Before migrating data, it’s worth taking a step back to analyse how content is currently managed, and gather feedback from users on what currently works and what doesn’t.
Some aspects to consider are: folder structures (too monolithic or too flat?), permissions management (too strict or too lenient?), and workflows/approval processes (how many automated workflows is too many?). This feedback will inform future content management decisions for the new environment; a crucial consideration since a ‘lift and shift’ migration will almost certainly fall short of maximising the potential collaborative benefits that the new version of SharePoint can offer.
It is true that too much change at once can be disorienting, but a carefully considered change management plan will help to mitigate this.
When planning the new content structure, it’s worth trying to make use of the hierarchical structure SharePoint provides out of the box, as opposed to managing complex structures of nested folders in document libraries. This involves determining whether document libraries/folders as they currently exist could actually become SharePoint sites, and how metadata could be used to segment content in such a way that users no longer need to dig through folders to find what they need. It’s also important to analyse content usage to determine areas where content is never used, or hasn’t been for a long time, and so can be considered for archival/deletion as appropriate.
Governance
Planning for a successful upgrade process is one thing, but ensuring the continued success of SharePoint within an organisation is largely in the governance.
If a SharePoint environment is to maintain its relevancy and ease of use as it grows, there must be clear guidelines in place as to the roles and responsibilities of different individuals and teams in administering the environment and managing content; responsibilities such as site creation, permissions management and content ownership, amongst many others. A robust governance plan also outlines content archival and retention policies, as well as defining a regular review and feedback cycle to assess company-wide usage and any successes and shortcomings.
An official SharePoint working group is often a successful vehicle for defining and enforcing a governance policy, and should consist of a broad cross-section of representatives from across the organisation. Forming such a group at the outset of an upgrade project can be invaluable, as it also constitutes a forum for gathering feedback and providing progress updates, as well as helping to maximise buy-in and shared ownership as early as possible.
It can’t be emphasised strongly enough that, in order to succeed, a collaborative platform needs to be owned by everyone within an organisation; it should never be perceived as being entirely owned and driven by IT.
Change Management
As mentioned earlier, due to its broad scope as a platform, SharePoint has a habit of becoming the foundation upon which an organisation’s collaborative capacity is built (for better or worse!). Changing it, therefore, is likely to be noticed. To minimise the impact of an upgrade, and to ensure SharePoint’s continued adoption, a good change management plan is crucial.
One of the key definers of effective change management is communication. Timescales, plans and any actionable items need to be made clear to end users, without bombarding them with information they’re not interested in. Something we’ve used in the past for this is a project site in SharePoint, which contains key milestones, progress updates; technical documentation, training collateral, downtime windows etc., providing a centralised hub that surfaces the information people need. (A communication site in SharePoint Online can equally be used.) This can be configured with alerts as necessary and, if created in the new version of SharePoint, can be used as a way of familiarising users with the upgraded version ahead of the big switchover.
Another consideration is the need for training. Users already familiar with SharePoint may not need training in how to use it on a day-to-day basis, but changes in the layout of the user interface may necessitate an opportunity for familiarisation — 2010 and 2013 look markedly different from one another, for instance.
It’s also worth considering the different types of training that may be required, e.g., IT Admin training (managing and troubleshooting the farm itself), Power User training (creating sites, setting permissions etc.) or End User training (creating and editing documents). For larger organisations, delivering training directly to all users may not be feasible. In this case, a ‘train the trainer’ approach could be adopted, whereby training is delivered to a subset of key users, who then proliferate the knowledge amongst the rest of the company.
User testing also comes under the umbrella of change management; it’s obviously important to ensure that things continue to work at least as well as before, and in most cases the only people who can confirm this are the end users themselves. Planning when the testing will happen, and who will test each area within SharePoint, is important, as is communicating what is expected and what the deadlines are. It’s also worth considering whether this will take place in a dedicated testing environment or ‘in-place’ in the live environment. Either way, any testing should take place once the first migration of content has taken place.
Environment Configuration
Before any content can be migrated, the new SharePoint environment needs to be set up and configured. This will look different depending on whether you’ve opted for an on-premises farm, an Office 365 tenancy, or a hybrid of the two.
On premises
For an entirely on-premises farm, a sizing exercise will be necessary to determine the appropriate number of servers within the farm, and the roles these should each fulfil. The size and architecture of the farm are largely dependent on the number of end users within the organisation, and how acceptable it is that SharePoint should ever be unavailable. Microsoft provide a number of useful resources to help with determining the farm topology (https://docs.microsoft.com/en-us/sharepoint/technical-reference/technical-diagrams).
It’s worth noting that modern on-premises implementations carry a greater server footprint than older versions have in the past, so it’s unlikely that the same single-server topology that served its purpose previously will be appropriate to host a modern SharePoint farm.
Service accounts will also need to be created in Active Directory, under which the different administrative processes in SharePoint will run (e.g., search crawls, installation/patching, app pools). To minimise the effect of any one service account being compromised, it’s best to have a dedicated service account for each different purpose rather than using one account for everything. Account permissions should also be configured using the principle of least privilege (providing the minimum level of permission needed to fulfil their specific function).
A number of helpful tools exist for actually installing and configuring SharePoint across the multiple servers in the farm, such as AutoSPInstaller and the SharePointDsc PowerShell module. These help turn the process of installing and configuring into a faster and more repeatable process, with less need for constant attention.
At this point, it’s also worth identifying any custom farm solutions in the existing SharePoint farm that will need to be brought across, as these cannot be migrated in the same way that actual content can. Depending on the SharePoint version gap and the customisation particulars, these may need some degree of modification.
SharePoint Online
The process of configuration will look different for an upgrade to SharePoint Online. The key concerns being around acquiring the appropriate Office 365 licenses to enable the right functionality (for instance, E3 licenses and upwards include SharePoint Enterprise features), and considering how the other services within the 365 suite, such as Yammer, Delve or Sway, can integrate and enhance the user experience.
Authentication is also a consideration, as steps will need to be taken to enable synchronisation between an on-premises AD and the cloud-based Azure AD that drives authentication in Office 365. Single sign-on can also be configured at this stage through the use of Active Directory Federation Services.
Hybrid
All of the above applies when configuring a hybrid environment, with some extra steps being needed to set up features such as Hybrid Search and Hybrid Taxonomy. The former allows a full search experience for users, collating content from both on-premises and online, and the latter ensures that metadata for the SharePoint environment is always synced between online and on-premises. It is also possible to share content types between online and on-premises through the configuration of hybrid content types at this stage.
Content Migration
So, you’ve configured the new environment and it’s time to start migrating content. There are two key ways of doing so: a content database upgrade or a targeted content migration.
The database upgrade route involves taking copies of the existing SharePoint content databases and attaching these to the new environment. This is a relatively straightforward process, however it does mean that content will now exist in the new environment exactly as it did in the old, so is more suited to upgrades where the structure of the content is not set to undergo any major changes. It is also only directly possible between contiguous versions of SharePoint, so upgrading from 2010 to 2016 would require an intermediate ‘hop’ via SharePoint 2013, for which a temporary environment would have to be set up. The database upgrade method is also not available when migrating to SharePoint Online.
Targeted content migration involves selecting the specific content to be brought across and only migrating this. This can be time-consuming, however there are a number of tools available for managing the process, such as the OneDrive for Business sync client and the newly introduced Microsoft SharePoint Migration Tool. There are also third-party tools available such as ShareGate, Metalogix Content Matrix and AvePoint, amongst others.
Third-party tools do incur additional licensing costs, but offer a number of time-saving features, are able to handle large quantities of data at high speeds and facilitate the mapping of content into an entirely new structure — they are generally the go-to choice for large-scale content migrations.
A test migration is generally a must for any upgrade project, as this will highlight anything that needs fixing or changing after the migration, and will give an idea as to how long to plan for when migrating the content for real. This also leaves us with an environment that we can make use of for user testing and training; a form of training that can be very beneficial, as it provides a sandbox in which users can acclimatise using the very same content they would normally work with every day. Any changes made at this point will be overwritten with a later live migration, so users can familiarise without fear of breaking anything.
Switchover
And so we arrive: we’ve configured the new environment, migrated content into it, trained our users and had them test it; we’ve got a robust governance plan in place and we’re ready to get going with the upgraded version of SharePoint. The final step in the process — the official switchover from old to new.
In order to plan the switchover, you need to have decided if it will happen all at once or in a phased manner. Phasing the switchover might look like moving one or more departments into the new environment at a time, or might entail running both environments concurrently for a short while so that the old one is still accessible, while encouraging the organisation to make use of the new one.
These approaches have the benefit of making sure that staff can revert to the former should they need to, but equally the presence of the old environment will likely have a negative effect on adoption of the new. One way to mitigate this is to make the old environment read only.
Phasing the switchover by department also increases the number of smaller content migrations that need to be made, as the process of switching each one over will require moving their specific content across.
Whether the switchover is phased or all at once, it will always consist of the following steps: communicating the switchover within the organisation (which will typically include instigating a change freeze while it’s taking place), migrating content afresh so that it’s up to date; smoke testing the new live environment to ensure there are no major usability issues, making any necessary updates to internal DNS and group policy, and making the appropriate communication again once it’s complete.
Once users are up and running on the new version, the old environment can be retired whenever it makes sense to do so.
Looking to the future
At this point we may be tempted to give ourselves a massive, well-deserved pat on the back. And we should do so. And while we’re at it maybe have some cake. However, just because we’ve successfully upgraded doesn’t mean the work is over. In fact, it’s just getting started.
Now is the time to be asking whether we’ve realised the benefits we were expecting from this shiny new version of SharePoint. If so, great, what can we improve on next? If not, what can we do to realise them? The governance plan we defined earlier will be central in driving this continuous improvement, and keeping some form of regular working group going beyond the upgrade itself is a great way of ensuring that SharePoint continues to deliver value for us well into the future.
