Jira is renaming "Projects" to "Spaces" across all Jira Cloud products starting September 1, 2025. This is only a terminology change – your workflows, data, filters, and APIs will not be affected. Full rollout by November 10, 2025, and for Release Tracks by December 9, 2025. JQL, filters, automation, and APIs will continue to support ‘project’ to maintain compatibility. Goal: To align terminology across Atlassian tools like Confluence for a more unified experience. No action needed from admins – the update is automatic.
This could end up having huge implications if not done right. Will JQL searches based on 'Project' be automatically renamed or will these break? What about API endpoints? Is there no rollout to Sandbox prior, just straight to Prod???
STOP WITH THE ALL THESE CHANGES. they are unnecessary and confusing.
Specifically, renaming Projects to Spaces in Jira feels like a misstep. In our organization, a "Jira Project" directly maps to a real-world project initiative. For example, we maintain a main project for our live production application, and when we take on a major enhancement (lasting several months), we spin up a new Jira project to track that effort separately. Once it’s completed and deployed, we archive it and return to using the main project for ongoing maintenance.
This naming convention aligns perfectly with how we and many others manage work. Calling it a Space introduces ambiguity and undermines the core concept of project management. After all, we’re project managers—not space managers.
Oh, why. I have enough trouble with users confusing Confluence with Jira, and now I cannot even tell them that one is a 'space' and the other is the 'project'.
'Apps' were enough, this naming gets more and more confusing.
the classical view is supposed to still exist for compatibility. However, when trying to install on a fresh instance, setting a feature which was used before (jsw.classic.issues) now suddenly does not exist anymore (classical kanban company managed "space" type) .
1. On what channel can i subscribe to be aware of such a breaking change .
2. Where can I read about the equivalent feature?
3. what is the safe approach to keep your forge app installation working in case of such a change?
(if (legacy-instance detected ) then install feature
else if (instance on which newer look and feel is rolled out ) then do something else (set the equivalent or if does not exist at all anymore, do nothing ?)
4. how can you test against such features if you do not know upfront whether is is already rolled out.
(we see different behaviour depending on our free instances, our premium instances, and on FRESH customer premium instances). It would be nice to know upfront whether our current forge app is still functional depending on these different versions.
31 comments