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.

[vv]

@Elle Ky

Customers are extremely dissatisfied with the way the deprecation of the legacy editor has been handled, particularly the lack of proper support and guidance throughout this transition. This change is causing significant pain and additional workload for administrators, who are forced to deal with unexpected issues and gaps in functionality.

In addition the tight timeline is causing immense frustration for Confluence users migrating from Data Center to Cloud. If you are going to deprecate a core functionality, you should account for all edge cases and ensure everything works smoothly by the stated timeline—not provide vague answers and leave customers to deal with it. At the end of the day, admins are burdened with extra work on top of their regular responsibilities, all because of Atlassian’s poor design decisions. Who will compensate for the time and effort we must spend checking for errors and troubleshooting, just to keep using Confluence?

It is not acceptable to shift responsibility for third-party app issues. If Atlassian chooses to host and promote third-party apps on its platform, they must also take responsibility for ensuring a smooth transition and providing adequate support to customers. Otherwise, such apps should not be hosted on the Atlassian platform in the first place.

Atlassian should take the lead to ensure all 1p and 3P functionality is smoothly transitioned by said date or delay the deprecation timeline until all features are fully supported.

[Chris_Acton]

Unfortunately, I will need to block more time for edits with new editor - not user friendly :(

[Dino Willy Baraldo]

It's incredibly frustrating—every time I try to copy or paste a single word or a small piece of text, the entire content gets automatically selected, sometimes even the whole text box. On top of that, countless floating windows pop up, making it impossible to see what I'm actually doing.
My question is: is there a way to disable these features, such as AI suggestions, translation tools, comments, and automatic enhancements?

[Susanne Ertle]

Definitely support that, it really is frustrating.

If a sentence starts with an "I" it's impossible to select to select the first word only, it has to be selected backwards, i.e., from right to left.

[Maarten van Dinther]

Hello,

Does this mean that you can no longer use the datatype storage instead of ADF in the confluence API?

[Elle Ky]

Hi @vv 

If you are going to deprecate a core functionality, you should account for all edge cases and ensure everything works smoothly by the stated timeline

Thank you for sharing your feedback with us. We understand the importance of ensuring a smooth transition. I will provide you with parts of our announcement and a link to our Deprecation Details & FAQ page, which highlight our commitment to addressing these gaps and ensuring a seamless transition by the stated timeline. Our team has already implemented many improvements based on previous feedback, and we are actively working on additional improvements in the coming months to address the major remaining gaps. 

The number of pages that are currently "unsupported" or "partially supported" is expected to drastically decrease in the coming month as we roll out major changes to support more content. 

On improvements to the conversion process:
We hear your concerns about quality and manual effort. Improving the conversion experience is a top priority as we have communicated. Please see my comment above to Keith Furnell to understand recent improvements we made. While not every incremental improvement will be announced here, rest assured that the work is ongoing and prioritized based on feedback. The number of pages that are currently "unsupported" or "partially supported" is expected to drastically decrease in the coming month as we roll out major changes to support more content. 

The best way to share your feedback:
As noted in our FAQ, if there are specific features that are important to your workflows, please search for them on jira.atlassian.com. under Confluence Cloud suggestions. Voting for and commenting on suggestions directly helps us prioritize the improvements that matter most to you. Feedback posted in community forums is much harder for our product teams to track and action, so we strongly encourage you to use JAC to ensure your voice is heard and your needs are visible to our development team. When we resolve feature suggestions or bugs, we also provide updates on those specific tickets. 

From our announcement above: 

Preserving Legacy Content

You are not required to take specific action for this deprecation, as our solutions are designed to enable a smooth, automatic conversion. We’re focused on ensuring the transition to the cloud editor is as straightforward and smooth as possible:

• Closing Feature Gaps: We’re focused on addressing the highest priority customer needs so that by the time of deprecation, nearly all pages can be converted seamlessly—minimizing manual effort required. Support for legacy pages with nested macros (through the legacy content macro) and nested tables is already available, along with new features to power better real-time collaboration in the cloud editor.

• Automatic Conversion: You are not required to take action to manually convert legacy pages. Eligible legacy pages will be automatically converted to the cloud editor according to our deprecation timeline. Content will remain viewable and editable after the deprecation, even without manual intervention.

• Legacy Content Macro: 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. We’re actively expanding support for additional use cases over the next quarter.

• Admin Controls: Site and space admins can enable auto-conversion settings to streamline the process for their teams. This is not required, but can help admins get a proactive head start on the transition. Pages with unsupported content that can’t be converted yet will remain in the legacy editor and won’t be auto-converted until support becomes available.

While no action is required for most customers, if you have especially complex legacy pages, we encourage you to convert eligible pages early and share feedback. Your input helps us refine our solutions and support you better.

---

From the Deprecation Details & FAQ page:

Legacy features not available in cloud editor Why are some features from the cloud editor not available in the legacy editor, and when will missing features be added?

Atlassian is actively working to address the most critical gaps between the legacy and cloud editor so that, by the time of deprecation, nearly all pages can be converted seamlessly with minimal manual effort. Some features from the legacy editor have intentionally not been replicated in the cloud editor due to technical limitations and our focus on building a modern, scalable editing experience for the cloud. If there are specific features that are important to your workflows, please search for them under Confluence Cloud suggestions on jira.atlassian.com. Voting and commenting on suggestions helps us prioritize improvements that matter most to you.

[Elle Ky]

Hi @Laurie Hickey @Danja Karenko

The number of pages that are currently "unsupported," "unsupported too big," or "partially supported" is expected to drastically decrease in the coming month as we roll out major changes to support more content. Once these changes are rolled out, we estimate that approximately 99.6% of pages will be eligible for conversion.

In general, as we roll out improvements to the legacy content macro (LCM) so that it supports more use cases, you can expect to see these "unsupported" pages turn into "supported." The content that the LCM supports is the same regardless of whether the page is manually converted or automatically converted ("forced automatic conversion" as you described it). We’re actively expanding support for additional use cases over the next few months. 

Following this upcoming major release, we will continue to address remaining edge cases to ensure that, by the time deprecation begins in January, nearly all content will be eligible for conversion. For the small number of pages that remain unsupported, please note that these pages will still be viewable even after the legacy editor is fully deprecated.

Additionally, later this month, we will introduce an admin tool to make it easier for you to generate space-level reports to quickly identify how many legacy pages you have and how many are eligible for conversion.

Improving the conversion experience remains a top priority for us. While not every incremental update will be announced here, please be assured that this work is ongoing and continues to be prioritized based on your feedback.

[emanuel_m_fernandes]

@Elle Ky We have many pages with design specs which haven't been migrated to the new editor due to a single reason: imagery management (auto-update images in a single page to propagate to multiple pages). This is the main reason holding us back to migrate.

We need a way to reuse images from other pages, so that we can quickly update images in a central place, only by dragging and dropping, using the image's name as the ID. Managing images page by page is a nightmare for us.

CLOUD-12503