As a Jira administrator on the cloud platform, you are probably familiar with the two project types offered by Jira: Team-managed project (previously known as "next-gen project")  and Company-managed project (previously known as "classic project").  

‍

‍

While the core functionality of both project types is the same, there are significant differences that you should consider to determine which type is best suited for your team's needs. 

Team-managed projects are ideal for teams looking to quickly launch and manage projects on their  terms, from start to finish, within a self-contained environment and basic configuration. 

When using team-managed projects, the project manager is authorized  to customize and establish the project configuration that best suits his team's unique requirements. For example, a Project manager can add new screens, fields and develop custom workflows that fit the specific needs of his team.

While team-managed projects provide the benefits of simplified and efficient processes, they may lead to lack of standardization because the team is free to customize it’s project as they see fit, which can result in variances across multiple organizational projects.

Company-managed projects are the best choice for teams who want to work with other groups across many projects in a standard way, while sharing the main schemes like workflows, permissions, fields and more. It can also be a good fit for teams that want to use complex configurations and the more advanced settings and features Jira offers. 

Company-managed projects require Jira admins to configure the schemes and the shared configuration. When a Jira admin changes a scheme or screen, every company-managed project that uses that configuration will change accordingly. Project admins can only execute some of the changes – like managing versions and components and configuring boards. Most of the work – like creating and maintaining schemes and custom fields – is done by Jira admins. Change requests often require collaboration between team members, project admins, and Jira admins.

Choosing the right project type is crucial since switching to another type is impossible once you have selected your preferred project type. If for any reason, you need to change the project type, you’ll have to create a new project, manually transfer all the issues between the projects and resolve the variant mismatch. For example, if you would like to move from a team-managed project to a company-managed project and you created new custom fields, the Jira admin will have to recreate the fields and add them to screen schemes and field configurations in your company-managed project. Custom field data will need to be recreated, otherwise it will be lost.

It can be a complicated and time-consuming task that is generally not recommended. It is, therefore, crucial to comprehensively understand the differences between the project types before deciding which one to choose.

So, what are these differences, and how can you determine which one best fits your team's needs? Let’s review the main differences.

‍

‍

Project creation

By default, all Jira users have the authorization to create team-managed projects. The permission to create these projects is granted globally to the group of Jira users via the "Create team-managed projects" global permission.Jira admins can prevent users from creating team-managed projects by managing which groups are granted this permission.The project creator becomes its first project administrator, allowing him to customize the project according to the team’s specific needs.

The ability to create company-managed projects in Jira is limited to administrators, as this allows for better control over project expansion and settings. By maintaining this control, organizations can ensure that teams working together in a collaborative setting have uniform configurations, including workflows and issue types

‍

Project access and permissions

Team-managed projects have three simple access level options managed by the project administrators: open, limited, and private.

• Open: Anyone on your Jira site can view, create and edit issues in your project. 
• Limited: Anyone on your Jira site can view and comment on issues in your project. But they can't edit them or create new ones. 
• Private: Only Jira admins and people you add to the project, can see it in their project directory or its issues in search results.

In company-managed projects, The projects have a permission scheme managed by Jira admins. Permission schemes allow you to apply customized access levels to combinations of groups, roles, and individuals. For example, the "create issue" permission restricts who can create new issues in the project, or the "Add comments" permission restricts who can add comments to issues in the project. Schemes give the ability to manage complicated permissions requirements.

Jira administrators establish project roles that are universally available across all projects. Project administrators are only authorized to assign members to the pre-existing roles that are applicable to their specific project.

‍

Workflows

In team-managed projects, project administrators are granted with the permissions to manage project-specific workflows, such as statuses, transitions, and workflow rules, which can meet the project's specific requirements. Creating and maintaining these workflows is usually straightforward and offers basic settings,suitable for small teams.

In company-managed projects, Jira administrators map issue types to workflows that come with predefined global statuses and resolutions. These workflows can be further customized with various components such as triggers, conditions, validators, post functions, and properties, all of which are managed by Jira admins.With these powerful capabilities, Jira administrators can create complex workflows per team/s needs.

‍

Custom fields

In team-managed projects, project administrators can create and manage custom fields directly from the issue type. However, the number of available custom field types is limited compared to  company-managed projects. Check the Available custom fields for team-managed projects.

The custom fields that are created within a project are unique to that project and cannot be utilized in any other projects. 

