XWiki implementation plan and cost

How an XWiki implementation plan starts with four decisions

A team replacing a shared drive, a legacy wiki or Confluence needs an XWiki implementation plan with a cost before anyone can compare a quote with doing the work in-house. The plan is scoped around four decisions: the release line, hosting and database, the knowledge structure and permissions, and the migration and integration scope. Settle these first, because each one changes the work that follows and the number of people who must be paid or trained to do it. The release line comes first. XWiki publishes a stable line, a long term support (LTS) line and an intermediate LTS line. At the time of research, the official Docker image tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS. Stable receives new features more often, while LTS is chosen when the team wants a longer maintenance window and fewer forced upgrades. Ask which line your extensions and migration tooling support before choosing. Hosting and database come second. The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Your database standard, backup tooling and servlet container policy will usually decide the variant. Confirm with your platform team which database engine they already operate and support, since a mismatch adds build and operations work. The third decision is the knowledge structure and permissions. Decide how spaces map to departments, projects or products, who creates spaces, and which groups hold edit and view rights at wiki and space level. Permission design is often where internal effort grows, because it requires agreement from data owners. The fourth decision is migration and integration scope: whether content moves from Confluence or a legacy wiki, which identity provider signs users in, and which extensions or connectors are required. Outside help is most often needed when a Confluence migration, directory integration or regulated audit trail must be delivered on a fixed timeline, or when the in-house team has not run a Java application server before. Otherwise, a capable internal platform team can deliver the work, while a partner is usually engaged for a fixed-scope piece with written deliverables.

What an XWiki implementation includes and what you receive

A fixed-scope XWiki implementation is built from a set of work packages, each with a named deliverable. The scope, deliverables and timeline for every package are agreed in writing before work starts, so you can compare the work against your own team's effort and see what you own at handover.

Environment design and sizing

Environment design fixes the stable or LTS line, the database variant (MySQL, PostgreSQL or MariaDB), the servlet container and the hosting target inside your own cloud account, data center or air-gapped network. You receive a written architecture document covering components, network paths, storage and environments for development, test and production. Confirm which XWiki line your standards allow and which database your operations team already supports before this package is priced.

Installation from image or package

Installation deploys XWiki from the chosen official Docker image tag or from a supported package, with the database and servlet container wired together and pinned to a known version. You receive a configured, reproducible deployment and build or deployment scripts you can rerun. Ask how image tags are pinned and how the team will apply future security releases, because that decision shapes the upgrade effort later.

Configuration and baseline hardening

Configuration sets the instance-level settings that govern how the wiki behaves, including guest access, scripting rights, mail, attachments and the default skin. You receive a configuration record and a list of every changed setting with its reason. Confirm which settings your security team must sign off on, since these choices feed later control evidence.

Space and permission model

The space and permission model defines the top-level spaces, the naming pattern, which groups hold view, edit and admin rights at wiki, space and page level, and where deny rules are allowed. You receive a documented space model and a rights matrix that maps each group to its permissions. Agree the model with business owners before pages are migrated, because changing rights later touches every space it inherits to.

Identity, extensions and backup

Identity and extension setup connects XWiki to your directory or OpenID Connect provider, installs the approved extensions and records their versions. Backup and monitoring configure database and attachment backups, restore tests and health alerts. You receive configured authentication, an extension inventory and a backup and monitoring runbook with restore steps. Confirm which extensions are free, which need a paid XWiki Pro license, and which are community contributions you must review yourself.

Testing, admin training and handover

Testing verifies login, rights, search, backup restore and upgrade paths in a staging environment before go-live. Admin training and handover transfer operating knowledge to your administrators, with the runbooks, a support escalation path and a list of open items. You receive test evidence, training material delivered to your administrators, and a handover pack. Ask who owns support after go-live, since XWiki SAS support and internal staff are separate cost lines.

What drives XWiki implementation cost and duration

This table lists the main factors that change XWiki effort and cost, why each one matters, and how to keep it under control. Use it to prepare scoping questions before you ask for a fixed-scope quote. The main takeaway is that identity scope, migration scope and environment count are settled early and are costly to change later.

