Your Confluence Data Center licence now has an end date. The 2029 end of life turns a background platform decision into a budget line with a deadline, and many teams start in the wrong place: a feature comparison of every Confluence Data Center alternative they can find. That shortlist decides nothing. The real choice is narrower — rent knowledge management from Atlassian Cloud, or run a wiki your organisation controls.
This post gives IT and digital workplace leads the mechanism to make that choice, including where a sovereign option such as Huddo Wikis fits, then a 90-day sequence to decide, pilot and fund the move. What separates the two paths is migration mechanics and a three-line cost model — per user, per server, per admin hour — not a feature grid.
What Confluence Data Center's 2029 end of life actually forces
What "end of life" means in practice
End of life is where you stop being able to change the platform. You can no longer edit or update the instance, and you already cannot add new licensed users, so it is frozen at the size and version it is on now. Everything behind it stops too: bug fixes, security patches and vendor support. The pages keep loading; the risk does not stop accruing. Every month after that date, you are operating a product nobody is patching.
"Can we just keep running it?"
Technically, yes. However you won’t be able to update any content. Confluence will move to Read Only. Practically, an unpatched system holding your organisation's institutional knowledge tends to fail a security review or an audit long before it fails in production. The question is rarely whether the wiki still loads — it is whether your risk register, your cyber insurer and your architecture board will still accept it. Plan for the review, not the outage.
The runway is shorter than the date
The deadline that matters is the last safe migration window, and it closes well before 2029. Confluence licensing is regularly being increased to force people to Confluence Cloud. Licence renewals commit you for a term. Marketplace apps need to be compatible with the target, not just the source. Change freezes — particularly the end-of-year shutdown — remove weeks from the calendar. Work backwards from those constraints, not from the date on the announcement.
Treat the endgame as settled
Data Center is the final self-hosted edition. Build the business case on the assumption that no extension is coming. Being wrong in that direction costs you a scramble; planning for an extension that never arrives costs you the window. Huddo's enterprise wiki is built for teams making that move on their own terms.
The fork in the road: Atlassian Cloud or a wiki your organisation controls
Be clear about what cloud buys and costs. You stop running servers, patching and backing up the platform. In exchange, data residency, sovereignty and your right to take your data back become contractual questions rather than technical ones, and air-gapped deployment comes off the table entirely.
Be equally clear about the controlled option. You own the data and the deployment model, and you also own patching, backups, disaster recovery and hardware. Argue for it on control and compliance — the things a contract cannot promise — not on it being free. Huddo Wikis is built for that case: sovereign on prem, private cloud or air-gapped, or on AWS, Azure or GCP.
Clear the Marketplace apps first
Before anything else, work through your Marketplace apps. Atlassian's cloud-replacement list tells you which apps have a cloud counterpart, not what happens to the pages those apps generated. An app with no equivalent can decide the migration for the one team that depends on it — and that decision arrives early, not late.
So understand exactly which Marketplace add-ons you depend on, and treat each one as a line in the target. Huddo Wikis builds the majority of the common ones into the product rather than making you buy them again: draw.io, Diagrams, Whiteboards, Workflow and Governance are all part of it.
The self-hosted alternatives, compared on install, licence and hardware — not on vibes
BookStack, Wiki.js, Outline and DokuWiki recur in every self-hosted wiki discussion. They are rarely put side by side on the three things a buyer actually needs: how it installs, how it is licensed and supported, and what runtime and hardware it demands.
Put migration on the comparison, not just deployment
Ask each candidate what moving from Confluence involves and who does the work. DokuWiki keeps pages as files while the others generally expect a database, which changes your backup and upgrade routine, and any tool that calls an external service is out of the running air-gapped. Note the deployment model against those constraints, then ask the harder question: who builds the conversion, and what does it cost.
Most self-hosted wikis leave the migration to you, which is where the real effort lands. Huddo Wikis includes Huddo WikiShift, which migrates your Confluence content across for you, free of charge.
Note where the free options put the burden
Open-source wikis hand you permissions design, audit trails, backup tooling, upgrades and support. For some teams that trade is sound. For a security team that wants a vendor to call when an upgrade breaks, it is not.
Put every candidate in one table
Include Huddo Wikis as a row rather than a separate pitch: an enterprise wiki from Australian software company ISW, deployable on premises, in private cloud, air-gapped, or on AWS, Azure or GCP, with commercial licensing and support. It is the option when "we'll patch it ourselves" is not a sentence you can get approved.
Check provenance explicitly. Who builds the product and where they are based is a compliance question, not a preference, because data residency and sovereignty obligations follow the answer.
The migration work nobody scopes: exports, page trees, permissions, attachments
Export fidelity comes before tool selection. Choose the export format per space — HTML, PDF and XML each preserve different things — then migrate one real space and inspect the result before you commit to a date. Tool shortlisting is downstream of that inspection, not the other way around. Confluence data migration is where the mechanics get settled.
Page trees and Spaces are an architecture decision
A page tree is an information architecture rebuild, not a file copy. Decide whether the target mirrors the space tree, flattens into a curated hierarchy, or leans on labels and tags instead. Pick one rule and apply it across every space; mixed rules produce a target nobody can navigate.
Restrictions do not translate one-to-one
Space and page restrictions map onto groups and roles in the target, and the mapping is never exact. Some restrictions are worth redesigning rather than reproducing — copying permissions is also how you copy permission debt, which is why Huddo Wikis supports full fidelity of space and page restrictions.
Attachments and macros stall migrations
Budget for both separately. Attachments and embedded images need a handling rule: re-host, link, or archive. Every macro needs a per-macro decision — rebuild it, replace it with a plain link, or retire it. Huddo WikiShift maps Confluence macros automatically and migrates them across, which is where that budget usually goes.
The three-line cost model your business case is missing
Vendors quote one line. Your business case needs three. Put every option through the same model:
Per-user subscription. Licence cost per head, renewing annually. This is the line that scales with headcount and gives you a yearly increase to negotiate, which makes it a recurring operating cost rather than a one-off.
Infrastructure. Compute, storage, backup and disaster recovery. Self-hosting converts subscription spend into capital, cloud consumption and staff time, including the procurement and foreign-exchange reality of buying from a vendor outside your region.
Admin labour. Price the hours explicitly: patching cycles, upgrade testing, backup verification and restore drills. Add the premium on keeping an unsupported Data Center instance compliant while you migrate off it. Those hours are real even when nobody invoices them.
Price the exit, not just the entry
For each option, write down what it would take to leave again in five years. The 2029 deadline exists because a vendor ended a self-hosted product line, so any option without a credible exit is borrowing the same problem at a later date.
Give the CFO one number
Convert the model to a per-year, per-employee figure and put it in the executive summary. That is the number a finance team can weigh against a licence renewal — and the comparison no competitor page publishes.
A 90-day sequence to decide, pilot and fund the move
Days 1–30: inventory what you actually have
Count spaces, pages, attachments, macros and integrations. Flag the spaces holding regulated, sensitive or high-value knowledge. That inventory sizes everything after it — the shortlist, the pilot scope, the cost model — and it is the artefact you reuse when procurement asks how you got your numbers. Do it with the export tooling rather than by hand, so the counts survive scrutiny.
Days 31–60: pilot on two real spaces
Pick one messy space and one permission-heavy space. Not a sandbox demo — the messy space shows what breaks on page trees and attachments, the permission-heavy one shows what breaks on group mappings and inherited restrictions. Run the actual export and import and time it end to end. That timing is the most defensible number in your business case, because it is yours. Huddo WikiShift resolves all of these challenges by magically migrating it all seamlessly!
Stand up a test instance first and do it yourself. A trial on your own infrastructure tells you more in a week than a vendor demo tells you in an hour. If you want a candidate to test against, Huddo's downloads page is the starting point for a self-hosted trial, and you can look through the Huddo Wikis demo site before you install anything.
Days 61–90: decide and fund
Take the pilot evidence, the three-line cost model and the shortlist to security and procurement. Leave with an approved option, a named owner, a budget line and a decommission date for the Data Center instance.
Then run it in waves
Migrate by space, freeze content during each cutover, keep the old instance read-only for a defined read-back period, and decommission on the date you set. An instance left running becomes a shadow system nobody owns.