Migration Path
. Only SharePoint 2010 can be upgraded to SharePoint 2013
. There is no “in-place” upgrade for SharePoint 2013
. There is only “database attach” upgrading
. There is no pre-upgrade check for 2010, only Test-SPContentDatase before
attaching
. Site collections can have an upgrade health check run before upgrade
. Upgraded content databases generate an upgrade status report to make sure
upgrade was successful
. Site collections are upgraded individually, and start out, by default in 2010
mode
. A temporary evaluation upgrade (copy) can be created for a site collection to
see if there will be any problems upgrading before doing so permanently
. Services that cannot be migrated
. Search
. Web Analytics
. Usage and Health
. Services that can be migrated
. Business Connectivity Services
Preparing for Migration
. House cleaning
. Visual upgrades
. Orphaned sites
. Large lists with too many columns
. Extraneous document versions
. Site collections that need to be moved to their own content databases
. Decommission PowerPoint broadcast sites and Fast search center
. Remove unused web parts, features, solutions, sites, etc.
. Documentation
. Customizations
. Some might migrate, many won’t
. Create a test environment to check your customizations as part of your prep
. Authentication- convert classic web applications to claims (or plan for it on the 2013 server)
. Site templates may need to be rebuilt (unsupported zones, controls in non-standard places
can cause issues)
. Convert Classic to Claims web applications
. For User Profile- export synchronization key
Documentation
. Some simple tools to gather information about your SharePoint
implementation before migration.
. Stsadm –o enumallwebs –includefeatures –includewebparts –
includeeventreceivers –includecustomlistview >c:\enumallfarm.txt
. PowerShell Script (specifically for SharePoint Foundation, but will work for
Server too): http://technet.microsoft.com/enus/
library/ff645390(v=office.14).aspx
. More thorough powershell script that generates numerous XML files:
http://technet.microsoft.com/en-us/library/ff645391.aspx
. Simple tool that generates hmtl file: http://spsfarmreport.codeplex.com/
. To do file comparison between 2010 server’s 14 hive, and the 2013
server, some simple tools
. WinMerge
. FreeFileSync (portable too)
. WinDiff
. SPDocKit (not free, but a great documentation tool)
Converting Classic to Claims
. Although 2013 can support classic mode authentication, claims based authentication is
the default
. Migration web application databases
. You can upgrade the authentication mode on the web applications from classic to claims on the
2010 prior to migrating (suggested approach)
. To do so:
$webappname = read-host “Enter Web Application URL”
$wa = Get-SPWebApplication $webappname
$wa.UseClaimsAuthentication = $True
$wa.Update()
$account = read-host “Enter PS Policy Account”
$account = (New-SPClaimsPrincipal –Identity $account –IndentityType 1).ToEncodedString()
$zp = $wa.ZonePolicies(“Default”)
$p = $zp.Add($account,”PSPolicy”)
$fc = $wa.PolicyRoles.GetSPecialRole(“FullControl”)
$p.PolicyRoleBindings.Add($fc)
$wa.Update()
$wa.MigrateUsers($True)
$wa.ProvisionGlobally()
. You can migrate content databases from web applications that were using classic mode
authentication to 2013 (not recommended)
. You can migrate content databases from web applications that were classic mode, then upgrade
them on the 2013 server (extra work)
Eight steps to migration
1. Install SharePoint 2013 (don’t forget language
packs)
2. Copy customizations over to the new server
3. Run configuration and configure farm settings
4. Move databases to new SQL Server
5. Migrate Service Applications (that can migrate)
6. Create Web Applications
7. Test and Attach Databases
8. Upgrade site collections
Create Web Applications
. You first need to create a web application to attach the
content databases from the 2010 server
. Make sure all settings and URLs are the same
. You can use PowerShell or Central Administration
. You can remove the database that gets created
automatically
. The migration itself should be done in PowerShell
. To create a claims based web application (example):
$auth = New-SPAuthenticationProvider
New-SPWebApplication –Name “Portal” –ApplicationPool “Portal”
–ApplicationPoolAccount contoso\sp_portalapppool –URL
http://sp1 –AuthenticationProvider $auth
. Pro tip: Do not use convert-spwebapplication
Test and Attach Databases
. SharePoint 2010 does not have a preupgrade
checker, however it does have a cmdlet to test
individual content databases before upgrading
them.
. Test-SPContentDatabase –Name <databasename> –
WebApplication <webapplicationURL>
. If there are errors they are often concerning server side
dependencies or the database is using classic mode
and the new web application uses claims
. Attaching the content database to the web
application will upgrade it.
. Mount-SPContentDatabase –Name <databasename>
–DatabaseServer <sqlsvr> –WebApplication <URL>
. Review database and upgrade status in GUI
Upgrade the Site Collections
. Once the content databases are successfully attached to the new SharePoint
2013 web applications the site collections they contain are not upgraded
automatically
. They are still running as SharePoint 2010 site collections and can be upgraded
individually
. As a site collection administrator
. As a farm administrator
. They can, of course, do mass upgrades
. The easy way to upgrade a site collection or two:
. Use the Banner at the top of the site collection page
. Use the link in the Site Collection Settings page
. Use PowerShell
. Before upgrading
. Run the Site Collection Health Check
. Can Create temporary Evaluation site collection
. Select to create a temporary evaluation site collection (site name appended with –eval)
. Usually lasts 30 days (can be changed)
. DO NOT do work on temporary site- it is not permanent!
On Point with SharePoint 