XWiki cost of ownership: Standard vs XWiki Pro

Is XWiki free, and what does XWiki cost of ownership actually include?

XWiki is licensed under the LGPL 2.1, so the software itself carries no license fee. The real cost of ownership is the infrastructure you run it on, the staff time to install, configure, secure and upgrade it, and any support or Pro subscription you choose to buy. If you are comparing a free wiki with paid options, treat the license line as zero and build the rest of the picture from those components. There are three ways to run XWiki. XWiki Standard is the free open source edition, which you install and operate yourself in your own cloud account, data center or air-gapped network. XWiki Pro combines XWiki with business applications, connectors and XWiki SAS support, and is sold as a subscription. XWiki Cloud is XWiki SAS hosting on its own infrastructure, which moves operations out of your team but puts the wiki in a vendor-run environment. Each option shifts cost between infrastructure, people and subscriptions differently, so compare them on the same assumptions. Many teams keep day-to-day operations in-house on Standard and buy a partner for specific pieces, such as a Confluence migration, a first upgrade, or an extension review. That split is often easier to budget than a full subscription, because each piece has its own written scope. Ask any provider, including XWiki SAS, which items are included in a subscription and which are billed separately as consulting, training or migration work. The right answer depends on three things: how many users you will have, which applications and connectors you need, and what skills your internal team already has. User count affects which subscription tier applies, since XWiki publishes Starter, Basic, Business and Enterprise tiers with different user limits. Required apps, such as SSO applications or Office365 connectors on the Pro list, may only be available in Pro, so confirm the exact app list against your requirements. Internal skills determine how much of the Standard route you can run without outside help. Before comparing totals, ask each vendor for a written quote that states the user tier, the apps included, the support level, whether pricing differs between cloud and on-premises, and what is excluded. Confirm with XWiki SAS whether the pricing it publishes applies to your region and contract term. For the self-hosted route, list your own hosting, database, backup, monitoring and staff hours so the comparison is complete.

What an XWiki cost of ownership model includes

The model is built from your own environment, not a generic price sheet. Each deliverable below feeds the next, so the final recommendation can be traced back to the user counts, integrations and apps that drove it. DeployOpen prepares the model under a written scope agreed before work starts.

User and content inventory

A count of named users, active editors, readers and guests, plus the number of spaces, pages and attachments that will move into XWiki. Tiers such as Starter, Basic, Business and Enterprise are sized against these user counts, so the inventory decides which support and Pro tier is even eligible. Confirm whether guests and external contractors are counted and how often the counts change.

Integration and required app inventory

A list of every system XWiki must talk to, such as Active Directory, Azure Active Directory, Google Apps, Office365, OnlyOffice or a Confluence source, and every business application you expect to use. Each item is marked as included in XWiki Standard, requiring an extension you maintain yourself, or requiring a XWiki Pro application. This separates the free path from the paid path and shows where custom integration work sits.

Side-by-side model of Standard, Pro and Cloud

A comparison of XWiki Standard (free, LGPL 2.1), XWiki Pro and XWiki Cloud against the same inventory. Each column lists the software cost, support tier, hosting location, applications included and who operates the platform. Ask XWiki SAS to confirm current Pro and support pricing and whether cloud and on-premises pricing are identical for your tier, since those terms can change.

Hosting and staff estimate per option

Infrastructure and people costs for each option: servers or cloud resources in your accounts, database and backup storage, reverse proxy, monitoring, and the internal or partner hours needed to upgrade, patch and support users. Standard carries the most internal operating effort, while Cloud shifts hosting to XWiki SAS. Request line-item estimates from each source so the comparison uses the same assumptions throughout.

List of recurring items

A schedule of costs that repeat each year or each cycle: subscription renewals, support plan fees, extension maintenance, security patching windows, backup retention, certificate and licence renewals, and staff time for release upgrades. Separate these from one-time items such as migration, configuration and training. Recurring costs usually decide the total cost of ownership over several years, so this list should be explicit.

Written recommendation and assumptions

A recommendation for Standard, Pro or Cloud, with every assumption that supports it written out: user growth, the chosen XWiki release line, expected extensions, staffing and hosting location. Each assumption carries a note on what would change the answer, such as a new identity integration or a higher support tier. The document is reviewed with your team before it is treated as a basis for budget or procurement decisions.

