4.1 Company-Managed vs. Team-Managed Project Architecture

Company-Managed vs. Team-Managed Project Architecture

In Jira Cloud, every project belongs to one of two distinct architectural models: Company-Managed Projects (CMP) (formerly referred to as Classic projects) and Team-Managed Projects (TMP) (formerly referred to as Next-Gen projects). For an enterprise Jira Administrator preparing for the ACP-120 examination, understanding the structural, governance, and operational differences between these two models is foundational. The choice between CMP and TMP dictates how configurations scale, who controls changes, how data is queried across the organization, and how compliance frameworks are maintained.

---

Architectural Comparison: Shared Global Schemes vs. Project-Scoped Objects

The fundamental architectural distinction between CMP and TMP lies in scheme inheritance versus project-level encapsulation.

Company-Managed Project Architecture

Company-Managed projects are built entirely on Jira's relational scheme architecture. In a CMP, the project acts as an operational container that binds together multiple global configuration schemes:

• Issue Type Scheme: Defines which standard and sub-task issue types are available.
• Workflow Scheme: Maps issue types to specific workflow definitions.
• Issue Type Screen Scheme & Screen Schemes: Control field layouts for Create, View, and Edit operations across issue types.
• Field Configuration Scheme: Dictates field visibility, required status, and renderers per issue type.
• Permission Scheme: Grants granular project permissions to Project Roles, Groups, and Users.
• Notification Scheme: Dictates email alert triggers for system and custom events.
• Issue Security Scheme: Restricts issue visibility to designated security levels.

Because these schemes exist at the global Jira administration level (Cog > Issues), a single scheme can be associated with hundreds of projects simultaneously. When a Jira Administrator updates a shared workflow or adds a field to a shared screen, the modification instantly propagates to every project sharing that scheme. This provides tremendous administrative leverage, consistency, and centralized governance.

Team-Managed Project Architecture

Team-Managed projects abandon the shared scheme model in favor of complete project isolation. A TMP does not reference global workflow schemes, screen schemes, or permission schemes. Instead, all configurations—including issue types, custom fields, board columns, workflows, and access rules—are defined, stored, and managed directly within that single project's boundary (Project settings).

In a TMP:

• Project administrators can add new issue types or customize workflows directly without involving a Jira Administrator.
• Custom fields created within the TMP are scoped exclusively to that specific project.
• Access is governed by simplified project roles (Administrator, Member, Viewer, or custom project roles) rather than complex, 40+ permission global schemes.

---

Governance Trade-offs: Enterprise Standardization vs. Team Autonomy

Deciding between CMP and TMP represents an organizational governance decision between centralized control and decentralized agility.

                    CENTRALIZED GOVERNANCE vs. DECENTRALIZED AUTONOMY

   Company-Managed Projects (CMP)                Team-Managed Projects (TMP)
  ┌─────────────────────────────────┐           ┌─────────────────────────────────┐
  │ • Centralized Jira Admin control│           │ • Project Lead self-service     │
  │ • Reusable global schemes       │           │ • Zero Jira Admin overhead      │
  │ • Strict regulatory compliance  │   VS      │ • Rapid iterative changes       │
  │ • Standardized cross-team KPIs  │           │ • Complete team independence    │
  │ • Controlled custom field pool  │           │ • Potential field sprawl        │
  └─────────────────────────────────┘           └─────────────────────────────────┘

Enterprise Governance & Compliance (CMP Advantage)

In regulated industries (finance, healthcare, defense, automotive) requiring compliance standards such as SOC 2, ISO 27001, HIPAA, or SOX, auditability and process enforcement are mandatory. Company-Managed projects allow the organization to:

• Enforce strict separation of duties (e.g., developers cannot approve their own pull requests or close their own defects).
• Require specific fields (e.g., Root Cause, Fix Version, Risk Score) across all engineering projects using standardized Field Configurations.
• Restrict administrative privileges so that project leads cannot arbitrarily remove audit steps, modify approval gates, or grant unauthorized external access.
• Ensure uniform status definitions across 50 development squads, enabling executive dashboards to accurately report cycle time and lead time.

The Custom Field Proliferation Dilemma (TMP Risk)

While TMPs empower teams to create fields freely via Project settings > Issue types, this flexibility introduces severe database and governance risks at enterprise scale. When a project admin creates a field named T-Shirt Size in TMP Alpha, and another admin creates T-Shirt Size in TMP Beta, Jira Cloud registers two distinct custom fields in the backend database. In large organizations with hundreds of TMPs, this leads to:

• Custom Field Proliferation: Hundreds of redundant custom fields with identical or overlapping names.
• Search & Reporting Friction: A Jira user querying cf[10450] = 'Medium' will not retrieve issues from cf[10488] = 'Medium', even though both appear as T-Shirt Size in the user interface.
• Performance Degradation: Excessive custom field definitions can degrade instance indexing performance and screen rendering speeds.

---

Feature & Agile Board Differences

Beyond administrative controls, the daily user experience and agile delivery mechanics differ substantially between CMP and TMP.

Agile Boards and Column-to-Status Mapping