In company-managed projects, Jira administrators are responsible for managing custom fields with contexts for project or issue type. The custom fields are global. Any modifications a Jira administrator makes will impact all projects that utilize that particular custom field.

‍

Boards

In team-managed projects, it is possible to have only a single board per project. This board will contain issues exclusively from that project and you will not be able to access issues from other projects.

Company-managed projects, on the other hand, offer more flexibility in regard to boards. Specifically, it is possible to have multiple boards that span across various projects. Moreover, these boards can display issues from across the entire Jira site, including team-managed projects, provided that the user has the necessary permissions to access them. 

‍

Reports

Team-managed projects offer a limited set of out-of-the-box reports, which include the burnup-report, sprint-burndown-chart, velocity-report, cumulative-flow-diagram, cycle-time-report, and deployment-frequency-report

Company-managed projects, on the other hand, provide a much wider range of report options across various categories, including Agile, DevOps, Issue analysis, and Forecast & management. In total, there are 17 additional reports available for company-managed projects, providing greater flexibility and insight into project performance.

See Reports in Jira to get detailed information about Jira default reports.

‍

Basic Roadmaps / Advanced Roadmaps

Basic roadmaps are a fundamental tool for agile teams, providing a clear overview of their work and its purpose. By displaying a timeline of epics and stories based on their start and due dates, Basic Roadmaps show both the what and the why of the team's current and upcoming tasks. This feature comes built-in with team-managed projects and company-managed projects, making it easily accessible for many users.

When it comes to managing more complex scenarios that involve multiple teams working together towards a shared objective, Advanced Roadmaps provides an array of added functionalities and customization options. Its primary goal is to facilitate collaboration among multiple teams and enable them to keep track of the big picture, identify dependencies, and plan for team capacity across large pieces of work. With Advanced Roadmaps, users can also create customized workflows that are tailored to the specific needs of their teams, which helps them stay on track and achieve their objectives. This feature is available exclusively for company-managed projects that have a premium license support. If you are working with Jira Data Center, however, the Advanced Roadmaps feature is automatically included in your license. In summary, Advanced Roadmaps provides added value and increased project management capabilities, making it an excellent option for teams collaborating on larger and more complex projects.

‍

Appearance of elements

If you add new elements as a Jira administrator to support company-managed projects, it's trivial that all Jira projects and users can see the elements.

If you create a team-managed project and add new elements, such as workflow statuses or issue fields, you may think they are only visible within your project. But this is not the case. Although limited and intended for a single project, configuration elements, such as filters and issue fields, can still be seen outside the project's scope. It can lead to confusion among users and cause unnecessary clutter. As a team-managed project administrator, you should know that new elements you create for your specific team will be visible for all Jira site projects.

As a Jira administrator, consider limiting the creation of new company-managed projects to a specific group to control the number of elements on your site.

‍

Migrate between team-managed and company-managed projects

As mentioned, it's impossible to change project type, and migrating from one project type to another is not recommended, but sometimes you may have a good reason to do so. 

Here are some common reasons to consider doing so:

• The team started quickly with a team-managed project. As the team grows, it needs more customization options that do not exist in team-managed projects, such as advanced permissions or more complex workflows.
• The team started as a small independent team, but after a while, the team needed to collaborate with other teams and use shared boards or link issues between different projects.
• The team currently works with a company-managed project but wants to move to a team-managed project because the project admin needs to make frequent changes to the project's workflow and fields without the dependency on Jira admin.

The migration steps include creating a new project, migrating all issues, and resolving things on the go. Migration between the project types can be complicated and requires the assistance of the Jira admin. For example, you want to move from a team-managed project to a company-managed project, and you have already created new issue types on your team-managed project. In that case, the Jira admin will need to recreate it using an issue-type scheme and associate the scheme with your new company-managed project.

Read this article, Migrate between team-managed and company-managed projects, for more information about the steps needed and the limitations when changing project type.

‍

Conclusion

Choosing the right project type is a crucial decision that requires careful consideration. As a Jira administrator, there are several factors that you should take into account, including standardization, project maintenance, and control of project and element numbers within your Jira site. It's also essential to have a clear understanding of the technical differences between project types so that you can choose the one that best suits your team's needs.

As a project administrator, you need to be aware of your team's requirements and anticipate future scaling and collaboration with other groups. You should also consider the frequency of configuration changes required in the project and whether you have complex requirements. Taking these factors into account will help you choose the project type that will best meet your team's needs and ensure successful project delivery.