Which factors push XWiki running costs up or down

This table lists the factors that change the cost of running XWiki Standard or XWiki Pro in your own infrastructure. Read each row as a question to answer before you request a quote. The main takeaway is that user count, paid applications, and internal skills usually move the total more than the free software itself.

Driver	Why it matters for cost	How to keep it down
User count against Pro tier bands	XWiki Pro and support subscriptions are sized in bands: Basic (up to 1,000 users), Business (up to 10,000) and Enterprise (unlimited). Crossing a band can change the subscription you need, so the count you quote drives the tier.	Count named users who need edit or read access, not every directory account. Ask XWiki SAS to confirm how users are counted before you choose a band.
Starter tier availability	The Starter tier (up to 25 users) is listed for XWiki Cloud only. A self-hosted deployment may therefore need Basic or higher if you buy a Pro subscription, which changes the baseline cost.	Confirm with XWiki SAS whether Starter applies to your deployment model before comparing costs. Do not assume a small team qualifies for the lowest tier.
Number of wikis and spaces	Wiki and space structure affects the permissions design, the search index size, and the time needed to migrate and maintain content. Large structures increase admin and support effort even when the license does not change.	Plan a small space hierarchy with clear ownership. Use a pilot space to test structure and rights before the full rollout.
Paid Pro applications and connectors	XWiki Pro bundles applications such as File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram and Pro Macros, plus Google Apps, Office365 and OnlyOffice connectors. Each one you need adds to the subscription scope and the testing workload.	List the features users need in writing and map each to a Standard feature or an extension first. Only add Pro applications that a named business process depends on.
Identity integration	Active Directory and Azure Active Directory SSO applications are listed as XWiki Pro components. An OpenID Connect path through the xwiki-contrib extension is a community option that you must test and maintain yourself. The choice affects licensing, build effort, and ongoing support.	Decide the identity provider and protocol before the quote. Ask whether the SSO application is included in your chosen tier and who supports the community extension if it breaks after an upgrade.
Number of environments	Production, staging and test copies each need compute, database capacity, storage and an upgrade path. Extensions must be tested in staging before production, which adds time for every release.	Keep staging small but representative. Use the same database variant and servlet container in every environment so test results carry over.
Backup and retention needs	Backup scope, retention period and restore testing set storage size and recurring operations work. Page history and attachment history need separate planning, because Confluence Migrator Pro keeps page history but not attachment history.	Write the retention period per content type. Test a full restore on a schedule and record the time it takes, so the recurring cost reflects real operations.
Compliance evidence	Assessors often ask for change records, access reviews, patch dates and backup test results. Collecting this evidence is recurring work for your team or partner. XWiki Cloud infrastructure is described as ISO 27001 certified, but that does not cover your self-hosted environment.	Set up logging, change tracking and access review exports from the start. Ask your auditor which evidence they expect so you collect it once, not during each audit.
Internal skills available	Running XWiki needs skills in the servlet container, the chosen database, extension management and upgrades. XWiki SAS offers consulting and training, with consulting available under a Business or Enterprise support plan. Skill gaps usually add external hours.	Inventory the skills on your team before you request a quote. Train at least two administrators, and ask whether consulting hours are included in the support plan you consider.

Where XWiki Pro changes the bill: tiers, user bands and cloud parity

The XWiki Pro subscription is the line item that changes the total, because XWiki Standard is free and open source under the LGPL 2.1. XWiki Pro combines XWiki with business applications such as File Manager, Forum, Polls, Calendar, Ideas, Meeting and Diagram, plus Pro Macros, Active Directory and Azure Active Directory SSO applications, Google Apps, Office365 and OnlyOffice connectors, and XWiki SAS support. Before you compare prices, list which of these features your knowledge base will use in its first year. Every application you would not use is cost without a matching benefit, and an SSO application only matters if your identity provider is one of the supported directories.

Subscriptions come in four tiers, and user count sets the band. Starter covers up to 25 users and is available only on XWiki Cloud, so an organization that must keep wiki data in its own data center or private cloud cannot use it and should start its comparison at Basic, which covers up to 1,000 users. Business covers up to 10,000 users and Enterprise covers unlimited users. XWiki SAS states that cloud and on-premises pricing is the same, so hosting location does not change the subscription line by itself, although you still pay for the servers, storage and staff time when you run it yourself. Ask XWiki SAS to confirm the current subscription price for your band in writing, because this page does not carry those figures, and ask how users are counted and whether the band is reviewed at renewal.

