Upgrading is very straight forward, improvements were done in .NET 4.6.1 related to the MultisubnetFailover and AlwaysOn. Here is the section from the .NET team this blog post that is relevant for SQL AlwaysOn. The connection string in TFS still sets MultisubnetFailover to true but it is no longer required any longer.
Improve MultisubnetFailover connection behavior for AlwaysOn
The SqlClient now automatically provides faster connection to AlwaysOn Availability Group that was introduced in SQL Server 2012. It transparently detects whether your application is connecting to an AlwaysOn availability group (AG) on different subnet and quickly discovers the current active server and provides connection to the server.
Prior to this release, an application has to set connection string to include “MultisubnetFailover=true” to indicate that it is connecting to AlwaysOn Availability Group. Without turning on the connection keyword, an application might experience a timeout while connecting to AlwaysOn Availability Group.
With this feature an application does not need to set MultisubnetFailover to true anymore. For more information about SqlClient support for AlwaysOn Availability Groups, see SqlClient Support for High Availability, Disaster Recovery.
Make sure you have enough free space for your transaction log, the TFS upgrade is performed in Full Recovery mode, by default with a single instance the database recovery mode is switched to the simple recovery model.
Support for upgrading databases in an AlwaysOn configuration was introduced with TFS 2012 Update 2, you can reference this blog post by the TFS Setup, Administration and Opertaion team.
The post contains some guidelines for the amount of space that you will require but of course a test upgrade would be the best method for determining how much space is actually required for your TFS environment.
The Server Configuration Wizard database screen does not give you any indications that the databases are in an AlwaysOn configuration (see below)
The upgarde may take a bit longer because it is being done in full recovery mode and if your Availability Group is set to use the Synchronous Commits then this could introduce additional latency (slowness).
Be patient and hopefully you already know this because you did a test upgrade before you tackled production🙂
Remember you don’t need an AlwaysOn cluster to upgrade the databases using the Full Recovery Model. You can set the extended property TFS_UPGRADE_IN_FULL_RECOVERY_MODEL = YES on each database you wish to upgrade in this mode.
If your upgrade fails you will need restore your databases from backup and attempt the upgrade again.