Driver	Why it moves effort	How to keep it down
Users and edition tier	Pro tiers are Starter (up to 25 users, cloud only), Basic (up to 1,000), Business (up to 10,000) and Enterprise (unlimited) per XWiki pricing. Tier sets support scope.	Count active users and confirm the tier before scoping support hours.
Content volume and attachments	More pages, spaces and attachments lengthen import testing, search index rebuilds and storage sizing. Attachment history often needs rework.	Prune stale spaces before migration and agree which attachment versions must move.
Confluence or other migration	Confluence Migrator Pro is priced from 2000 EUR (XWiki Store). Its trial covers 30 pages per migration. Macros often need manual rework.	Run a pilot space first and write down what transfers and what does not.
Identity integration	OpenID Connect, LDAP or Active Directory each need directory configuration, group-to-rights mapping and test logins. The xwiki-contrib OIDC extension is a community option to confirm.	Choose one directory and one protocol for the first release, and confirm extension support for your provider.
Custom or paid extensions	Pro applications such as connectors and Active Directory SSO add licensing and testing. Custom code adds maintenance at every upgrade.	List required extensions early and use standard applications before writing custom code.
Number of environments	Each environment needs its own database, servlet container, configuration and data refresh process. Staging setup often takes as much effort as production.	Keep environments identical by using the same image tag and configuration management for each.
Compliance evidence needs	Access reviews, change records and restore tests must be produced and retained for assessors. Auditors, not the implementer, issue any opinion.	Agree the evidence list and retention period in writing before the build starts.
Hosting model	Self-hosting in your own cloud, data center or air-gapped network adds infrastructure, patching and monitoring work. XWiki Cloud moves hosting to XWiki SAS.	Confirm who patches the servlet container and database, and where backups are stored.

Choosing stable, LTS or intermediate LTS before the build

The XWiki release line is the first decision in the plan because it sets the image tag you pin, the extensions you can install, and the upgrade calendar your team will carry after go-live. XWiki publishes three lines: stable, long term support (LTS) and intermediate LTS. When this page was researched, the official Docker image tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS. Tags change with each release, so confirm the current tags on the official Docker image repository before you write them into a scope document or a quote.

The line you choose drives upgrade frequency. A stable line receives new releases more often, so each upgrade is usually a smaller step, but your team will be asked to plan and test upgrades more frequently. An LTS line moves less often and is intended for organizations that want fewer change events, at the cost of running a line that is older than stable. The intermediate LTS sits between the two. Before deciding, check the release cadence and support windows for each line on xwiki.com, because those dates determine how long a pinned version stays supported and how many upgrade cycles fall inside your planned operating period.

Extension compatibility is where the choice has the most effect on effort. Every extension in your plan, including any XWiki Pro applications you license, must be verified against the chosen line. An extension that works on stable may lag on LTS, and the reverse can also happen as the lines diverge. Build a test environment with the full extension set, the same database variant and the same servlet container as production, and rehearse an upgrade to the next release on that line. Record each extension's compatibility result in the plan. This testing is recurring work, so include it in the cost model as an ongoing item rather than a one-time build task.

Who carries the upgrade work depends on the contract. In a self-hosted deployment, your platform team normally owns execution, testing, backups and rollback, and XWiki SAS offers on-premises support and installation help that can cover parts of that work. DeployOpen can plan and execute upgrades inside your infrastructure under a retainer or a fixed-scope engagement. In the quote, ask which line is recommended and why, who runs each rehearsal, how many upgrade cycles are included in the period you care about, and what happens if an extension is incompatible with the target release. Settle the line in writing before the build starts.

Implementation phases and the output of each

The sequence moves from agreed requirements to a tested, documented XWiki instance that your team can operate after handover. Each phase closes with a named output, so you can check progress against the written scope at every gate.