Services are priced separately, and they are where costs tend to grow. XWiki SAS lists consulting at 1200 EUR per day, and that rate requires a Business or Enterprise support plan. Training is listed at 1500 EUR per day. Confirm whether these list rates apply in your region, whether volume terms exist, and whether any day allowance is included in a subscription. If your user count places you in Basic, consulting at the listed rate may only be available after moving to a higher tier, which can change the comparison more than the subscription difference itself. Estimate the days you expect to buy for installation help, extension review and editor training, then price those days against each tier you could realistically license.

Plan for the costs that recur regardless of edition. Your platform team will run hosting, backups, upgrades and extension testing whether you choose Standard or Pro, so staff time usually outweighs the subscription over several years. A Pro subscription changes who you can call for support, not who operates the server. Migration is a separate line item: XWiki SAS prices its Confluence Migrator Pro from 2000 EUR, and that cost sits outside the subscription. In your quote request, ask what each support plan covers, including response times and upgrade assistance, and record each cost as one-time or recurring so the three-year comparison between Standard and Pro uses the same assumptions.

How the XWiki cost model is built, step by step

This sequence turns requirements into a side-by-side cost model for XWiki Standard and XWiki Pro, with each option priced on the same user numbers, hosting assumptions and staffing. The finance and IT owners approve the model before any option is chosen.

Confirm requirements and user numbers
The project lead and the business owner, with input from IT, record the named user count, expected growth over the planning period, the content volume to be moved (if any), required single sign-on, and the hosting location. User count matters most because XWiki Pro subscriptions are tiered: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000), Business (up to 10,000) and Enterprise (unlimited). This step is complete when the owners sign off on one user figure and one feature list that both options will be priced against.
Choose the release line and database variant
The team compares XWiki's stable line, its long term support (LTS) line and its intermediate LTS line, weighing how often each one requires upgrades and how long security fixes are provided. Next, it selects the database that the organization already runs and supports, from the MySQL, PostgreSQL and MariaDB variants of the official Docker images, all running on Tomcat. Confirm the current image tags on the official library file before pinning a version, because the tags change over time. The output is a decision record naming the line, the database variant and the exact image tag, which the infrastructure and cost lines in later steps depend on.
Price infrastructure and staff for each option
For XWiki Standard, the license is free under LGPL 2.1, so the model carries the hosting, database, storage, backup, monitoring and load balancing costs, plus the internal time for installation, upgrades, extension testing and administration. For XWiki Pro, the same infrastructure lines apply, and the subscription tier is added. Staff time is usually the largest recurring cost in either option, so estimate it per role and per year. Consulting from XWiki SAS is listed at 1200 EUR per day and requires a Business or Enterprise support plan, and training is listed at 1500 EUR per day. The output is one cost table per option that separates one-time costs from recurring costs.
Add subscription, app and migration costs
Here the team lists the paid items that sit on top of either base option: Pro applications and connectors (such as the Active Directory and Azure Active Directory SSO applications, File Manager, and the Google Apps, Office365 and OnlyOffice connectors), and any migration work. XWiki SAS prices Confluence Migrator Pro from 2000 EUR, with a trial limited to 30 pages per migration, according to the XWiki Store listing. Manual rework for macros and attachment history is not covered by the tool and should be estimated separately. Ask XWiki SAS and the extension publishers to confirm current prices, license terms and whether each item recurs. The output is a line list of add-ons, each with its pricing basis and recurrence.
Review the model with finance and IT owners
The team walks finance and IT owners through the assumptions, including the user tier, staffing levels, hosting choice and migration scope, and shows how the totals change if user numbers grow or the release line changes. Owners challenge each assumption, and open questions are logged with a named owner. The model is approved only when both sides accept the assumptions register and the year-by-year totals for each option. Ask any implementation partner for a timeline in the written scope, since the timeline affects the staff and migration lines. Once the model is approved, a quote for implementation work can follow the written scope.

Which parts of the cost model your team can own and which to buy

