How did user macros actually disappear from Confluence Cloud? Did Atlassian ever explain why?
We went digging. Old Jira tickets. Ancient release notes. A 2012 Summit slide deck. Community threads from a decade ago. A few coffees later, we had a surprisingly complete paper trail.
Ask anyone who ran Confluence Server or Data Center what they miss most after migrating to Confluence Cloud. "User macros" comes up almost immediately. Not Team Calendars. Not custom CSS. User macros. A feature most admins never thought about until the day it disappeared from their instance.
Here's what we found, backed by the actual tickets, releases, and community threads that tracked it in real time, including why it took Atlassian eleven years to give this a final answer.
A feature built for tinkerers
User macros showed up early in Confluence's life, before Cloud and even way before Data Center. Even in its early years, Confluence let system administrators write their own reusable snippets like wiki markup, HTML, CSS, JavaScript, Velocity straight from the admin console, no plugin required. By Confluence 4.0 in 2011, the feature was mature enough to need real governance. Macros now had to declare parameters and be explicitly marked "visible to all users." That's not an experimental feature. That's infrastructure people were actively depending on.
What made a Confluence user macro different from regular macros was who could build them. No plugin, no developer, no marketplace listing required. Any Confluence administrator could open General Configuration, write a snippet of wiki markup, HTML, or Velocity, and give it a name. The macro would then show up in the macro browser for everyone, right next to the macros Atlassian shipped out of the box.
Teams used them for everything: styled panels, custom buttons, conditional content, embedded widgets, small internal tools nobody outside the company would ever see. It became such a well-loved part of the platform that it got its own talk at Atlassian Summit 2012. Steve Goldberg, a technical writer at Venda, walked a room full of admins through building their own. He pointed them to a GitHub repo of macros to fork. Whole libraries of community-written macros circulated for years afterward, covering everything from HTML5 audio players to Bootstrap-styled progress bars.
Long story short: by the early 2010s, user macros weren't an edge case. They were infrastructure built by admins, for admins, with zero involvement from Atlassian's own product team.
That last part matters, because it's exactly what Cloud's architecture couldn't accommodate.
Why Confluence Cloud never got user macros
On 5 November 2012, a Confluence user named James Dellow filed a suggestion. Support simple user macros in what was then still called Confluence OnDemand. That was the product's name before it got rebranded to "Cloud." The detail alone tells you the gap existed before the word "Cloud" was even part of Atlassian's vocabulary.
The ticket, CONFCLOUD-27141, asked for something modest: a template-style macro that admins could define and call by name, without the raw HTML/JavaScript execution that worried Atlassian's security team.
It picked up some votes steadily and a handful of watchers over more than a decade. That's a long tail for a feature request. Usually that means one of two things: either nobody cares, or a small, committed group keeps coming back to check.
Atlassian's answer, when it finally came on 26 June 2023, was Won't Fix.
The reasoning had been on the record since the early Cloud days. A Confluence Cloud user macro allows arbitrary HTML and JavaScript to run. In Confluence Cloud's architecture, the same web interface serves both content and site administration, so that's a real cross-site scripting risk. Atlassian's own documentation on differences between Data Center and Cloud still lists user macros under "Not available in Cloud," full stop, pointing admins toward Forge or Connect apps and the Marketplace instead.
It's a defensible security argument.
Does the Confluence Cloud Migration Assistant migrate user macros?
Closing CONFCLOUD-27141 didn't make the underlying problem go away. It just exposed a second one, specific to migration. In February 2023, CONFCLOUD-79019 was filed: custom macros built through the Server/Data Center "user macro" admin feature simply aren't migrated by the Confluence Cloud Migration Assistant. No mapping, no conversion, no equivalent waiting on the other side. Atlassian's own problem definition on the ticket is blunt about the consequence: it causes migration challenges with direct impact on both timeline and cost.
That ticket is still open, still in "Gathering Interest," and still active. It was last updated in mid-August 2026, weeks before this article.
The workaround Atlassian lists on the ticket itself is one line: recreate every custom macro using Forge or Connect. For a company with a handful of macros, that's a weekend project. For an enterprise instance with hundreds of pages built around dozens of macros, that one line is a migration blocker with a real budget line attached.
What that actually looks like for migrating teams
The Atlassian Community forums fill in the rest of the picture. One long-time Community Leader put it about as plainly as it gets: on Cloud, user macros simply don't exist, and you have to drop them.
Another admin, migrating a Confluence instance with years of accumulated macros, described the experience of researching the topic beforehand: barely any documentation. What little exists amounts to "write a Connect or Forge app," or "check the Marketplace" with no acknowledgment of how much manual work that means for teams that never expected to become app developers.
The practical result, described across multiple threads: pages with a missing macro show a bright red "Error loading the extension!" box. The content is still there, text and data aren't deleted. But the formatting, logic, and behavior the macro provided is simply gone. Multiply that by every page the macro touched, and a data migration turns into a rebuild from scratch.
What to check before you migrate
If your Server or Data Center instance is still ahead of you on the migration timeline, this is worth checking now rather than discovering it mid-project:
Open General Configuration → User Macros on your instance and count which macros are in use. Most admins are surprised by the total.
Search your spaces to locate each macro. A macro on three pages is a cleanup task; a macro on 300 pages requires inclusion in your migration budget and timeline.
Flag macros that are purely cosmetic (styling, panels) versus those that contain logic (conditional content, data retrieval). Recreating the latter often increases cost and effort.
None of that requires a tool. It just requires knowing the gap exists before the Migration Assistant quietly leaves it behind.
Where that leaves teams today
Atlassian's stated path forward is consistent: build a Forge or Connect app, or find one on the Marketplace that reproduces what the macro did. For teams without in-house developers or without the appetite to turn "we had a macro for that" into a software project that's a real gap. Cloud promises parity; a Data Center admin could do this from a settings page in five minutes.
That gap is exactly why we built User Macro for Confluence Cloud, backed by Atlassian Ventures. It gives admins back the ability they lost: define a macro, give it a template, make it available across the site without custom app to write or maintain. It also includes a User Macro Exporter, built to pull macros out of a Data Center instance ahead of migration. So teams aren't starting from a blank page, or from CONFCLOUD-79019's official answer of "recreate everything manually."
Eleven years is a long time for a feature request to sit open. It's a good reminder that "not available in Cloud" doesn't have to mean "gone for good". Sometimes it just means someone else has to build it.
Migrating to Confluence Cloud and not sure what will survive the move? Talk to us about auditing your user macros before you start, or try User Macro for Confluence Cloud directly on the Atlassian Marketplace.
Sources: CONFCLOUD-27141, CONFCLOUD-79019, Atlassian — Differences administering Confluence Data Center and Cloud, Atlassian Community threads on user macro migration (1, 2), Atlassian Summit 2012 session "User Macros: Making Your Own Changes to Confluence" (Steve Goldberg, Venda).