Run discovery and capture requirements
DeployOpen works with your content owners, security team and identity administrators to record what the wiki must hold, who uses it, which systems it must connect to and which rules apply to the data. The main decisions are whether to use the stable line or an LTS line, how many users and spaces to plan for, and whether a Confluence move is in scope. The output is a signed requirements document that lists in-scope and out-of-scope items, open questions with owners, and the acceptance criteria that later phases will be tested against. The phase is complete when your sponsor has approved that document in writing.
Design architecture and size the platform
Using the requirements, DeployOpen proposes the target architecture inside your infrastructure. This covers the XWiki release line, the database variant (MySQL, PostgreSQL or MariaDB, each running on Tomcat in the official Docker images), the servlet container configuration, file and attachment storage, backup targets and retention, and the reverse proxy and TLS layout. Sizing is based on user counts, expected attachment volume and search load, and it should be validated by your platform team against their own standards. The output is an architecture decision record and a sizing note. Confirm the exact resource figures with your infrastructure team, because they depend on your hosting platform.
Design spaces and permissions
DeployOpen drafts the space hierarchy, naming rules, template pages and the rights model across wiki, space and page levels. Groups are mapped to the roles your organization already uses, and the design records where allow and deny rules are needed and where inheritance is enough. Guest access and scripting rights are set to a documented default at this stage. Your content owners review the draft against real use cases. The output is a space and permission specification that the build phase implements exactly, along with a list of the groups that must exist in your directory before go-live.
Build and configure in a non-production environment
DeployOpen deploys XWiki in a non-production environment in your cloud account, data center or air-gapped network, using the architecture decision record. The build covers the chosen image and database, storage, backup jobs, the space structure, templates, and the approved set of extensions. Configuration is kept in version-controlled files where possible so the environment can be rebuilt. The output is a working non-production instance and a configuration record listing every setting that differs from defaults. The phase is complete when a fresh deployment from the same files reproduces the instance.
Set up identity and extensions
DeployOpen connects XWiki to your identity provider, using the method chosen in discovery, such as OpenID Connect through an extension like xwiki-contrib/oidc, LDAP or Active Directory. Directory groups are mapped to the XWiki groups from the permission design, and each extension is installed, version-pinned and checked for compatibility with the chosen XWiki line. Where a commercial application from XWiki Pro is required, your team confirms licensing separately. The output is a tested login flow, a group mapping table and an extension register with versions and owners. Confirm with your identity team which protocol and attributes they support before this step starts.
Run a pilot with real content
A small set of spaces is loaded with real content and used by a named pilot group for an agreed period set in the written scope. DeployOpen supports the pilot team, records defects and usability issues, and checks search results, permissions and attachment handling against the requirements. If a Confluence move is part of scope, the pilot spaces are the test set for that move. The output is a pilot report listing defects by severity, decisions taken, and changes made to configuration or permissions. Changes made during the pilot are rebuilt in the configuration record, not applied by hand.
Execute acceptance testing
Acceptance tests are run against the criteria signed in the requirements document. They typically cover login and group mapping, space and page permissions for each role, backup and restore of a sample instance, search behavior, email notifications, and the recovery steps in the runbook. Your team signs off each test, and any failed test is either fixed and retested or formally accepted as a known issue. The output is an acceptance test record with results, evidence and sign-off names. Security testing scope, if you have bought it, runs in this phase and its findings are tracked to closure.
Cut over and hand over
The production instance is built from the same configuration files used in the tested environment, content is migrated or loaded in an agreed window, DNS and access are switched, and the first backup is verified by restore. DeployOpen then hands over the operational documentation: architecture, configuration record, runbooks for backup, restore, upgrade and extension changes, the permission model, and the known-issues list. Your operators are trained on the runbooks. The output is a live production instance, a handover package and a signed handover record. Support after go-live, if wanted, is agreed separately in the written scope.

Which XWiki implementation work teams keep in-house and which they outsource

This table maps each part of a self-hosted XWiki rollout to the team that usually does it, the skills it needs, and where outside help adds the most value. Read the last column as a starting point for scoping, then adjust for your own staff and existing platforms.

Work area	Skills required	Who usually does it and where outside help adds value
Platform administration (servlet container, database, Docker or VM hosting)	Linux operations, servlet container operations such as Tomcat, database administration for MySQL, PostgreSQL or MariaDB	Usually in-house, since it runs daily. Outside help adds most value at the initial build and at the first upgrade, when the chosen stable or LTS line is installed and tested.
Space structure and permission design	XWiki rights model across wiki, space and page levels, information architecture	Usually a joint effort. Content owners and an architect define the space tree, then an outside specialist can review the rights design before it is locked in, since mistakes are costly to unwind.
Confluence migration	Confluence data model, XWiki import tooling, macro mapping, cutover planning	Often outsourced when the volume is large. XWiki SAS offers Confluence to XWiki migration services and sells Confluence Migrator Pro. Confirm what each option transfers and what manual rework remains.
Identity integration (SSO and directory groups)	Identity protocols such as OpenID Connect, LDAP or Active Directory, group-to-rights mapping	Usually in-house with the identity team, who own the provider. Outside help adds value when mapping directory groups onto XWiki rights, which requires both protocol and rights expertise.
Extension selection and testing	Extension ecosystem knowledge, XWiki version compatibility, staging environment operations	Usually in-house for low-risk extensions. Outside help adds value for paid Pro applications or when a custom extension must be validated against the chosen XWiki release.
Security configuration	Servlet container hardening, database access control, guest access and scripting rights settings, extension review	Shared. Internal security staff set policy, while an outside tester can verify the configuration and review installed extensions with an independent view.
Backup and restore testing	Database administration, file store backup, restore runbooks	Usually in-house, since the operations team owns recovery. Outside help is most useful in planning the first full restore test, which should be run and recorded before go-live.
User training and content owners' work	Information architecture, documentation practice, facilitation	Usually in-house, because content owners know the material. XWiki SAS offers training, which can be bought for administrators or trainers, but local champions usually carry the ongoing work.