Infrastructure and operations is the area where in-house teams most often keep the work, because the skills overlap with what they already run. XWiki Standard is free open source under the LGPL 2.1, so the recurring cost sits in servers, databases, backups, patching and the people who operate them. The official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8, which gives a container team a familiar starting point.

Skills your team needs: Linux administration, container operations, database administration, reverse proxy and TLS configuration, and monitoring.
What a partner adds: Sizing and installation help, a tested backup and restore runbook, and a hardening review before go-live.
What you keep: The hosting account, the database, the upgrade calendar and the on-call rota.
Main recurring cost driver: Staff time for patching and upgrades, which grows with the number of extensions you install and test.

Check whether your team has these skills at the depth an incident would require, and price the on-call load as well as the first build.

Recurring XWiki costs after go-live

This table lists the recurring cost items after go-live for XWiki Standard and XWiki Pro, with who is paid and what to request in a quote. Read it as a checklist: XWiki Standard is licensed under the LGPL 2.1 and carries no license fee, so recurring spend moves to hosting, staff time, extensions and any subscription you choose. Confirm the license of each extension separately, including the xwiki-contrib OpenID Connect extension.

Cost item	Who is paid	One-time or recurring	What to ask for in a quote
Hosting or cloud subscription	XWiki SAS for XWiki Cloud, or your cloud provider or data center for self-hosted infrastructure	Recurring	Whether the XWiki Cloud fee covers backups, patching and the ISO 27001 scope, or what your own servers, storage and network will cost
Pro or support subscription by tier	XWiki SAS	Recurring, usually on a subscription term to confirm	Tier that matches your user count (Starter up to 25 users, cloud only; Basic up to 1,000; Business up to 10,000; Enterprise unlimited) and the term length
Paid Pro applications and connectors	XWiki SAS	Recurring, if included in the subscription; confirm per application	Which applications are included in your tier and which are licensed separately, including Active Directory SSO, Azure AD SSO, File Manager and the Office365 and OnlyOffice connectors
Third-party and xwiki-contrib extensions	Extension authors or vendors, depending on the license	Varies; confirm one time per extension and again at each renewal	License terms for each extension, including the xwiki-contrib OpenID Connect extension, any fees and who maintains compatibility with new XWiki releases
Internal administrator time for upgrades and extension testing	Your staff, or a partner you engage	Recurring, once per upgrade cycle	Estimated effort to test extensions and custom code in a staging instance before each upgrade on the chosen stable or LTS line
Backups and monitoring	Your team, your hosting provider or a managed service	Recurring	Who owns database and attachment backups, restore testing, and monitoring of the servlet container and database, and the retention period
Consulting and training by the day	XWiki SAS	Recurring only when you buy days	Daily rates for consulting (listed at 1200 EUR per day, requires a Business or Enterprise support plan) and training (listed at 1500 EUR per day), and what a billable day includes
Security releases and line upgrades	Your team for applying releases; XWiki SAS for support if subscribed	Recurring	Which release line you are on (stable, LTS or intermediate LTS), its support window, and how security releases are communicated and supported under your tier

What usually inflates XWiki costs after launch

Most XWiki cost surprises come from decisions made early and never revisited: the tier chosen, the apps enabled, the release line in use, and the assumptions about migration and hosting. Each card below names one of these drivers and the check that keeps it from growing into a budget problem.

Outgrowing the user band

XWiki Pro and support subscriptions are sold in bands: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). A tier chosen on today's headcount can be exceeded within a year as teams adopt the wiki. Prevention: forecast named users for the next two to three years, confirm with XWiki SAS how user counts are measured, and ask for the price at the next band before signing.

Paying for unused Pro apps

XWiki Pro bundles applications such as File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros and connectors for Google Apps, Office365 and OnlyOffice, alongside Active Directory and Azure Active Directory SSO applications. Licensing these for every space adds cost without adding use. Prevention: list the business requirements that each app serves, pilot only those, and confirm with the vendor which apps are included in the subscription you are quoting.

Running an unsupported release line

XWiki publishes a stable line, a long term support line and an intermediate LTS line. Staying on a line that has passed its support window pushes security fixes and extension compatibility work into unplanned projects, often at emergency rates. Prevention: pick a release line that matches your upgrade cadence, record its support end in your operations calendar, and ask XWiki SAS what support covers on the line you run.

Extension rework after upgrades