In a Company-Managed Project, agile boards (Scrum and Kanban) are entirely independent entities governed by a Saved Filter (JQL).

• A single CMP can host dozens of different boards (e.g., Team Board, QA Board, Triage Board, Executive Overview Board).
• A single CMP board can aggregate issues across multiple projects (project in (PROJA, PROJB, PROJC) ORDER BY Rank ASC).
• Board columns are mapped manually to global workflow statuses. Unmapped statuses remain hidden from the board without breaking the underlying workflow.

In a Team-Managed Project, the board is the project.

• When a project lead adds a column to a TMP board, Jira automatically creates a new status in the project's internal workflow.
• If a column is deleted, issues in that column must be moved to another status.
• The TMP board cannot pull in issues from other projects or support complex multi-project JQL filters.

Estimation & Reporting

• CMP Estimation: Supports Story Points, Original Estimate (hours/days), Issue Count, or any custom numeric field, configured via Board settings > Estimation. Advanced burndown, velocity, and cumulative flow reports offer deep retrospective analytics.
• TMP Estimation: Configured in Project settings > Features > Estimation. Supports Story Points or Issue Count. While burndown and velocity charts are available, configuration options are streamlined and fixed.

---

Migration Realities: Moving Between CMP and TMP

One of the most frequent misconceptions tested on the ACP-120 exam is the belief that Jira Cloud provides an automated toggle to switch a project from Team-Managed to Company-Managed or vice versa.

[!IMPORTANT] There is no direct conversion switch or automated toggle between CMP and TMP. Transitioning issues between project types requires a manual, multi-phase migration using Jira's Bulk Move functionality.

                        MIGRATION REALITY: TMP TO CMP

  ┌───────────────────────┐                    ┌─────────────────────────┐
  │  Source TMP Project   │                    │ Target CMP Project      │
  │  • Project-scoped     │                    │ • Shared Global Schemes │
  │    custom fields      │                    │ • Standard Workflows    │
  │  • Internal statuses  │                    │ • Global Custom Fields  │
  └───────────┬───────────┘                    └────────────▲────────────┘
              │                                             │
              │   1. Audit fields & statuses                │
              │   2. Provision target schemes in CMP        │
              │   3. Pre-create Components & Versions       │
              │   4. Execute Bulk Move (Map Types & Fields) │
              └─────────────────────────────────────────────┘

Comprehensive Step-by-Step Migration Procedure (TMP to CMP)

1. Pre-Migration Audit & Schema Design:

   • Review all custom fields, issue types, and statuses currently active in the source TMP.
   • Determine which TMP custom fields must be migrated to existing global custom fields, and which require creating new global custom fields in Cog > Issues > Custom fields.
   • Ensure global custom field contexts are assigned to the target CMP.

2. Target Project Provisioning:

   • Create a brand new Company-Managed project (Projects > Create project > Company-managed project).
   • Associate the target CMP with the appropriate corporate Workflow Scheme, Issue Type Scheme, Screen Scheme, Field Configuration Scheme, and Permission Scheme.

3. Pre-Populate Project Structural Metadata:

   • Components and versions belong to a single project. Create the ones you need in the target CMP before the move so values can be mapped.
   • Custom field data from a team-managed project doesn't carry over in a bulk move. Atlassian's documented approach is to export the issues to CSV first, bulk-move them (system fields, comments, and attachments transfer), then re-import the custom field values against the new issue keys with the CSV importer.

4. Execute Bulk Move:

   • Navigate to Filters > View all issues and execute a JQL search for all issues in the source project: project = 'SOURCE_TMP' ORDER BY key ASC.
   • Select Tools (three dots) > Bulk Change > all [N] issues.
   • Choose Move Issues and click Next.
   • Step 1 (Select Projects and Issue Types): Map each source TMP issue type (e.g., Bug, Task) to the corresponding target CMP issue type.
   • Step 2 (Map Statuses): Map each source TMP status to a valid workflow status available in the target CMP's workflow scheme.
   • Step 3 (Map Fields): Carefully map each source field to the target field. For fields where the target requires specific formats or mandatory values, supply default mappings.
   • Step 4 (Confirm and Execute): Review the migration summary and trigger the asynchronous bulk move task.

5. Post-Migration Remediation:

   • Update external Jira filters, dashboard gadgets, and agile board filters to reference the new project key.
   • Review Jira Automation rules that triggered on the old project and update their project scopes.
   • Verify the new issue keys. A moved issue gets the next available number in the target project (for example, OLD-12 might become NEW-87). Links to the old key redirect to the moved issue, but boards and JQL queries that list specific keys must be updated.

---

Shared Configurations for Company-Managed Projects

Blueprint 2.1 asks you to weigh the advantages and limitations of shared configurations. When a Jira admin creates a company-managed project, they can choose to share settings with an existing project instead of generating a fresh set of schemes from a template. The new project then points at the same workflow scheme, issue type scheme, screen schemes, field configuration scheme, and permission and notification schemes as the existing project.

Rule of thumb: Share configuration when teams truly follow the same process. Use a template, or a copy of the shared schemes, when a team needs its own workflow or screens.