What goes wrong in XWiki rollouts and how to prevent it

Most XWiki rollout problems are decided early, in release selection, space design and rights, and then surface months later as upgrade work, access complaints or restore gaps. The cards below cover the failure points we see most often in scoping, with the prevention step and the person who should confirm it before build starts.

Release line without an upgrade plan

XWiki publishes a stable line, a long term support line and an intermediate LTS line, and the release you pick sets how often you must upgrade. Choosing a line without a written upgrade cadence leaves the wiki on an unsupported version later. Before go-live, confirm which line you are on, who will test and apply upgrades, and how extensions will be checked for each release. Owner to confirm: head of platform engineering.

Flat space structure and unmanageable permissions

A wiki with every page in one flat set of spaces makes rights hard to reason about, because access is inherited through the space and page hierarchy. Once hundreds of pages carry local exceptions, nobody can say who can see what. Agree the top-level space taxonomy and the group model on paper first, then limit page-level overrides to documented cases. Owner to confirm: knowledge management lead with the security architect.

Broad scripting and guest rights

Granting script rights or guest edit access to large groups lets users run server-side code or change content anonymously, which turns a documentation tool into an attack surface. Scripting rights should sit with a small, named group, and guest access should be explicitly limited to what the business needs. Review these rights during the rights design and again after each migration batch. Owner to confirm: CISO or security engineering lead.

Unsized database and backup gap

XWiki runs on a relational database and a servlet container, and both need sizing for page history, attachments and search indexes. A database chosen only for the install, with no tested restore path and no backup of attachment storage, leaves recovery undefined. Document the database engine, its growth assumptions, and a restore test that covers both the database and the files. Owner to confirm: database administrator and infrastructure lead.

Unreviewed third-party extensions

Extensions and applications add features but also code that must be patched, tested against each XWiki release and assessed for data access. Installing extensions because they seem useful, without an owner or an update path, makes upgrades risky. Keep an inventory with the version, owner, data access and upgrade status for each extension, and review new ones before they reach production. Owner to confirm: application owner with the security team.

Underestimated migration rework

Moving content from another wiki often looks like a copy job, but macros, attachment history, user mappings and broken links usually need manual work after the automated transfer. Scope the rework by sampling pages from each space before committing to a timeline or budget. Agree which content is migrated, which is archived and which is retired. Owner to confirm: content owner for each business area with the project manager.

Skipping an upgrade rehearsal

Teams that upgrade XWiki directly in production often discover extension conflicts, database changes or customized templates only after users report errors. A rehearsal on a copy of production data, with the same extensions and database engine, shows these problems while there is time to fix them. Schedule a rehearsal before every planned upgrade and record the rollback steps. Owner to confirm: platform engineering lead with the business service owner.

What XWiki costs to run after go-live

The first cost question is which license model you are running, because it decides what recurs after go-live. XWiki Standard is the free open source edition under the LGPL 2.1, so there is no license fee. Your recurring costs are then internal staff time, hosting, database and servlet container operations, backups, and the time your team spends applying releases and testing extensions. Budget these as ongoing line items, not as a one-time build. Ask your team to name who owns patching, who restores from backup in a test, and how many hours per month that work realistically takes in your environment. Those hours are the largest recurring cost on the Standard path, and they are easy to undercount because they are spread across several people. XWiki Pro changes the picture by adding a subscription. XWiki SAS sells Pro and support subscriptions in four tiers: 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. The vendor states that cloud and on-premises pricing is the same. That statement matters for a self-hosted plan, but confirm in writing that it applies to your tier and user count, and confirm which tier includes the support hours and response commitments you need. Starter is not available for self-hosted deployments, so an on-premises rollout starts at Basic. Pro also brings paid add-ons that are separate from the subscription tier. The Pro offering lists Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros, and Google Apps, Office365 and OnlyOffice connectors. Do not assume these are all included in the subscription you are quoted. For each one you plan to use, ask whether it is covered by your tier or priced separately, and whether it has a recurring fee. Consulting and training are also billed separately: XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support plans and training at 1500 EUR per day. When you request a quote, ask for a line-item breakdown with the following: the Pro tier and the user count it covers, whether the price is annual or multi-year, which add-ons are included and which are extra, whether self-hosted support is covered and at what response level, what consulting days are included or optional, and any migration tooling such as Confluence Migrator Pro, which XWiki SAS prices from 2000 EUR. Ask how price changes are handled at renewal and how user growth between renewals is billed. Also ask your internal team to estimate its own hours for upgrades, backups and extension review, so you can compare Standard and Pro on the same total cost of ownership basis.

