There are still many organisations who actively use SharePoint 2007, even 2003, and now is the time to be seriously planning upgrades.
This post is not going to sing the virtues of 2013 (although it is a great product), instead it outlines the ISC approach to upgrades which has been developed over a number of years. There is plenty of technical guidance available, so this post will focus on explaining a pragmatic phased approach to upgrades which I believe works whatever version you are going to and from.
There are seven phases to this approach based on planning, discovering, testing and delivering the upgrade.
- Phase 1 – Upgrade Planning
This phase is about planning the objectives of the upgrade. It is important to define why you are moving to a new version, rather than it being a purely technical upgrade. This phase also should be used to review current functionality what needs to be upgraded and potential areas of complexity.
- Phase 2 – Discovery Upgrade
There are various checks which can be run before an upgrade, but in my opinion the best way to understand the challenges ahead is to run an initial upgrade. There will be problems and functionality which does not work, and the output of this phase is identifying these.
- Phase 3 – Rework and New Functionality
This phase follows directly on from the Discovery Upgrade and its initial focus is on addressing issues discovered in the Discovery Upgrade. There may be ways to address issues, custom functionality may require rewriting or new out of the box functionality may replace a function which previously was customised/developed.
This phase will also incorporate the introduction of any new functionality which will be delivered as part of the upgrade. The primary reason for upgrading to a new version of SharePoint is to take advantage of new functionality, and a sensible amount of new functionality should be introduced during the upgrade to deliver immediate value to the organisation.
In some cases after Phase 2 & 3 a break may occur while organisations take a fresh perspective on the upgrade following the finding of Phase 2 & 3. It may make sense that the upgrade is staggered or content migration path considered.
- Phase 4 – Test Upgrade
Following Phase 2 & 3 a basic set of upgrade and issue resolutions steps should be devised. These steps can then be followed to perform one or more test upgrades to validate the upgrade process, and to understand the timings involved in completing the upgrade. During this phase business users should be actively engaged in the testing, which may reveal issues previously missed by technical testers.
Only once key stakeholders are satisfied with the upgrade process and timings should this phase be completed.
- Phase 5 – Plan for Live Upgrade
This phase is really important and can easily be missed. With a clear understanding of changes as part of the upgrade and time involved a well considered Go Live plan needs to be produced. This could include considering downtime, out of hours working, users training, testing, switch over and fall back.
- Phase 6 – Live Upgrade
This is the actual live upgrade, where the migration to the new version of SharePoint will actually occur. Most likely this will happen out of working hours and will follow the documented instructions which have been produced in the other phases. Experience of previous upgrades suggests a small core team delivers an effective upgrade, and adding extra people will not necessarily delvier a quicker upgrade.
- Phase 7 – Closeout
Once users have switched to the new SharePoint system it is important to consider how the project is closed out, including decommissioning environments, validating necessary backups are in place and archiving documentation.
I hope to develop this blog post into a series of posts and presentation to share at SharePoint community events. Stayed tuned over the next few months as I post experiences using this framework with upgrades to 2013.