Visual Studio Team Services and Team Foundation Server (TFS) both provide an integrated, collaborative environment that supports Git, continuous integration, and Agile tools for planning and tracking work.
Team Services is the cloud offering that provides a scalable, reliable, and globally available hosted service. It is backed by a 99.9% SLA, monitored by our 24—7 operations team, and available in local data centers around the world.
Team Foundation Server is the on-premises offering built on a SQL Server backend. Organizations typically choose on-premises TFS when they need their data to stay within your network, or they want access to SharePoint sites and SQL Server reporting services that integrate with TFS data and tools.
While both offerings provide the same essential services, compared with TFS, Team Services provides organizations these added benefits:
- Simplified server management
- Immediate access to the latest and greatest features
- Improved connectivity with remote sites
- A transition from capital expenditures (servers and the like) to operational expenditures (subscriptions).
Use this topic to determine which offering—cloud or on-premises—meets your organizational needs by considering these important areas:
- Fundamental differences between TFS and Team Services
- Differences in specific feature areas between TFS and Team Services
For each area, we'll discuss both the current state of the world and the expected impacts from short and medium-term plans. Check back here for updates, because this information may change frequently.
If you're on TFS and considering moving to Team Services, read Migrate data from TFS to Team Services to understand your options.
Fundamental differences between TFS and Team Services
When you plan a move, there are a few fundamental differences between TFS and Team Services that are important for you to understand.
Scope and scale data
TFS has three options for scoping and scaling data—deployments, team project collections, and team projects. In the simplest case, deployments are just servers. Deployments can also be more complicated, however, including everything from a two-server deployment where SQL is split out on a separate machine to high availability farms comprising lots of servers. Team project collections serve as containers for security and administration in addition to serving as physical database boundaries. They are also used to group related team projects. Finally, team projects are used to encapsulate the assets of individual software projects, including source code, work items, and so on. Learn more about these concepts at Manage team project collections.
Team Services is slightly different. It currently only has two options for scoping and scaling
data—accounts and team projects. Accounts in Team Services get their own URLs (for example,
and always contain exactly one team project collection. Accounts can contain multiple team projects, like
TFS team project collections.
We are planning a third option for scoping and scaling data in Team Services—a new entity called an Organization. Rather than adding support for multiple team project collections within an account, multiple accounts could be grouped within an organization. Additionally, we will merge accounts and their single team project collections into a single entity. The organization will be similar to the TFS deployment, and the account will be similar to the TFS collection.
To be ready to use the organization entity, we recommend that you create accounts in Team Services whenever you would have created collections in TFS. In the short term, having your work split across multiple accounts can cause some problems, but we plan to address these when the organization entity is introduced. In particular:
You purchase Team Services users per account, meaning that paid users only have access to the Team Services account in which the payment is made. If you have users who need access to multiple accounts, Visual Studio subscriptions can be an attractive option, since subscribers can be added to any number of Team Services accounts at no charge. We are also considering other ways we might make access to multiple accounts grouped into an organization available.
You currently have to administer accounts one at a time, which can be cumbersome when you have many accounts. We're working to support organization-wide policies.
With TFS, you typically connect to an intranet server (for example,
You authenticate with Windows Authentication and your Active Directory (AD) domain credentials. Usually this
process is transparent, and you'll never see any kind of sign-in experience.
With Team Services, you connect over the public internet (for example,
https://contoso.visualstudio.com). You'll either
authenticate with Microsoft Account credentials or with
Azure Active Directory (Azure AD) account
credentials, depending on your Team Services account setup. You can also set up Azure AD
to require features like multi-factor-authentication, IP address restrictions, and so on.
We recommend that organizations configure their Team Services accounts to use Azure AD rather than Microsoft Accounts. This provides a better experience in many scenarios and more options for enhanced security.
Users and groups
In TFS, you provide users access to deployments by adding Active Directory (AD) groups to various TFS groups (for example the Project Contributors group for an individual team project). The AD group memberships are kept in sync. As users are added and removed in AD they also gain and lose access to TFS.
In Team Services, you can use a similar mechanism to provide access to groups of users by adding Azure AD groups to TFS groups. If you use Microsoft Accounts instead of Azure AD, you will have to add users one at a time.
Manage user access
In TFS and Team Services, you can give free access to work item features to an unlimited number of Stakeholders. Also, unlimited Visual Studio subscribers can have access to all Basic features at no additional charge. You only need to pay for other users who need access.
In TFS, all use is on the honor system. To set access levels for users based on their licenses, use specify their access levels administration page. For example, assign unlicensed users Stakeholder access only. Users with a TFS Client Access License (CAL) can have Basic access. Visual Studio subscribers can have either Basic or Advanced access, based on their subscriptions. Note that TFS does not attempt to verify these licenses or enforce compliance.
In Team Services, you must assign an access level to each user in your account's Users hub. Team Services validates Visual Studio subscribers as they sign in. You can assign Basic access for free to five users without Visual Studio subscriptions. To give Basic access to more users, you'll need to set up billing for your account and pay for more users. Otherwise, all other users get Stakeholder access.
If you use Azure AD groups to provide access to groups of users, Team Services will assign appropriate access levels to them automatically when they sign in for the first time. For Team Services accounts configured to use Microsoft Accounts for sign-in, you will have to assign access levels to each user explicitly.
Security and data protection
Many organizations want to know more about data protection when they consider moving to the cloud. Microsoft is committed to ensuring that Team Services projects stay safe and secure. We have technical features and business processes in place to deliver on that commitment. You can also take steps to secure your data. Learn more in our Data Protection Overview whitepaper.
Key feature differences between Team Services and TFS
Even though Team Services is a hosted version of TFS, there are some differences between the features available in the two products. Some TFS features are not supported in Team Services at all—for example, Team Services does not support integration with SharePoint or Project Server.
You customize the work tracking experience in two different ways depending on the supported process model:
- For Team Services, you use the Inheritance process model which supports WYSIWYG customization
- For TFS, you use the On-premises XMLprocess model which supports customization through import/export of XML definition files for work tracking objects
While the On-premises XML process model option is quite powerful, it also can cause a number of problems. Chief among these is that processes for existing team projects do not update automatically when TFS is upgraded.
For example, TFS 2013 introduced several new features which depended on new work item types and other process template changes. When you upgrade from TFS 2012 to TFS 2013, each team project collection gets new versions of each of the "in the box" process templates which include these changes. However, these changes are not automatically incorporated in existing team projects. Instead, after you finish upgrading you have to include them in each team project by using the Configure Features wizard or a more manual process.
To avoid these issues in Team Services, custom process templates and witadmin.exe have always been disabled (only export functions are enabled). This has enabled us to automatically update all team projects with each Team Services upgrade. Meanwhile, the product team has been working hard to make customizing processes possible in ways that we can support easily and continuously. These first of these changes was recently introduced, and more changes are on the way.
With these new Team Services process customization capabilities, you can make customizations directly within the Team Services Web UI. If you want to customize your processes programmatically, you can also make customizations through REST endpoints. When you customize team projects in this way, those projects will continue to update automatically when we release new versions of their base processes with Team Services updgrades.
To learn more, see Customize your work tracking experience.
Over time we will support more and more types of process customizations with this new approach. If you need process customization features which are not yet available and cannot wait for them, a second option for process customization in Team Services is available, referred to as Hosted XML process model, and in private preview and by request only.
With this option, you import customized process templates. This option is quite similar to using custom process templates in TFS, except that:
Restrictions exist in the customizations that can be imported into Team Services.
Process templates are associated with all team projects created from them, and changes made to the process are reflected in each team project.
Team projects in accounts which participate in this process customization private preview will not update automatically with Team Services upgrades.
Both TFS and Team Services have a variety of tools to give you insight into the progress as well as the quality of your software projects. These include:
- Dashboards and lightweight charts, available in both TFS and Team Services. These are very easy to set up and use, but are also fairly limited in what they can do.
The following reports and dashboards—which are more complicated to use, but also more powerful—are only available in TFS:
And, available today only in Team Services:
- A PowerBI connector which provides a nice combination of simplicity and power. We plan to make it available in TFS in a future release.