When Atlassian ended Confluence Server, thousands of organisations discovered that their knowledge base was a per-seat subscription waiting to happen. Many moved to Confluence Cloud; some looked at what else could hold 9,000 pages of company memory. This post follows a knowledge manager evaluating XWiki on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, and running the migration before deciding.
The company is a 400-person engineering consultancy we will call Bramford & Hale, with 9,000 Confluence pages, 40 spaces and a habit of using page properties and macros heavily. The XWiki package deploys XWiki on Tomcat with a MariaDB or PostgreSQL database and persistent storage for attachments and the Solr search index.
The cost shape, first
Confluence Cloud is priced per user per month, with tiers, and every one of the 400 staff who might read a page is a user. XWiki is LGPL-licensed and free to run; the cost is the environment: a Java node for Tomcat, a database node and storage. The knowledge manager's spreadsheet had Confluence Cloud at a four-figure monthly sum for 400 users on the tier with the permissions and audit features a consultancy needs, and the XWiki environment at a two-figure sum before discounts. But she did not decide on that column, because a wiki that people stop using is expensive at any price.
What XWiki is, for someone who knows Confluence
XWiki is an enterprise wiki with a page hierarchy, rich WYSIWYG editing, attachments, versions, comments, fine-grained rights and hundreds of extensions. Its distinctive idea is structured pages: any page can carry a class with typed fields, and those fields can be queried and displayed across the wiki, so a "project" page type with a client field becomes a project directory without a plugin. Confluence users recognise this as page properties and the page properties report, done as a first-class model. XWiki also has an application builder, scripting in pages for power users, and a Solr search index that indexes attachments.
Where it differs: fewer polished third-party integrations than Atlassian's marketplace, a different editing feel that takes a week to settle into, and an administration model that assumes an owner. The knowledge manager listed the eight Confluence macros her spaces depended on and checked each against XWiki's equivalents on a trial environment before going further.
Running the migration before deciding
XWiki ships a Confluence migrator, built on its Filter Streams framework, that imports a Confluence space export and converts pages, attachments, hierarchy and much of the macro content. The manager installed XWiki from the marketplace, then cloned the environment so she had a disposable copy, exported four representative spaces from Confluence and imported them into the clone. The results, per space:
| Space | Pages | Imported cleanly | Needed attention |
|---|---|---|---|
| Engineering standards | 1,400 | Text, hierarchy, attachments, tables | Two custom macros rendered as plain text |
| Project archive | 3,100 | Everything including page properties as XWiki objects | Jira issue macros became links |
| HR handbook | 300 | Everything | Nothing |
| Client onboarding | 600 | Text and attachments | Embedded Confluence whiteboards exported as images |
The two custom macros were rewritten as XWiki macros by the consultancy's own developer in a day. Whiteboards were an accepted loss. The clone that answered these questions ran for a week at a low cloudlet limit and cost a few dollars; it was deleted when the decision was made.
Sizing a Java wiki
XWiki recommends at least 2 GB of heap for a small team and more as the wiki and its Solr index grow; 9,000 pages with attachments is a mid-sized wiki. The Java node's JVM settings follow the container's cloudlet allocation, so the manager set a limit of 48 cloudlets (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU) and let vertical scaling allocate what Tomcat actually used: around 24 during the day, less at night, with a spike during the Solr re-index after the import. The database node is modest. Attachments and the Solr index live on the node's persistent storage with snapshots, and the Database Backup/Restore add-on dumps the database nightly. Across a month the environment averages about 32 cloudlets an hour, roughly $78 before discounts at MassiveGRID's published $0.003372 per cloudlet-hour.
Access, residency and the things a consultancy's clients ask
Bramford & Hale's clients ask where their project documentation is held. The answer became the London region, a named data centre under a GDPR data processing agreement with an ISO 9001-certified provider, rather than a SaaS vendor's region list. Single sign-on uses XWiki's LDAP and OIDC extensions against the company's identity provider. The environment sits in an isolated group; the container firewall exposes 443 on the Tomcat node and nothing else. And the exit is the same as the entry: XWiki exports a whole wiki as XAR, and the environment itself can be exported.
The decision, and what the first quarter showed
They moved. The migration of all 40 spaces ran over a weekend into a fresh production environment, with the four trial spaces re-imported so nothing from the clone leaked in. Page views in the first quarter matched Confluence's last quarter, which the manager took as the real success metric, and the structured project directory that XWiki made possible replaced a spreadsheet three teams had maintained separately. The subscription line disappeared from the budget; the environment line appeared, at a fraction of it, and the manager's honest note in the review was that the week of editor unfamiliarity was real and passed.
Frequently Asked Questions
Does the marketplace XWiki differ from MassiveGRID's managed XWiki hosting?
Yes. The marketplace package is a self-service environment you administer: you choose versions, run upgrades and manage users. MassiveGRID's XWiki Hosting is a managed offer priced per user with the operations included. Teams with an administrator usually take the package; teams without take the managed offer.
How do I keep XWiki up to date?
XWiki releases monthly with a long-term-support line. Clone the environment, upgrade the clone through XWiki's distribution wizard or by redeploying the Tomcat container with the new WAR, check the extensions, then repeat on production. The clone is the safety net.
Can XWiki handle several thousand users?
Yes. Raise the Java node's cloudlet limit for heap and, for very heavy read load, put an NGINX balancer in front of two Tomcat nodes with sticky sessions and a shared permanent directory on a storage container. Most organisations under a few thousand users run one well-sized node.
Run the migration before you decide
Install XWiki on MassiveGRID PaaS, clone it, import a Confluence space and see what comes through. Per cloudlet-hour billing, London or Frankfurt regions, no per-seat licence. Free 14-day trial, no credit card.
XWiki on MassiveGRID PaaS