How the XWiki plan changes by starting point and environment

If you are moving from Confluence, the migration tool shapes the plan more than any other factor. Confluence Migrator Pro, from XWiki SAS, transfers spaces, pages, users, groups, permissions, attachments and metadata. It keeps page history but not attachment history. The XWiki Store lists the tool from 2000 EUR, with a trial limited to 30 pages per migration.

Scope the trial: the 30-page limit means a proof of concept should select pages that exercise macros, attachments and permissions, not a bulk run.
Plan for attachment history: if teams rely on earlier attachment versions, decide how to archive them before cutover.
Map users and groups early: confirm how Confluence users and groups will match your identity source, because permissions depend on it.
Ask about license scope: confirm whether the price covers one migration or several, and what the quote includes beyond the tool.
Reserve rework time: macros and layout differences need review by space owners after transfer.

Confirm the transfer list, trial terms and license scope with XWiki SAS before you fix the migration schedule. The sibling migration topic covers pilot spaces and cutover.

What you need to provide before a fixed-scope quote

Scope cannot be written until the client has supplied a short list of facts about its own environment. The first item is infrastructure access and the hosting target. The infrastructure owner (usually the head of platform or cloud engineering) should confirm which cloud account, data center or virtual network will host XWiki, which Linux and container runtime versions are approved, and whether the team can pull the official XWiki Docker images from a registry the organization controls. If the environment is air-gapped, the image mirroring process must be agreed up front, because it changes the build and upgrade sequence.

Next, confirm the database and servlet container standards already in use. The database administrator should state whether MySQL, PostgreSQL or MariaDB is the approved engine, since the official Docker images come in those three variants, each running on Tomcat. The platform team should state the approved Tomcat or container image lineage and whether a managed database service is mandatory. Each choice determines the image variant, backup tooling, and the patching calendar, so it must be fixed before the work breakdown is written.

Identity details come next. The identity team should name the identity provider (for example, Active Directory, Entra ID or another OpenID Connect provider), the directory owners who approve group changes, and whether guest access is expected at all. Decisions on guest access and edition tier also belong here: the business owner and the CIO should decide whether XWiki Standard is sufficient or whether XWiki Pro applications and support tiers are needed. Those decisions change which connectors, support plan and user-count tier are quoted.

A content inventory is the input that most affects effort. Ask the current wiki or document owners for the number of spaces, approximate page counts, total attachment volume, and a list of macros, applications and scripts in use. Each space should have a named business owner, who approves its structure and who will decide which pages are retired instead of migrated. Without these owners, permission design and content cleanup stall after the quote is signed. Finally, the security or operations lead should state backup and retention requirements, including recovery point and recovery time targets, and agree a test window for cutover and penetration testing. Confirm each figure internally; DeployOpen will not assume a retention period or window on your behalf.

XWiki implementation questions buyers ask before hiring help

What drives the cost of an XWiki implementation project?

Scope drives most of the cost: how many spaces, pages and users move in, which identity provider you connect, which extensions or Pro applications you need, and how much custom work is involved. One-time costs include design, installation, configuration, data migration, testing and handover. Migration is a major variable. XWiki SAS lists its Confluence Migrator Pro from 2000 EUR, so any tooling cost sits alongside the services effort to clean up macros and permissions. Recurring costs include hosting in your own infrastructure, database and backup operation, any XWiki support subscription you buy, and internal staff time for upgrades and extension testing. Ask every partner to split the quote into these groups so you can see what recurs each year.

How long does an XWiki rollout take, and what sets it?

