50-field limit in Team-Managed project

Question

We’re currently running into the 50 custom field limit when building schedules in a Team-Managed Jira project, and it’s starting to impact how we structure and manage our work.

We’re exploring whether moving this project to a Company-Managed project would help remove or alleviate this limitation.

Before making that change, we’d love to better understand:

* Does switching to Company-Managed remove the 50-field limit entirely, or are there other limits we should be aware of?

* What trade-offs or constraints should we consider when moving from Team-Managed → Company-Managed?

* What is the recommended migration approach, given that there doesn’t seem to be a direct conversion between project types?
* Are there best practices for managing a large number of fields in either setup?

* Has anyone gone through a similar migration, and what was your experience?

Thanks in advance for any insights.

Paul Glantschnig _Appfire_ · Answer

Hi @Lufei Yu and welcome to the community!

The already given replies, cover the core well. Let me add a few specifics that might additionally help with your decision.

Does Company-Managed remove the 50-field limit? Yes. The 50-field limit is specific to fields created within a Team-Managed project. Company-Managed projects use globally-defined fields, which have a much higher ceiling (Cloud has a 700-field-per-field-configuration guardrail, but you're unlikely to hit that).

Before you migrate — check if you actually need to. As Trudy pointed out, Team-Managed projects can also use globally-defined fields — they just need a Global Field Context set by your Jira admin. So if you have fields that exist globally (created via Settings > Issues > Custom Fields), you can make them available in your TM project without counting toward the 50-field limit. This might buy you enough room without migrating.

Trade-offs of TM → CM:

CM gives you more control (custom workflows, screens, field configurations, permission schemes) but also more complexity to manage

TM is simpler but more restrictive — the 50-field limit is one example

In CM, any project admin can't just create fields on their own; a Jira admin manages fields globally

There's no direct "convert" button. You'll need to create a new CM project, migrate issues (via CSV export/import or the Jira Cloud Migration API), and remap fields, workflows, and permissions

Formula fields (currently beta in TM) don't exist yet in CM projects / spaces.

Best practices for managing many fields:

Review whether some fields are truly needed or if they can be consolidated (e.g., multiple "status" fields that could be a single select list)

For computed/derived data (sums, date calculations, status-based metrics), consider whether these need to be Jira fields at all — display-time calculations avoid field bloat entirely

Use field contexts to limit which fields appear on which issue types, keeping forms clean

On that point about computed data — if you're open to solutions from the Atlassian Marketplace, you may want to have a look at JXL for Jira, the app my team and I are building.

JXL gives you a spreadsheet-style view of your issues where you can add smart columns — calculated columns that don't require Jira custom fields. Things like time-in-status, linked issue data, sprint metrics, and custom formulas all live in JXL without counting toward any Jira field limit. If a portion of your 50 fields are derived/calculated values, moving those to JXL smart columns could get you under the limit without a full migration.

JXL works with both Team-Managed and Company-Managed projects, so it's useful regardless of which direction you go.

Cheers, Paul

Trudy P Claspill · Answer

Hello @Lufei Yu

Welcome to the Atlassian community.

Company Managed project make use of fields that are defined globally and shareable between projects.

Team Managed project allow you to make custom fields that are not shareable and are available only within that one TM project. In TM projects you can also make use of globally defined fields (the ones used by CM projects) where there is a Global Field Context defined.

The 50-field limit in TM projects is specific to the custom fields you create within the TM project. You can add more fields to the TM project by having your Jira Admin create globally defined fields that have Global Context.

Company Managed projects use Field Configurations to determine which fields may be used in each Work Item type. Note that not all of those fields may actually be used; the Field Configurations defines the fields that could be used. The Field Configuration allow up to 700 fields.

When considering moving from TM to CM projects some things to keep in mind:

* Project Admins do not have access to add new fields, change the workflow, add new work item types, and many other things in CM projects. Customization of CM projects is mostly managed by Jira Administrators.
* If you move your work items from the TM project to the CM project there could be data loss. Refer to: https://support.atlassian.com/jira-software-cloud/docs/migrate-between-team-managed-and-company-managed-projects/
* There could be other differences in functionality depending on whether you are working with a Business, Software, or Service project. For instance in a CM Software project board you can see both Story/Task cards and their child Subtask cards at the same time. That is not supported in the TM Software project board.

The migration approach is basically:

* Create a new CM project
* Configure it to match your issue types, workflows, custom fields from the TM project
* Move the issues from one project to the other.

I would make sure that your test the move with a few duplicated work items to see how it works before moving your "production" work items.

Note also that because TM work items cannot cross the project boundary for linking Epics and child work items, if you have any such links those will be broken during the move. Many people use Automation Rules to make note in a separate custom field what the original key for an Epic is, note that original key also in its child items, and then use Automation Rules after the move to re-assign the child items to their Epic.

Regarding best practices for managing large numbers of fields, my best practice is to not have large numbers of fields. Each request for a new field should be evaluated to determine the business case for it, and evaluate if there is an existing field that can already fulfill the need. I like to use the Five Why's approach to evaluating requests for customizations. Also consider if there is an alternative way to achieve the requirement.

Arkadiusz Wroblewski · Answer

Hello and welcome @Lufei Yu

If the 50 custom field limit is your blocker, then company-managed is the right direction.

The trade-off is that this is not a direct conversion. Moving from team-managed → company-managed usually means recreating and reconfiguring things like fields, screens, workflows, and permissions in the target project.

So my short answer to your questions would be: yes, company-managed removes that specific limit; the main downside is the migration/rebuild effort; and the recommended approach is to treat it as a planned migration, not a simple switch.

On best practice, I would also review whether all fields are really needed, because even in company-managed, “more fields” is not always the best long-term design. Atlassian does have other field guardrails in Cloud as well