Why do customers pick Confluence?
When it comes to making SharePoint attractive for typical Confluence customers, you have to answer the question Why do customers pick Confluence in the first place?.
For me, it’s not that easy to answer since I’m mainly in touch with teams moving away from Confluence to SharePoint. Often, Confluence has been around for more than a decade. But what I see is common usage patterns that allow insights into why Confluence was chosen in the past.
👉 You’ll find a list of common Confluence use cases below.
I’m vocal on LinkedIn and X when it comes to SharePoint’s limitations with regard to the wiki use case (Confluence is an enterprise wiki) - and there are quite some.
👉 You’ll find a list of the most blocking SharePoint limitations below.
To get started, let’s have a look at the most mentioned reasons for moving away from Confluence - because this doesn’t seem to have anything to do with functionality.
Reasons to Move From Confluence to SharePoint Online
The following points are not a recommendation, but input I got from nearly a hundred demo sessions for WikiTraccs (the Confluence to SharePoint migration tool) and WikiPakk (the SharePoint page tree).
The main two reasons for moving away from Confluence are:
- The cost of Atlassian products is increasing steadily. SharePoint licenses are available in the company, so those should be used instead.
- Strategic decision for the Microsoft ecosystem, consolidation of products and services.
And that’s basically it. It’s either cost, or strategy, or both.
Notable other reasons were:
- “Somebody long time ago set up Confluence, we don’t really know how that happened but it isn’t properly aligned.”
- “Our Confluence admin left.”
- A reduction of vendor lock-in in general, with the goal to be independent of any vendor at all (that’s where my WikiTraccs for Markdown proof of concept came from).
Common Confluence Use Cases
When talking with customers, I commonly see the following use cases in Confluence.
Team Knowledge Base & Technical Documentation
Teams use Confluence to document everything related to software development, hardware development, and whatever needs to be documented in their specific sector.
The content is “functional” - lots of plain text, code snippets, images, tables, and so on. Not necessarily pretty.
The content lives potentially forever.
Project Documentation & Collaboration
When a project starts, a Confluence space is created for project documentation, collaborative meeting notes, and progress tracking.
Project spaces contain technical documentation, but there will also be a lot of management focused content (progress tracking, meeting notes).
When the project ends, the space usually can be archived.
The migration result in SharePoint usually looks pretty good, as there is not too much effort put into the looks of the content.
Process Documentation & Work Instructions
Drafting and publishing mission-critical content, keeping information in a manner that survives an audit.
Intranet & News Authoring
There are many Confluence-based intranets out there, often themed by third-party solutions. Those are hard to migrate because nearly all the styling and layouting will be gone in SharePoint.
Confluence supports news (called blog posts) which can be shown on the intranet start page. This is comparable to SharePoint news posts.
General Observations
The more third-party styling and layouting plugins are installed to Confluence (for example AURA content formatting macros, see animation in next section), the harder content is to migrate, as folks will use those.
The longer content is supposed to live, or the more complex content is, the more of third-party styling and layouting macros will be used (for example Navitabs navigation and tabs macros).
Technical Limitations of SharePoint Compared to Confluence
What would make migrating to SharePoint easier?
Inlining & Nested Macros
SharePoint does not allow extensions inside text web parts - little pieces of functionality that float with the text. Micro parts.
Having that would allow dynamic @-mentions, little status lozenges, the current date - you name it.
And how about nesting whole macros? How about a macro around a text web part? Applying formatting, a border, reusability, and such?
Nested Tables
Please. Just enable that in the editor. I know that technically SharePoint supports that.
Reusable Content
This is a really big one. There is no way in SharePoint to create reusable content snippets or to embed pages in pages. I this this being heavily used in Confluence to avoid duplication of content.
Here’s my blog post about that pain: Sharing Content Across Pages Is Impossible.
Toggle Visibility of Content
This is a huge one as well. Confluence has the Expand macro that allows to expand and collapse a section of content. Tabs also fall into that category.
All in One Animation
Here is an example, showing all of the above features in one example.
The animation shows:
- nested content (multiple levels) (note: third party solution)
- inline content (status, date) (note: mix of third party and out of the box solutions)
- toggling the visibility of content (note: out of the box functionality)
- nested tables (note: out of the box functionality)
- tabbing (note: third party solution)
- wide page real estate for content
- a content snippet being reused on the same page (note: there are both out of the box and third party solutions that can do that)
You might say: nobody does what I did in that video. But I’ve seen it all. And more.