Extensions, custom macros and scripts do not always move cleanly from one XWiki version to the next. Teams that budget only for the platform upgrade often discover that compatibility fixes and retesting take longer than the upgrade itself. Prevention: inventory every installed extension and custom script, test each one on a staging copy before every upgrade, and estimate staff hours for that testing as a recurring line item.

Hosting sized for the pilot

A pilot with a few spaces and a small group of editors rarely shows the load of a company-wide knowledge base with search indexing, attachments and integrations. Hardware or cloud capacity sized for the pilot then needs an unplanned upgrade or a second environment. Prevention: model growth in users, pages and attachment volume, load test with realistic data before cutover, and agree with your infrastructure team who pays for scaling and when.

Treating Confluence migration as one-off

Confluence Migrator Pro transfers spaces, pages, users, groups, permissions and attachments, and keeps page history but not attachment history. Macros that do not map cleanly, and any attachment history you need to keep, require manual rework that is easy to leave out of the budget. Prevention: run a pilot on representative spaces, inventory macros and attachment history requirements before quoting, and budget the rework and validation as a separate phase from the tooling licence.

What you need to provide before a cost model can be trusted

A cost model for XWiki is only as accurate as the inputs behind it, and the most important input is the number of users. XWiki SAS prices support and Pro subscriptions in tiers: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). Provide a current count of named users, the number who only read content, and any guest access. Then give a growth estimate for the planning period, with the assumptions behind it, such as headcount growth or a planned acquisition. Ask XWiki SAS how it counts users in its current terms, because a count that includes or excludes read-only accounts can move you into a different tier.

Next, list the spaces and applications you expect to run. Include the number of Confluence spaces, pages and attachments if a migration is planned, along with the groups and permissions that must carry over. Confluence Migrator Pro is priced from 2,000 EUR according to the XWiki Store, and its trial is limited to 30 pages per migration, so a page inventory is needed before you can estimate tooling cost. Name every feature you expect to use, such as file management, calendars, diagrams, forums, or connectors for Google Apps, Office365 or OnlyOffice. Some of these appear in XWiki Pro and others may be available as free extensions, so mark each one as required, nice to have or undecided and confirm its licensing with the vendor.

Identity and hosting decisions change both the subscription and the labor. Document your identity provider, the protocol it supports (OpenID Connect, LDAP or Active Directory), the directory that holds your groups, and whether you need the Active Directory or Azure Active Directory SSO applications listed for XWiki Pro. The OpenID Connect extension in the xwiki-contrib project is community software, so confirm with XWiki SAS whether it is supported in your setup. Then state your hosting constraints: cloud account, data center or air-gapped network. XWiki SAS states that cloud and on-premises pricing are the same, but infrastructure, patching and backup costs still sit with you unless you choose XWiki Cloud. Include your backup frequency, retention period and recovery targets, since they set storage and staff effort.

Finally, settle ownership and obligations before anyone compares numbers. Name the budget holder for licenses, infrastructure, consulting and training, and the operations owner who will apply upgrades and security releases. Consulting is listed at 1,200 EUR per day and requires a Business or Enterprise support plan, while training is listed at 1,500 EUR per day, so decide early whether internal staff or an outside team will do the work. Record compliance requirements, including the control frameworks, audit dates and evidence your auditor expects. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications. Before you sign, confirm current XWiki SAS pricing directly with the vendor, and ask for a written quote that states the tier, user basis, included support, renewal terms and any price changes.

Questions buyers ask about XWiki cost of ownership

Does XWiki Standard have a license fee for the software itself?

No. XWiki is licensed under the LGPL 2.1, and XWiki Standard is the free open source version, so there is no license fee for the software itself. Your cost of ownership comes from the infrastructure that runs it, the staff time to install, configure, secure, back up and upgrade it, and any support or Pro subscription you choose to add. Hosting, database and servlet container operations, patching, upgrade testing and user support recur over time. Installation, migration work and any integration build are usually one-time costs. Ask your team to list each of these before comparing the total against a subscription.

How much does an XWiki consultant cost per day?

XWiki SAS lists consulting at 1200 EUR per day. That rate requires a Business or Enterprise support plan, so the subscription tier is part of what consulting costs. Ask XWiki SAS to confirm in writing which plan you must hold, whether the subscription fee and day rate are billed separately, and whether the days cover installation and configuration or only advice. XWiki SAS lists training separately at 1500 EUR per day. DeployOpen does not publish a price list. It agrees a fixed scope in writing and the quote follows from that scope, so compare the vendor day rate against a quote built from the same deliverables.

