CODEWITHSUNDEEP
sql-servertfs
Bill Greer
Bill Greer

Reputation: 3156

TFS Upgrade from 2017 to 2018

I am upgrading my TFS instance from 2017 to 2018. Since TFS 2018 requires SQL Server 2016 I am going to proceed as follows:

  1. Log ship databases to SQL Server 2016
  2. Recover log shipped databases on SQL Server 2016
  3. Copy all Agent Jobs to New Instance (except log shipping jobs)
  4. Turn off SQL Server 2014
  5. Point TFS2017 to new SQL Server instance
  6. Run TFS Upgrade
  7. Delete all databases that have to do with Sharepoint

Are there any obvious flaws in my plan? I already scripted users over and I'm assuming the permissions in the databases won't need consideration because they are copies.

Upvotes: 3

Views: 4252

Answers (2)

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51073

Your steps looks ok. Just a kindly remind, you have to use SQL Server 2016 (minimum SP1) which is the mini version TFS2018 support not SQL Server 2016.

More details please refer Requirements and compatibility--SQL support.

It was a 3 step process usually: Disable old work item form (Not really a step. Just check the box) due to-- Before you upgrade to TFS 2018

  1. Backup and Upgrade SQL to 2016 SP1
  2. Upgrade TFS from TFS 2017 to TFS 2018
  3. Upgrade SQL from 2016 SP1 to SQL 2017 (If need)

Also do a Pre-Production Upgrade Test, a very important feature in the upgrade; since we keep the old name of the server after the upgrade, – we have to change this name immediately in case of a dry run or a trial migration

enter image description here

Besides suggest you also take a look at other tutorials with detail steps and screen shot shows how to do a upgrade to TFS2018, which may be helpful to you:

Finally go through the impact of an upgrade to Team Foundation Server 2018.

Upvotes: 3

M.Ali
M.Ali

Reputation: 69494

Sounds like a decent plan but even a better plan would be to use Powershell DBATools.

Stick with your log shipping method to migrate databases but for everything else (Logins, SQL Agent jobs etc) use PS DBATools. You can also use PS DBATools Log shipping for database migration.

There are many very good reasons to use PS DBATools for migrations a few of them are:

  1. One PS Command does it all for you, no hassle of scripting out things and creating them in the new environment.
  2. Logins maintain their SID during migration.
  3. Copies over pretty much EVERYTHING from source to destination, even things like Alerts, Backup medias, SQL Server - Server level configuration settings( You may need to change this if your new server is more powerful than the old one), Credentials, proxies , Linked Servers etc.
  4. It can help you to setup log shipping and do the cutover for you when planned.
  5. If you do not want to migrate all in one go, you can explore commands to migrate only the things you want to one-by-one or as appropriate.

In short if you are dealing with a side-by-side upgrade of SQL Server, Powershell DBATools is your friend and will take away a lot of your pain, for in-place upgrades its not as useful as it can be.

Upvotes: 1

Related Questions