Description
Introduce an enhanced, admin‑only bulk move capability in Jira Cloud that can safely handle very large numbers of issues (tens of thousands) by running as a background or scheduled operation, instead of being constrained by current interactive UI limits and erroring with “too many fields” messages.

Current behavior

This error is based on internal dynamic limits (issues × fields to validate) and:

• Forces customers to manually reduce the batch size until it works, and/or
• Clean up or de‑scope fields from the destination projects without clear guidance on which ones are causing the problem.

Workarounds today:

• Move smaller batches many times.
• Clean up custom fields / contexts / screens to reduce field count.
• Use alternatives like:
  • Clone‑and‑delete via Automation,
  • CSV export/import.

For customers who regularly need to move thousands or tens of thousands of issues, these options are described as “very painful or slow” and make bulk move feel effectively unusable at scale.

Suggested behavior
Provide an admin‑level, schedulable bulk move feature with the following characteristics:

1. Admin‑only mode
   • Accessible to site/org admins or similarly trusted roles.
   • Designed specifically for large‑scale moves between projects.
2. Background / schedulable execution
   • Ability to:
     • Run the bulk move as a background job that does not depend on the browser session, and/or
     • Schedule the bulk move to run in off‑peak times (e.g. overnight, weekends).
   • Jira internally splits the operation into safe chunks (respecting platform limits) and processes them sequentially or asynchronously.
3. Higher practical limits with protection
   • Instead of blocking with “too many fields”, the system:
     • Accepts the full selection (e.g. 14,000+ issues),
     • Automatically handles internal chunking to stay under safe dynamic limits,
     • Surfaces progress (e.g. percentage complete, issues processed, any failures).
4. Better feedback for admins
   • Before running, show:
     • Estimated scale (number of issues, affected projects, rough complexity),
     • Any major configuration factors that could slow it down (e.g. very high number of custom fields on destinations).
   • After running, show:
     • Result summary (moved, failed, skipped),
     • Error details for any issues that could not be moved.

Reason for the change

• Some customers need to regularly move very large sets of issues between projects (e.g. project re‑structuring, consolidating, or cleaning up old spaces).
• Under current behavior:
  • They repeatedly hit dynamic limits and “too many fields” errors.
  • They must manually guess safe batch sizes and repeat bulk moves many times.
  • Alternative paths (Automation clone‑and‑delete or CSV import/export) are slow, complex, and introduce new keys / data fidelity concerns.
• An admin‑level, schedulable bulk move feature would:
  • Make Jira more manageable at scale,
  • Reduce operational overhead and error risk,
  • Align with how admins expect to handle large background operations (similar to other enterprise products),
  • Directly address the repeated frustration around current bulk move limits for large instances.