This technique was introduced for upgrades from MOSS 2007 to SP2010 and appears to work nicely with SP2013 too.
The STSADM command still exists, creates HTTP 302 redirect output, and enables farm administrators to more easily manage content database attach upgrades for large Web Applications (i.e. multiple terabytes). Considering how content database attach is the only upgrade method for SP2013, the below AAM technique can be a helpful way to gradually upgrade content databases from a SP2010 “source” farm to a SP2013 “destination” farm. Multiple weekends and longer timelines beyond one day upgrades (small Web Applications) are possible with the help of AAM redirection.
Please keep in mind AAM redirect (HTTP 302) is a temporary solution and best used for as short a time as possible. The sooner upgrade is complete, the fewer support tickets we are likely to have. See whitepaper below for how to configure.
Using Alternate Access Mapping (AAM) URL redirection as part of the upgrade process (SharePoint Server 2010) (white paper)
Special Considerations
- Custom Code (DLL/JS) - Hardcoded URLs may fail on the “source” web application when it is given a new AAM and temporary URL.
- InfoPath Forms (XSN) - Hardcoded URLs in data connections, hyperlinks, or code may fail.
- Workflow (XOML) - Hardcoded URLs in email body HTML may fail.
- Incoming Email - While AAM handles HTTP browser traffic, it does not facilitate SMTP (port 25) delivery for inbound email enabled lists and libraries. One possible option here might be the placement of a PowerShell script in Task Scheduler on the “destination” (new SP2013) farm to move old EML files over to the \\sp2010-wfe\c$\inetpub\mailroot\drop\ folder if they are not picked up locally. A time threshold needs to be decided (i.e. 30 minutes) to give the local SP2013 farm enough time to process while not burden users with “missing” email taking too long to appear.
- Local HOSTS File - It may be necessary to enable both the original URL (portal.contoso.com) and temporary URL (portalold.contoso.com) enabled on the “source” (old SP2010) system. This means IIS binding and local HOSTS loopback so that if SharePoint 2010 attempts to open http://portal.contoso.com/ via loopback for one of the above data connections on a site which hasn’t migrated yet it could successfully do so. Even though end user DNS will have “portal.contoso.com” pointed at SP2013, the SP2010 machines may need to loopback locally for “portal.contoso.com” to better accommodate SP2010 sites which haven’t migrated.
Note
- This method is might not be officially supported by Microsoft for SP2010 upgrade to SP2013. However, quick tests in the lab show HTTP 302 redirects can be created and user traffic successfully redirects.
