The Legacy Editor is being deprecated in Confluence Cloud: Here’s what you need to know

[Dave Thomson]

We are actively looking for a replacement for Confluence.  The switch to Confluence Cloud was bad enough.  The amount of $$$ lost due to drop in productivity was huge.  90% of the features added to the new editor are either sub par or useless to us.  The new table editor is a joke compared to what is available from the Google or Microsoft documentation platforms.  The fact that it took so many years to get embedded tables into the new editor is a sign that the only ears that Atlassian has is deaf ears.  This new editor vs legacy editor is an example of more of the same.   Confluence is supposed to be a tool to help us make money.  It stopped being that a long time ago.  The ROI is now strongly negative.  

[서영민]

I have been using Confluence Data Center for over four years, making extensive use of JIRA JQL queries to document and manage projects. Our team has grown very accustomed to this workflow, and realistically, it is not something we can easily change.

since moving to the Cloud version, however, editing pages has become extremely difficult. The editor attempts to render every JQL query in real time while editing, which slows the experience to the point of being nearly unusable.

at the moment, we are still relying on the Legacy Editor. But with the announced deprecation and the forced migration next year, we are very concerned about how we will be able to continue working effectively.

at a minimum, there should be an option to disable real-time query loading in the editor. Users should be able to choose whether queries refresh during editing or only in view mode. Without such an option, many teams like ours will be left with no choice but to consider alternatives. We sincerely ask that you address this issue.

[Danja Karenko]

@Laurie Hickey , fellow customer here also looking into what "unsupported"/"ineligible" means in detail and in practice.
I will ask an Atlassian Support human to look into this, but below is
(1) my AI chatbot prompt. It summarizes our findings from Atlassian's documentation + communication and our own initial manual conversion tests.
(2) the AI chatbot response from the Atlassian Support portal.

TLDR: Our minimal manual conversion tests have been relatively reassuring -- the Legacy Content Macro has preserved the contents that couldn't be converted so they are still legible. However, I am not convinced the forced automatic conversion will yield the same results. Why call it "ineligible" or "unsupported" if the overall page conversion actually works? But maybe it's just a terminology issue.

(1) Prompt

We are preparing for the Confluence Legacy editor deprecation.

We have run the API-based analysis reports (as instructed here: https://confluence.atlassian.com/confkb/export-list-of-legacy-pages-and-their-eligibility-status-1587937727.html) to identify all our pages' eligibility statuses. We have also tested the manual conversion from legacy to new editor for one page in each "eligibility category" that the reports provide: "SUPPORTED", "SUPPRTED_WITH_MIGRATION", "PARTIALLY_SUPPORTED", "UNSUPPORTED_TOO_BG".

Our question is specifically about pages marked "UNSUPPORTED_TOO_BIG" in the reports:
Official Atlassian documentation and communication states: "For complex or unsupported content (like nested macros), we’ve built the Legacy Content Macro to preserve your content and ensure that it remains editable in the cloud editor." When manually converting a sample page marked "UNSUPPORTED_TOO_BIG" in the reports, we are able to convert the page after previewing the changes. As expected, unsupported elements are placed in the "Legacy Content Macro" on the converted page.
But will happen to these "UNSUPPORTED_TOO_BIG" pages during the forced conversion as part of the Atlassian-managed editor deprecation? And what does that mean for our preparation work?

(2) AI chatbot response

### What Happens to "UNSUPPORTED_TOO_BIG" Pages During Forced Conversion?

**Forced Conversion Process**
- During the phased deprecation (especially Phase 2 and 3), all legacy pages—including those marked as "UNSUPPORTED_TOO_BIG"—will be automatically converted to the cloud editor[^01^].
- For pages with unsupported or complex content (such as those too large or with nested macros), the conversion process will place this content inside the Legacy Content Macro on the new cloud editor page[^02^][^03^].

**What the Legacy Content Macro Means**
- The Legacy Content Macro preserves unsupported elements, ensuring that no content is lost during conversion.
- Users can still view and edit the content inside the macro, but with some limitations:
- You cannot copy/paste entire unsupported elements outside the macro (only the text).
- Some features (like inline comments or smart links) may not work inside the macro.
- Collaborative editing inside the macro can be unpredictable—it's best to have only one person editing at a time before publishing[^03^].

**Preparation Recommendations**
- No special action is required for most customers; Atlassian’s process is designed to ensure content remains accessible and editable after conversion[^01^].
- For "UNSUPPORTED_TOO_BIG" pages, you can expect the same result as your manual tests: unsupported content will be preserved in the Legacy Content Macro.
- If you have especially complex or business-critical pages, consider manually converting and reviewing them early. This allows you to restructure content if needed and provide feedback to Atlassian to help improve the conversion process[^01^][^04^].
- Keep a record of pages with this status for post-conversion review, in case manual cleanup or restructuring is needed later[^05^].

**Summary Table**

| Status | Forced Conversion Outcome | Action Needed? |
|-----------------------|------------------------------------------|------------------------|
| UNSUPPORTED_TOO_BIG | Content placed in Legacy Content Macro | Review after conversion|

You can find more details about the Legacy Content Macro and its limitations in Atlassian’s documentation[^03^].

If you have further questions about specific edge cases or need guidance on restructuring particularly complex pages, let me know!

[Laurie Hickey]

@Danja Karenko , I agree with your statement ("... I am not convinced the forced automatic conversion will yield the same results. Why call it "ineligible" or "unsupported" if the overall page conversion actually works?").  The chatbot response doesn't make sense -- if the page is ineligible to be converted, then how is it possible that the automatic conversion would work? 

My plan right now is to attempt to rebuild (from scratch) pages that have been identified as "unsupported" or "unsupported too big" prior to January 1st, but it's a daunting task and I am not sure I will make that deadline, which is why I posted the question.  😞

[Alyson Griffin]

In Confluence, the Jira Legacy Issues macro currently allows exporting Jira issues directly from a Confluence page, with all fields included in the export. This functionality is critical for reporting and record-keeping.

With the new Jira Work Items macro, this capability no longer seems to work as expected. When exporting, not all issues from the JQL query or displayed on the Confluence page are included. Instead, the export appears incomplete or truncated, which breaks workflows that rely on full exports.

So far, I haven’t found a workaround or setting to restore this behavior.

Questions:

Will the export functionality from the Jira Legacy macro remain available?

Is there a plan to bring full export support (all issues and all fields) to the new Jira Work Items macro?

If not, is there an alternative solution recommended by Atlassian for teams who depend on this functionality?

Impact:

Without this feature, teams must leave Confluence and manually export directly from Jira, which causes loss of formatting, duplication of effort, and gaps in reporting.