June 5, 2013

Lessons from a Successful SharePoint 2013 Upgrade

SharePoint 2013 is a major new release of the Microsoft enterprise document management and intranet/extranet portal platform that builds upon previous releases in 2007 and 2010.

The latest version of SharePoint introduces new ways to work collaboratively and organize projects with better support for social networking via Yammer ; enhanced mobile and public website support; and more integration with Excel to expand business intelligence reporting.

As a core technology in many organizations, the new release of SharePoint will bring several useful enhancements, but it is also brings complications to implementation.

We recently discussed the challenges of upgrading to SharePoint 2013 with Eric VanRoy, Senior Portal Systems Engineer, with UWEBC member, Skyline Technologies. As an IT consulting and custom technology development firm, Skyline Technologies not only provides Microsoft SharePoint development expertise, but recently upgraded its own corporate intranet from SharePoint 2010 to SharePoint 2013 as well.

“Since we can see our successes and failure much better in hindsight,” VanRoy said, “the lessons we learned from our implementation may help others in planning a successful SharePoint 2013 upgrade.”

1. Determine a destination before you start. Skyline found that it was helpful to actually ignore what they had installed in 2010 and look at what they would do if this was a “green field” installation. The key decisions for Skyline: they would use SQL 2012; all operating systems would be Windows 2012 and they would have an Office Web Application Server.

2. Categorize current customizations into the following: Items that will stop the project; Items that will not stop project but need to be completed; and Items that will be eliminated. Skyline reviewed each customization to see if it was still in use, and if SharePoint 2013 had a better option, how much effort would be required to move to 2013. After categorizing the customizations, Skyline focused on the first category during planning.

3. Recognize environmental changes. For example, by deciding to go to Windows 2012 an environmental change was put in place that needed to be addressed. Windows 2012 has deprecated the SMTP server role. Based on that information, another decision had to be made on whether to do a much more complex configuration using the exchange server directly, or to install the deprecated feature. (Skyline opted for the deprecated SMTP feature).

4. Script all migration steps. According to VanRoy, it does not matter how simple the task seems, use PowerShell to script it. This allows for a very repeatable process ensuring that the dry runs go much smoother and are less error prone.

5. Perform dry runs. “It seems that three dry runs are about the ‘sweet spot,’” says VanRoy. The final dry run should follow the upgrade plan without deviation, or additional undocumented steps.

6. Plan time and space correctly. Based on their dry runs, Skyline identified disk space needs and the upgrade time needed. “The time for SharePoint to mount and upgrade the content database was 13 hours. By adjusting the memory on the SQL server we were able to decrease this down to 7 hours,” said VanRoy, “We only recognized this issue and made adjustments because of the dry runs we had performed.”

7. Test after dry runs. Since the only difference between a dry run and a live run is that the data is not up to date, the end result should be the same as it will be for the live migration. Based on this, using an alternate access mapping, Skyline opened the upgrade to a select group of end users to test, and allows adjustments to be made if needed. “It is much better to find that a user interface component is confusing for 10 people in a test environment, than 100 people,” according to VanRoy.

8. Prepare the destination environment. Prepare and configure as much as possible before the migration. If you can configure the environment prior to the migration, it will make the migration smoother. Preparing a destination environment, allowed Skyline to address problems caused by migration, not the installation, or environmental issue.

9. Define support after go live. “To support the SharePoint 2013 migration, we created an open, recurring Lync meeting and had a person from our team monitor/host it,” said VanRoy, “If an end user had a problem they popped into the Lync meeting.” This method allowed the support staff to quickly view and discuss user issues and reach a resolution quickly.

10. You will have issues. “This is an obvious statement,” said VanRoy, “But how you manage those issues is important.” Define a process for end users to submit issues, a place to track the issues, as well as, how the issues will be triaged and assigned out.