Can our own team build the XWiki cost model?

Yes. The model needs two inputs your team can gather: the tier bands and an inventory of the wiki. Use the user count bands to place your headcount. Starter covers up to 25 users and is available only for XWiki Cloud, Basic covers up to 1,000 users, Business covers up to 10,000 users and Enterprise covers unlimited users. Then list spaces, extensions, apps, integrations and the people who own each one. Price each cost line in your own currency and environment, including hosting, backup storage, staff hours for patching and upgrades, the support subscription and any paid Pro apps. Keep one-time and recurring costs in separate columns. Bring in an outside reviewer when the inventory includes many custom extensions or unusual hosting constraints.

How long does an XWiki cost of ownership model take?

No timeline for this work has been confirmed, so ask for the timeline in the written scope before you commit. The main drivers are the number of users and spaces to inventory, how many extensions and paid Pro apps are in use, how many hosting environments you run, and how quickly your teams can confirm owners and figures. A model covering one small wiki takes less work than one covering several business units with custom extensions and a planned Confluence migration. Ask the provider to name the inputs it needs from you, the dates those inputs must arrive by, and how the schedule changes if an input comes in late.

Do XWiki Cloud and on-premises Pro cost the same?

XWiki SAS states that its cloud and on-premises pricing is the same. That moves the hosting decision toward control, data location and operating effort. Starter is available only for XWiki Cloud and covers up to 25 users. Confirm the current terms in writing, because pricing pages change. Then check whether your infrastructure costs, staff time and compliance requirements differ between the two options. If you run XWiki in your own cloud account or data center, the hosting line in your model is yours to size, and the cost of that environment belongs in the comparison.

What decides which XWiki Pro tier we need?

User count is the main factor. XWiki SAS lists Starter for up to 25 users (XWiki Cloud only), Basic for up to 1,000 users, Business for up to 10,000 users and Enterprise for unlimited users. Count the people who will log in, and confirm with XWiki SAS how it counts users in your case. The tier also affects consulting access, because the 1200 EUR per day consulting rate requires a Business or Enterprise plan. Model the tier you expect to reach within your planning period and ask what changes at each step up. Check your list of paid Pro applications, such as connectors and SSO applications, against the tier you choose.

What does the cost model need from our team?

Four groups of input make the model accurate: users, applications, hosting constraints and owners. For users, provide active and named counts, groups and external guest accounts. For applications, list the extensions, apps and connectors in use, along with any custom code. For hosting, record where data must live, which database and servlet container you run, and any network or air-gap rules. For owners, name who approves spaces and permissions, who patches and upgrades the platform, and who pays the support invoice. Assign one person to collect and check figures from directory exports and the platform itself before the model starts.

How DeployOpen scopes and hands over an XWiki cost model

DeployOpen builds a cost model for XWiki cost of ownership: Standard vs XWiki Pro from your own infrastructure, user counts and required business applications. The output is a written comparison of the Standard and Pro paths that your finance, security and platform teams can review and challenge.

How we scope

Engagements are fixed-scope, with the cost model's inputs, deliverables and timeline agreed in writing before work starts.
We confirm your user count, which determines the XWiki Pro or support tier to compare against Standard.
We list the Pro applications and connectors you actually need, such as SSO, File Manager or Office365, and price each path separately.

How we build

We model infrastructure for the official XWiki Docker image variants you choose, covering database, servlet container and hosting location.
We map internal staff time for installation, extension testing, upgrades and user support under each edition.
We check each cost line against the vendor's current published pricing and flag any figure that needs a written quote from XWiki SAS.

How we hand over

You receive a written cost model with assumptions, one-time costs, recurring costs and the factors that move each line up or down.
We document the Standard and Pro comparison so your team can rerun it when user numbers or applications change.
We walk your finance, security and platform owners through the model and the questions to put to XWiki SAS before signing.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer if you choose to run the platform with us.
We can refresh the cost model when XWiki publishes new tiers, prices or LTS releases that affect your decision.
Support scope, response expectations and retainer terms are set out in writing, so you know exactly what recurs and what does not.