TFS2018 to AzureDevops 2019 Upgrade -Part 1

Table of Contents:
TFS2018 to AzureDevops 2019 Upgrade Part 1: Approach (this article)
TFS2018 to AzureDevops 2019 Upgrade Part 2: Create TFS Sandbox
TFS2018 to AzureDevops 2019 Upgrade Part 3: Upgrade sandbox instance to Azure Devops 2019
TFS2018 to AzureDevops 2019 Upgrade Part 4 Upgrade production instance to Azure Devops 2019

The purpose of this article is to describe the process of upgrading TFS infrastructure from TFS 2018.Update2 to Azure Devops 2019. As could be understood from the version number in the previous statement, our setup was on premises and remained so after the upgrade.

Here is additional information on the infrastructure hosting TFS:
TFS application on Windows 2012 Standard Edition
TFS database on Windows 2012R2 on SQL 2016 SP1

Almost all members of our development department used TFS as a source code repository, build and release management (CI/CD pipeline) and work item tracking tool. Hence all stakeholders were informed before the upgrade to TFS infrastructure.

Considering that TFS was (is) so widely used, there was a desire to know a few things prior to the upgrade:
-for how long is the environment unavailable?
-how is the new environment going to react (navigation, look and feel) after the upgrade?
-in case we have to bailout (rollback to current TFS environment) mid-way in the upgrade process, do we have the capability and how?

Except for the last one, the answers to the questions were available only after an upgrade. So, the approach that we were comfortable taking was to create a parallel and standalone TFS (application and database) instance that is identical to (but separate from) production and use that environment as our upgrade candidate. For the sake of clarity, let’s call the standalone instance as TFS sandbox instance. And upgrade that sandbox instance with Azure Devops 2019.
This approach had three benefits:
• the current TFS production setup did not get interrupted and the department continued to work as usual,
• the upgrade process took place on a setup as close to production and so the metrics collected were relatable to an actual production upgrade and
• the department got to navigate/review the new environment before the actual production upgrade and hence has a better idea of what to expect.
To answer the last question (if we have to bailout midway), before proceeding with TFS upgrade we took a snapshot of the application and database servers. That snapshot allowed us to revert in case we had to. After a couple of weeks or so, these snapshots were deleted.

The next set of steps are as follows and since these are quite detailed, I am creating separate notes for them. Click on them to read further:
• standup a parallel TFS instance (sandbox)
• upgrade the sandbox instance
• upgrade TFS production instance