Many organizations still use old platforms and they are reluctant to move to new platform with fear of failure in doing the move. But hanging onto older products would not give any benefit as well as it would eventually fail to meet the demands of the modern business and software development requirements. Visual Studio Team System 2005 (TFS 2005) is such old tool, but still people using it for the production work. Let’s have a look at steps taken to move a TFS 2005 as a collection into TFS 2013.3 (again this is not the latest version, but this client demand was to get it to 2013.3), and the thing to keep an eye on to avoid any issues in the move.
Proposed Plan
Upgrade Path
TFS 2005 –> TFS 2010 –> TFS 2013 Move Collection to customer TFS 2013 Instance
Detailed upgrade Steps
TFS 2005 –> TFS 2010
Backup DBs
Restore DB in different server (Windows Server 2008 R2 standard) with SQL 2008 R2 version
Install and Configure TFS 2010 in the Windows Server 2008 R2, as an upgrade
Verify TFS State
TFS 2010 –> TFS 2013
Upgrade Windows Server 2008 R2 to SP1
Backup DBs and snapshot of VM
Upgrade SQL to Customer’s current TFS SQL database version (SQL 2012 SP1)
Install and Configure TFS 2015.3 in the Windows Server 2008 R2 SP1, as an upgrade
Verify TFS State
Bring 2005 Collection to Customer’s TFS 2013
Detach collection from upgraded server
Backup collection database and restore in Customer’s current TFS Database Server
Attach collection to customer’s current TFS
Verify TFS
Server Requirements
Windows Server 2008 R2 standard with SQL 2008 R2 (reporting services native configured),
sufficient hard disk space and minimum 8 GB RAM
Windows Server 2012 R2 standard with SQL 2016 (reporting services native configured),
sufficient hard disk space and minimum 8 GB RAM
Required Software
TFS 2010
TFS 2013.3
SQL 2008 R2
SQL 2012 SP1
Windows Server 2008 R2
Windows Server 2008 R2 SP1
Special Notes
SharePoint related to TFS will not be used for the upgrades as TFS 2018 onward SharePoint
server integration is unsupported.
Execution
- Customer's IT department provided required VMs with required OS and SQL version installed.
- Job started with backing up of TFS 2005 DBs including reporting services DBs, by setting up a master backup plan in SQL 2008 in current TSF 2005 production environment. Followed instructions described in here https://msdn.microsoft.com/en-us/library/ms253070(v=vs.80).aspx.
- Backup of the reporting key taken following instructions in here https://msdn.microsoft.com/en-us/library/ms400729(v=vs.80).aspx
- Reconfigured already native mode configured reporting services in customer provided SQL 2008R2 SP1, instance to use a new DB with different name (ReportServerX and ReportServerXTemp).
- Deleted the ReportServer and ReportServerTemp DBs in the VM and restored them from backup taken from TFS 2005 Database server.
- Restored reporting services key and verified the reporting services have the Team Projects folders etc.
- Restored the backups in a new VM with customer provided SQL instance.
- Turned off the current TFS 2005 environment to prevent anything happening to it.
- Installed TFS 2010 and run the upgrade using restored DBs
- Once upgrade completed after 10-15 hours verified the TFS 2010 instance.
- Stopped TFS 2010 services (TFSServiceControl quiesce) and run SQL back up taken for all databases. More info here.
- Verified SQL version in production TFS 2013.3 instance and identified it is SQL 2012 SP1 standard edition while the intermediate server having SQL 2008 R2 SP1 Enterprise. Now this is a disaster as we cannot restore DBs to standard edition if any enterprise features used in the DBs we have just upgraded to TFS 2010.
- Executed SELECT * FROM sys.dm_db_persisted_sku_features on each of the DB and tfs_coniguration and tfs_collection DBs already using compression enterprise feature.
- Two choices here either to start over by create SQL instance with standard SQL 2008 SP1 or find a way to restore the upgraded DBs in standard version by removing enterprise features.
- To remove enterprise features this link provided instructions, but looks risky as this is not normal DB it is TFS DBs. Further research revealed that it is possible to remove the enterprise features from the TFS DBs by using instructions here.
- Executed
- Backed up DBs and restored them in new SQL instance with standard SQL 2008 SP1. But unfortunately it was not possible to get the reporting services DBs to restore. Luckily client agreed to proceed without reporting DBs as they have not been using it in TFS 2005 and if a demand for reports is there TFS 2013 team project can be added with relevant template TFS reporting services reports by following instruction here.
- Installed TFS 2013.3 in new server having the DBs in standard edition and executed change server IDs commands to make sure it does not interfere with TFS 2010 intermediate instance.
- Run upgrade wizard to with the restored DBs in standard edition SQL 2012 SP1
- Verified the TFS 2013.3 upgraded instance.
- Detached collection from TFS and taken a backup of collection DB.
- Restored collection DB backup in clients production TFS 2013 DB server.
- Attached the collection to production TFS 2013.3 and all is good.
EXEC [dbo].[prc_EnablePrefixCompression] @online = 0, @disable = 1
for each of TFS DB.
Lessons Learnt
- It is important to check all edition + version information in SQL before starting a upgrade process even if the customer has provided the environments.
- Recovering from a disaster has more than one option and your negotiation skills help to convince customer on alternatives
- Customers network restrictions, disk space and CPU/memory issues in servers may drag the upgrade process timeline. So entering into a contract with client on these types of jobs make sure to go with T&M contracts to avoid loosing money on such projects (Luckily this case was done in T&M base).
No comments:
Post a Comment