Software Development
TFS 2017 End of Support: Three Paths and How to Choose
TFS 2017 end of support falls on January 12, 2027: Microsoft’s lifecycle page for Team Foundation Server 2017 lists it as the last day of extended support, for installations on Update 3. Microsoft’s mainstream support already ended on January 12, 2022, the same page shows. Under Microsoft’s Fixed Lifecycle Policy, extended support includes security updates. After it ends, security updates come only through Microsoft’s Extended Security Updates program, whose product list does not include Team Foundation Server 2017.
If your team still plans, builds and releases on TFS 2017, the question is not whether to move, but where to and how to get there without stopping the work that runs through it. There are three paths: upgrade in place to the current Azure DevOps Server, move to Azure DevOps Services, or move to GitHub. Which one fits depends on what is inside your installation, so this guide ends with the inventory that decides it and the order that keeps your team shipping while you move.
What TFS 2017 End of Support Means for Your Team
Team Foundation Server is rarely just source control. It holds the work items your team plans in, the build and release definitions that put code into production, the permissions that decide who can approve a release, and years of history. If your team builds and releases from it, every change it ships passes through it.
That is what makes the date matter. Running a system every release depends on, outside Microsoft’s security update programs, is a risk you will have to explain. The larger cost of waiting, though, is that the move gets planned under a deadline, when the path you choose is the one you can finish in time, not the one that fits.
If you run TFS 2018 instead, the clock is later: its Microsoft Learn lifecycle page lists extended support ending on January 12, 2028. Everything below applies to it too.
Three Paths: Upgrade in Place, Azure DevOps Services, or GitHub
| Path | What changes | What stays | The work depends on |
|---|---|---|---|
| Upgrade in place | The version | Your tools, on servers you run | Your version and customizations |
| Azure DevOps Services | Who runs the servers | Boards, Repos and Pipelines | An upgrade first, then history and sign-in |
| GitHub | The tools and the way of working | Your code | Integrations, customizations, history |
Upgrade in place to Azure DevOps Server
You stay on your own servers and move to the current Azure DevOps Server. Its Microsoft Learn lifecycle page lists no fixed retirement date: support depends on keeping it current under Microsoft’s Modern Lifecycle Policy.
This is the smallest change for the people who use it every day: the same family of tools, on servers you run. The trade-off is that your team keeps the job of running it: the servers, SQL Server, and the updates. Under the Modern Lifecycle Policy, staying current is a condition of support, so an installation that fell behind once needs someone who owns keeping it current this time. The upgrade work depends on your version and how far your process customizations stray from the defaults.
It fits when your data has to stay on your own servers, or when integrations that depend on the server would cost more to rebuild than to keep.
Move to Azure DevOps Services
Boards, Repos and Pipelines stay, and Microsoft runs them in its cloud, so nobody on your team patches an Azure DevOps server again. Coming from TFS 2017, this path starts with an upgrade: Microsoft’s migration overview lists updating Azure DevOps Server to one of the two most recent releases as a prerequisite of its Data Migration Tool. After that, the work is moving the history and setting up how people sign in.
It fits when the team is content with Azure DevOps and the problem is running it, not using it. Check early how the parts of your installation that lean on the server itself will carry over: process customizations, server-side extensions, and scripts that call the server directly.
Move to GitHub
A move to GitHub means planning for code, pull requests and pipelines, with GitHub Actions in place of Azure Pipelines. The work depends on your integrations, customizations and history, and on how your team wants to work.
This is two changes at once: a new home and a new way of working. It fits when the rest of your organization already works in GitHub, or when the team wants its workflow to change anyway. Decide early where planning lives after the move: the work items are part of what TFS holds, not only the code.
What to Inventory Before You Choose
The right path falls out of what is in your installation. Before anyone argues for one, write down:
- Version and update level. Microsoft’s extended support date applies to Update 3. Know which update each server runs.
- Collections. How many there are, which ones are active, and which are archives nobody opens.
- Process customizations. Every work item type, field and workflow you changed from the default. Each one gets carried over, mapped to something new, or dropped, on any path.
- Build and release definitions. Which still ship something to production, and what each depends on: build agents, service accounts, scripts on a build server.
- Extensions and integrations. Marketplace extensions, and everything else that talks to TFS: chat, ticketing, reporting, deployment tools.
- History. How much has to stay live and searchable, and how much can stay readable in an archive.
- Sign-in. Who has access today, through which accounts and groups, and how they will sign in afterward.
An inventory like this usually ends the debate. A heavily customized process with server-side integrations points one way; a lightly customized installation with a team that already works in GitHub points another.
How to Sequence the Move Without Stopping Delivery
The goal is a move your users barely notice, not a weekend everyone remembers.
- Inventory, then choose. Pick the path from the inventory, not from a preference, and write down why. Your team will need the reasoning when something does not carry over.
- Rehearse on a copy. Run the upgrade or the import against a copy of your data first, and time it. The rehearsal tells you how long the real cutover window needs to be, and what breaks before it breaks for real.
- Settle the process and pipelines first. Freeze changes to process customizations and pipeline definitions in the run-up to the move. Code keeps moving; the plumbing holds still.
- Move in slices where the path allows. One collection or one team at a time, starting with the one that ships least often, so the first cutover teaches you something without putting a release at risk.
- Cut over between releases. Choose a window that does not sit on top of a release, and keep the old server read-only for a while afterward, so anyone who needs history can still find it.
- Leave room before the date. A cutover planned for the last week has no room for the rehearsal to fail. Plan backward from January 12, 2027, not toward it.
It is the same principle as modernizing legacy systems without a rewrite: change one piece at a time while the rest keeps running. And if the TFS server is one of several Microsoft support dates on your calendar, how to evaluate a .NET modernization partner covers choosing who helps with the application side.
Frequently Asked Questions
When does TFS 2017 support end?
Microsoft’s extended support for Team Foundation Server 2017 ends on January 12, 2027, for installations on Update 3, as its Microsoft Learn lifecycle page lists it. The same Microsoft page shows mainstream support ended on January 12, 2022.
What happens to security updates after TFS 2017 end of support?
Under Microsoft’s Fixed Lifecycle Policy, extended support includes security updates. After it ends, security updates come only through Microsoft’s Extended Security Updates program, whose product list does not include Team Foundation Server 2017.
Should we upgrade TFS, move to Azure DevOps Services, or move to GitHub?
It depends on your customizations, integrations, history and where your team is headed. Upgrading in place keeps the tools and the job of running them; Azure DevOps Services keeps the tools and hands the running to Microsoft; GitHub changes both. An inventory of the installation is what decides it.
We are on TFS 2018. Does this apply to us?
Yes, on a later date. Its Microsoft Learn lifecycle page lists extended support ending on January 12, 2028. The three paths and the inventory are the same.
Where to Start
Start with the inventory. Our Azure DevOps Server assessment inventories your Azure DevOps Server or Team Foundation Server installation (version and update level, collections, process customizations, build and release definitions, and extensions) and recommends one of the three paths, with the work each would take. Clear Function is a Microsoft partner. If you want help carrying out the path it recommends, that is a separate engagement, never a condition of the assessment.
If your team is already stretched across a committed roadmap, the move is one more thing it has to staff. See how we work as an engineering partner for IT teams.
Newsletter
Subscribe to newsletter
Subscribe to receive the latest blog posts to your inbox every week.