The timeline follows the written scope, and no single duration fits every XWiki project. The main drivers are the number of spaces and how complex their structure is, whether a Confluence migration is included and how many pages need manual rework, the identity integration, how many extensions must be tested, and how quickly your team can approve decisions and schedule change windows. A pilot on a standard setup with one team moves faster than a multi-department rollout with single sign-on, permission mapping and migrated history. Ask each partner for milestones with the dependencies they assume, then check those dependencies against your own approval calendar before you commit to a date.

Can our internal team install and run XWiki without outside help?

Yes, for a small, standard setup with no migration and no complex identity integration, an internal team can do it alone. The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8, so the base installation is well documented. The skills you need are Linux administration, container or servlet container operations, database administration and backups, reverse proxy and TLS configuration, identity integration if single sign-on is required, and XWiki administration covering rights, extensions and upgrades. Confirm that those skills exist in-house for the whole lifecycle, including applying security releases and testing extensions before each upgrade, not only for the first install.

What must our team provide before an XWiki project starts?

The schedule depends on access and decisions from your side. Typically the client provides infrastructure in its own cloud account, data center or network, including hosts or a container platform, a database service, DNS and certificate management. You also need administrative access and agreed change windows, an identity provider contact and directory details if single sign-on is in scope, and a named business owner who approves the space structure and permission design. Content owners for each space, a Confluence export or read access for migration, test users, and a decision on the XWiki line (stable, LTS or intermediate LTS) belong on the list too. Delays often come from slow approvals and unclear ownership, so put these inputs and owners into the written scope.

Should we choose XWiki Standard or XWiki Pro for our rollout?

Choose XWiki Standard if the free open source edition covers your needs and you can support it internally. XWiki Standard is licensed under the LGPL 2.1. Choose XWiki Pro when you need its business applications or connectors, such as Active Directory or Azure Active Directory single sign-on, File Manager, Calendar, Diagram or the Office365 and OnlyOffice connectors. XWiki SAS prices Pro and support subscriptions in tiers by user count: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). XWiki SAS states that cloud and on-premises pricing is the same. Compare the Pro applications you actually need against the subscription tier for your user count, and include internal staff time in the comparison.

Does the 1200 EUR per day XWiki consulting rate apply to us?

XWiki SAS lists consulting at 1200 EUR per day, and that rate requires a Business or Enterprise support plan. It is XWiki SAS's own list rate, so it applies only when you buy consulting from XWiki SAS under that support plan. It does not set the price of an implementation quote from another firm. Check two things before you assume the rate applies: whether you hold or plan to buy a Business or Enterprise support plan, and whether the work you need is consulting from XWiki SAS or a separate implementation engagement. Ask any partner to state its own day rate or fixed fee in writing, with the assumptions behind the effort, so you can compare it with the XWiki SAS rate on equal terms.

How should we compare XWiki implementation partner quotes side by side?

Compare the written scope before comparing totals. Check that each quote names the same XWiki line, the same database and servlet container, the same number of spaces and users, and the same migration and identity work. Then look at deliverables such as installation, configuration, space structure, permissions design, testing, documentation and handover, along with what is excluded. Separate one-time services from recurring items such as hosting, support subscriptions, Pro applications and upgrades. Note how each partner handles change requests, who owns the risk when scope grows, and what support runs after go-live. A quote that looks lower but leaves out migration, testing or handover often costs more once the gaps are filled.

How DeployOpen scopes, delivers and hands over an XWiki implementation

DeployOpen plans, implements, hardens, documents and supports self-hosted XWiki inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Work starts from a written scope that fixes the XWiki line, database, servlet container, space structure and permissions before any build begins. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

Confirm the XWiki line (stable or LTS) and the upgrade cadence your team can sustain.
Agree the database variant and servlet container, and where each runs in your environment.
Map spaces, page types, groups and rights so the written scope names every permission model to build.

How we build

Install and configure XWiki in your infrastructure using the official Docker images or your approved packaging.
Set up authentication, extensions and any Confluence migration as separate, testable work items.
Test search, permissions and backups against the agreed scope before any users are onboarded.

How we hand over

Deliver architecture, configuration and runbook documentation covering installation, upgrades and backups.
Walk your administrators through space structure, rights assignments and extension management.
Record the agreed acceptance tests and the open items that remain after go-live.

How we support

Offer ongoing support, security patch application and upgrade testing as a retainer after go-live.
Retest extensions and permissions before each XWiki upgrade so changes are checked before production.
Confirm with your team which support tier and XWiki SAS subscriptions, if any, sit alongside our work.