-1

I am looking to perform a migration upgrade of our TFS 2010 instance to TFS 2013.

Our current implementation has both application and data tiers all residing on a single Windows 2008 R2 Enterprise server.
For this migration upgrade though, each tier will have its own dedicated server.

There are a few salient points I wish to emphasise though, which are:

  1. TFS 2010 Data Tier - This is currently supported by SQL Server 2008 R2 (SP2) Enterprise Edition.

  2. TFS 2013 Data Tier - We'll be supporting this with SQL Server 2012 Enterprise (min. SP1) or 2014.

  3. TFS 2013 App Tier - This will be hosted on a Windows Server 2012 R2.

For the data tier migration, my intention is to obtain backups of the TFS 2010 databases from SQL Server 2008 R2, migrate and restore them to the TFS 2013's data tier which will have SQL Server 2012/2014.

My question therefore is: To perform the TFS 2013 data tier upgrade, should I follow these high-level steps:

1) Install SQL Server 2008 R2 (SP2) Enterprise Edition on the new data tier host.
2) Restore the TFS 2010 database backups to the new data tier.
3) Subject to a successful DB restore, perform an in-place SQL Server upgrade to SQL Server 2012/2014 Enterprise.
4. Install TFS 2013 on the application tier and complete the migration upgrade.

Alternatively, can I simply proceed as follows:

1) Restore the TFS 2010 database backups directly to the new data tier (SQL Server 2012/2014 Enterprise).
2) Install TFS 2013 on the application tier and complete the migration upgrade.

So basically, the question is whether I have to perform the backup and restore on like-for-like SQL Server instances initially, or whether I can restore the SQL Server 2008 R2 Enterprise backups directly to SQL Server 2012/2014 Enterprise?

hitman126
  • 699
  • 1
  • 12
  • 43

1 Answers1

0

Your scenario is a standard upgrade. You can use the new hardware to do a dry run first, and then wipe everything clean and use it again for the production upgrade.

For our dry run, the steps for our upgrade will be:

  1. Copy recent database backups to new SQL instance.
  2. Install TFS2013 on new application tier.
  3. Use scheduled backups to restore the database backups.
  4. Run through the upgrade wizard, being sure to use a service account which does not have any permissions in production environment. See Protecting production in the dry run in pre-production document for more information.
  5. Optionally configure new features which require changes to our existing projects.

Useful links:

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • Dong, are the above recommendations valid for a migration from Windows Server 2008 R2 Enterprise (TFS 2010) to our target server of Windows Server 2012 R2 Enterprise (TFS 2013)? Can we simply take backups of a TFS 2010 instance and restore to a TFS 2013 instance without any compatibility issues? – hitman126 Mar 02 '20 at 15:47
  • It's supposed to work without issue. But I don't have a TFS 2010 environment to test your scenario right now. Please make sure you have a **full** backup database, and you may have a dry run first. – Cece Dong - MSFT Mar 03 '20 at 03:44
  • Dong, for sake of clarity, in Step 1 which you outline in your initial response, i.e. "Copy recent database backups to new SQL instance", do you mind clarifying which specific backups you're referring to? [1] - Are these backup(s) to be taken via the SQL Server backup task or via the TFS 2010 Team Foundation Backups from the TFS Admin Console? [2] - Including the Tfs_Configuration and Tfs_DefaultCollection, we also have a other databases in our collection. Are all of these to be included in the backup and restore to the new server and if not, which ones should be? – hitman126 Mar 03 '20 at 11:21
  • [1] Both scheduled backups and manual backups should work: https://learn.microsoft.com/en-us/azure/devops/server/admin/backup/config-backup-sched-plan?view=tfs-2015. [2] What other database do you have? Check here: https://learn.microsoft.com/en-us/azure/devops/server/admin/backup/backup-db-architecture?view=tfs-2015 – Cece Dong - MSFT Mar 04 '20 at 09:49
  • Dong, the complete list of 7 databases are: ReportServer, ReportServerTempDB, Tfs_Configuration, Tfs_DefaultCollection, WSS_Content, WSS_Content_TeamDevelopment and WSS_ContentTeamLive – hitman126 Mar 04 '20 at 13:50
  • It seems you integrated SharePoint with your TFS. WSS_ are the database for SharePoint, not for TFS. If you don't need SharePoint database, you don't need to migrate them. Please notice, TFS 2018 and later versions no longer support integration with SharePoint. – Cece Dong - MSFT Mar 05 '20 at 08:21
  • That's excellent feedback @CeCe Dong. Thanks for pointing out the database information. You are right, we actually don't intend to have Sharepoint or Reporting Services as part of our TFS implementation, as we've never done so to date. Based on your response, I am assuming therefore that I can exclude the following 4 databases - ReportServer, ReportServerTempDB, WSS_Content, WSS_Content_TeamDevelopment and WSS_ContentTeamLive. I am also assuming therefore that I won't need to backup and restore the Reporting Services Encryption Key from the TFS 2010 instance. Will this be correct? – hitman126 Mar 05 '20 at 11:27
  • Also, as we're not implementing SharePoint or ReportingServices @CeCe Dong, is there a need to run the PrepareClone command at all? The Microsoft support documentation states that: "The PrepareClone command removes information about scheduled backups, SharePoint, and reporting resources from a Team Foundation Server (TFS) deployment". – hitman126 Mar 05 '20 at 11:40
  • Despite restoring only the Tfs_Configuration and Tfs_DefaultCollection databases @CeCe Dong, I'm afraid I am still experiencing the same TF30040 error message. Could this be related to permissions perhaps? I am quite baffled now. – hitman126 Mar 05 '20 at 13:05
  • Yes, you don't need migrate reporting or sharepoint database if you don't need them. I've noticed you have opened a new case regarding TF30040 error. Can you close this case and follow that one? – Cece Dong - MSFT Mar 06 '20 at 04:05
  • The question was whether we can completely ignore running the PrepareClone command, seeing as we're not using SharePoint or Reporting Services as part of our TFS implementation. If you could provide a response to that key question @Cece Dong, would be most appreciated as it would enable us proceed further. – hitman126 Mar 06 '20 at 08:07
  • I have followed case: https://stackoverflow.com/questions/60529624/tf30040-the-database-is-not-correctly-configured-contact-your-team-foundation/60541839. Can we close this one? – Cece Dong - MSFT Mar 06 '20 at 08:35
  • Would be good if I could get some definitive response to my last query before closing the thread @Cece Dong. It will at least bring proper closure to the issue and help others in future, seeing as this particular error appears to be a frequent occurrence. Once again, the question is whether the PrepareClone command can be skipped, seeing as we're not using SharePoint or Reporting Services as part of our TFS implementation? Are you able to provide some feedback on this please, @CeCe? – hitman126 Mar 06 '20 at 14:35