All questions answered

We have developed tools to avoid manual editing of pages post-migration. The most common post-migration fix that would need to be done is handling macros that do not exist on the XWiki side. This can be achieved via batch rename scripts, or the creation of the specific macro on the XWiki side.

The Confluence Migration Toolkit migrates user accounts and group references stored in Confluence, including AD-synced accounts. Once XWiki is connected to the same LDAP/AD, these accounts align again and permissions continue to work.

Alternatively, you can use the Pro Active Directory Application to import users and groups directly from AD, independently of the Confluence migrator.

XWiki supports friendly URLs. By default, it generates human-readable URLs based on the page hierarchy and page names rather than numeric IDs. For example, a typical URL might be /xwiki/bin/view/Projects/Documentation instead of using numbers. However, the URL format can be customized based on instance configurations.

For Comala-style publishing, the closest XWiki options are Publication Workflow and Change Request. For Scroll Viewport, the functional behaviour can be recreated by creating internal and external sections or wikis. Note that Scroll Versions has an equivalent in XWiki, called Book Versions, and data can be migrated from the Confluence plugin to the XWiki extension.

Not at the moment. There are no direct video conferencing connectors built into CryptPad today. In practice, it can be used alongside tools like Jitsi or BigBlueButton rather than through a native integration.

Could OpenProject be used as a service desk for handling service requests, incidents, incoming emails, similar to Jira Service Management?

OpenProject currently provides lightweight IT Service Management functionality. You can manage service requests, incidents, and internal support tasks using customizable workflows, priorities, and roles, all within the same secure, open-source platform used for project management.

While OpenProject is not yet a full ITSM solution, it is a key area of ongoing development. We’re continuously expanding these capabilities to better support service-oriented teams and organizations. As an open-source product, customers and community actively influence the roadmap, helping shape the future of ITSM features and other enhancements.

XWiki doesn’t impose artificial limits on users or groups. Scaling depends on infrastructure and tuning (caching, indexing, clustering). It runs in environments with large user bases and complex group structures.

We can't update CKEditor to version 5 because of a license incompatibility (CKEditor 5 is GPL, while XWiki is LGPL).

However, we are planning to replace CKEditor with BlockNoteJS to improve the editing experience later this year. Delivery will likely happen around Q1 2027, as we want to avoid breaking the current editing experience.

For further details, you can check the forum thread where BlockNote has been discussed publicly as a future rich editor direction.

Also, you can test the experimental BlockNote Integration extension.

OpenProject already offers an integration with GitLab (see answer above). While there is no integration with Forgejo planned, OpenProject also offers a web view to directly display a Git repository. Refer to the guide.

Yes. A community extension called Review Pages allows teams to define review cycles and track documentation that requires validation.

In addition, modification dates and activity history are tracked by default. When combined with tools such as Analytics Application (Pro), teams can identify inactive or outdated content and implement structured review processes.

Yes. You can keep the entire wiki private and selectively open certain pages to unregistered users, as detailed in our documentation. Alternatively, you can create a separate public subwiki dedicated to product documentation.

Yes, XWiki Cloud includes daily automated backups as part of the managed service.

The security and compliance page also mentions proactive monitoring, antivirus scanning, regular security maintenance, continuous infrastructure monitoring, centralized logging, encrypted backup redundancy, cold storage solutions, and tested restoration and disaster recovery procedures.

This is one of the main reasons teams choose XWiki Cloud: They can start using XWiki without managing hosting, backups, upgrades, monitoring, and maintenance themselves.

XWiki already models roles through groups and rights (admin, editor, reader, etc.) at wiki/space/page level. The roadmap focuses on making rights easier to manage rather than introducing a separate roles layer mirroring Atlassian’s UI.

Not cleanly, at least not yet. Prototypes related to this exist, but there is currently no funded implementation plan. In the meantime, the suggested workarounds include access lists, making a copy, and destroying the original document. The Access List is a way to restrict access so that users who are not on the list cannot open the document, even if they already have it in their CryptDrive.

Historically, CryptPad has relied primarily on strong encryption to manage access control. An actor possessing the symmetric key associated with a channel is generally considered to have irrevocable access to its contents.

Not at the moment. CryptPad supports several identity scenarios through SSO, but not this kind of Active Directory discovery. It is an interesting feature and something the team would be open to in the future, but it's not currently a roadmap priority.

XWiki provides:

– The Administration Application for rights at wiki/space/page level and page/attachment indexes.

– The Pro Admin Tools Application for advanced rights overviews.

– The community Page Rights Viewer to quickly see effective rights on a page.

Yes, XWiki can be used to bring a collection of Word, Excel, PowerPoint, PDF, and other Office files into a structured knowledge space.

One option is to simply store the files as attachments in XWiki pages, organized through spaces, pages, tags, metadata, and navigation rather than relying only on nested folders. This makes it easier to connect documents with related procedures, project information, ownership details, or update notes, and to search across the knowledge base.

Depending on the intended setup, Office documents can remain files that people download or open from XWiki, or they can be embedded and edited through an office integration such as Collabora or OnlyOffice.

A second option is to convert office files using the Office Import functionality into XWiki pages, which are easier to search, link, version, and maintain collaboratively.

A third option is batch migration, if your MS Office setup allows CSV export. The Batch Import Application can be used to migrate a full set of office documents into structured XWiki pages (with metadata), as demonstrated in this SharePoint migration guide.

The right migration approach depends on the file volume, folder depth, permissions, naming quality, and metadata requirements. The organization should decide whether it wants to preserve the current structure or redesign it into a more useful knowledge model.

A short assessment is usually required to define the import approach. This helps identify which documents should remain files, which should become XWiki pages, and how permissions and navigation should be set up.

Yes, access rights can be managed at wiki, space, and page level, for individual users or groups. You can decide who is allowed to view, comment on, edit, delete, or administer a given area. This makes it possible, for example, to keep internal procedures and project discussions private while giving a customer group access to selected documentation pages or a dedicated customer space.

In practice, there are a few common approaches:

• Create a dedicated customer space or subwiki and give access only to the relevant customer group.
• Keep internal areas restricted and expose selected documentation to authenticated external users.
• Make selected documentation public by granting view rights to guest users, where anonymous access is appropriate.

For customer-specific documentation, a dedicated subwiki is often easier to manage than opening individual pages one by one. It makes permissions, navigation, and future maintenance clearer, especially when several customers need different access levels.

One important detail: access rules are inherited through the hierarchy. A child page can be made more restrictive than its parent, but it cannot be opened to people who do not already have access to the parent area. So the content structure and permissions model should be planned together from the start.

Technically, IP restriction can be possible, but it depends on the XWiki Cloud offer and setup.

IP allowlisting is an infrastructure-level requirement, so it should be confirmed with the XWiki Support team before choosing or configuring your offer. If your organization cannot expose the instance to the general internet, raise this requirement early so the team can confirm which XWiki Cloud offer is eligible, or whether a custom/private deployment or self-hosted setup would be more appropriate.

The XWiki OpenProject Integration (Pro) can display OpenProject work packages directly in XWiki pages using the OpenProject macro.

You can choose which work packages to show by filtering on properties such as project, type, status, creator, assignee, or identifier. You can also sort the results, set a display limit, and select which work-package properties should appear in the view. Filters can be configured directly in XWiki or based on a filtered work-package URL copied from OpenProject.

The macro currently supports 3 display modes:

• A table view for a structured list of work packages
• A card view for a more visual overview
• A single-item view for showing one work package in more detail

This makes it possible to include selected OpenProject information in documentation pages, for example requirements, open actions, project risks, milestones, or work packages related to a specific decision or feature. OpenProject remains the place where the work packages themselves are managed, while XWiki provides the surrounding documentation and knowledge context.

There are a few current limitations to keep in mind:

• The single-item view displays only the first work package returned by the selected list.
• Saved OpenProject queries referenced through query_id are not currently supported by the macro.
• Data retrieved from OpenProject is cached for 2 hours, so recent updates may not appear immediately in XWiki.
• When filters are defined both in OpenProject and in XWiki, the XWiki filters are applied in addition to the OpenProject filters.

Only within the same spreadsheet document, across tabs. Cross-document linking of that kind is not possible at the moment because the server does not know the content and cannot move data between documents on the user’s behalf. The same limitation is why form results cannot be kept automatically in sync with a separate spreadsheet.

Yes, OpenProject work-package views can be configured with filters, including project-related filters. The XWiki integration can also retrieve work packages from the broader instance or from a specific project, then apply filtering and sorting.

Yes, backlog items can be ranked either via drag and drop or by changing the respective position via the context menu. Each entry in a backlog and sprint has a position assigned (which can be displayed in the work package list).

XWiki and OpenProject can both be connected to a central identity system, such as LDAP or Active Directory, or to a shared single sign-on provider.

From the XWiki side, LDAP authentication is available, and XWiki can also authenticate through OpenID Connect providers, including setups based on Keycloak, Microsoft Entra ID, or similar identity platforms. XWiki can synchronize user information and groups, depending on the authentication setup.

From the OpenProject side, LDAP connections are supported. OpenProject also supports OpenID Connect and SAML single sign-on as enterprise add-ons. LDAP group synchronization is available as an enterprise feature, allowing memberships from LDAP or Active Directory to be synchronized with OpenProject groups.

The XWiki–OpenProject integration uses OAuth. When someone accesses OpenProject data from XWiki, they authenticate with their OpenProject account, and the integration applies the permissions of that OpenProject account. This means users only see work packages they are allowed to access in OpenProject.

For most organizations, the recommended approach is to connect both tools to the same LDAP, Active Directory, Keycloak, Entra ID, or other identity provider, then manage access rules in each application according to its own permission model.

Yes, you can choose to create a page through the change request workflow or without it. The Change Request extension allows you to request changes on a page without publishing them right away: People have to approve the changes to publish them.

It can be used where review and approval are needed, while other areas can keep a regular editing workflow. Also, it can be complemented by Change Request Replication, an extension which ensures that all events coming from Change Request are properly replicated whenever the page is subject to changes is itself replicated.

Not at the moment, if ECS refers to an S3-style object storage backend such as Elastic Cloud Storage. CryptPad relies on append-only log reads and writes that do not map well to that kind of storage, so this is not currently supported and is not on the roadmap at the moment.

This came up as a use case rather than a technical question. The session itself was meant to demonstrate that kind of scenario: secure collaboration, private sharing, and team workflows built around end-to-end encryption.

XWiki and CryptPad will continue as separate products. For public documentation websites, XWiki is the better fit, since building public documentation in CryptPad through shared links would become complicated.

Yes, it can, but it is not officially supported. Podman is used by some people with CryptPad, though no detailed setup guidance was given during the webinar.

Absolutely! Pro Applications are business-ready extensions developed and maintained by XWiki SAS and they are included by default in the Basic, Business, and Enterprise support plans.

If you choose the Starter plan, you can customize your wiki instance by selecting from our collection of business apps and integrations that can be installed on top of XWiki starting at 95€/year per app. Mix and match according to your needs and build a knowledge management and collaboration software tailored to your team's workflow.

Yes. When you make a purchase, you'll have the possibility to click a checkbox saying "I want to keep my DEMO data".

Yes, you can get a refund for XWiki Cloud during the first month for monthly subscriptions and within 30 days of payment for annual subscriptions.

Sure. You can try an XWiki demo by going to try.xwiki.com and create a free test instance (no credit card required). You have 4 hours to validate the instance in order to have a 10-day trial. You can also extend your trial 2 more times. This way, you get a total of 30 trial days.

XWiki supports several import options, and dedicated migration services are available for more complex projects, including Confluence migrations.

The right approach depends on your source platform, content structure, permissions, attachments, and project scope.

Yes. XWiki’s Solr-based search supports AND, OR, NOT, field-based queries, wildcards, parentheses and fuzzy queries. Default behavior is OR, but you can explicitly use boolean operators in uppercase.

We don't support storing XWiki attachments in Nextcloud out of the box, but we will soon work on a full integration with NextCloud. 

It's possible to use XWiki as the wiki for OpenProject. OpenProject GmbH and XWiki SAS are actually both working on integrations as we speak. Actually, you can already test the Beta version of the OpenProject Integration (Pro).

This needs to be assessed and tested as part of the migration. We cannot guarantee that existing Jira–Confluence links will automatically become OpenProject work-package-XWiki page links in every environment.

The result depends on how the links are stored in Jira and Confluence. They may be standard issue or page links, URLs inside page content, macros, custom fields, comments, Marketplace-app data, dashboards, or custom scripts. It also depends on whether the related Jira issue and Confluence page are both migrated and whether their identifiers can be mapped reliably.

The practical approach is to make link preservation an explicit migration requirement. We would review representative Jira issues and Confluence pages, identify the link types that matter, test them in a pilot migration, and agree on what can be migrated directly, what needs mapping or custom handling, and what should be reviewed manually.

How is licensing handled in such cases?

OpenProject currently does not provide full multi-tenancy support. A single installation of OpenProject equals a single instance. However, within each OpenProject instance, you can control on a project-by-project basis which users can access which projects (in combination with project hierarchies this can be used to separate access for e.g. different departments).

However, the global administration of the OpenProject environment (including workflow configuration) would be shared in this case.

OpenProject can support ticketing and service-request workflows, including email-to-ticket handling. Whether it is suitable for a customer-facing helpdesk depends on requirements such as external-user access, portal needs, SLAs, branding, and reporting.

The planned service portal (scheduled for end of 2026), as well as the support for SLAs (scheduled for early 2027), is particularly relevant here.

OpenProject allows organizations to configure work-package types, fields, workflows, and displayed columns. It should not be described as having Jira's exact "screen" concept.

Yes. OpenProject provides GitHub and GitLab integrations. Referencing work-package IDs in branches, commits, and pull or merge requests creates traceability between code changes and the related work package.

Additionally, it is possible to directly connect a Git repository and have an included web view of the repository within OpenProject.

OpenProject supports custom work package types, custom fields, configurable workflows per role or type, and custom actions, so you can model many business processes similarly to Jira, such as procurement or HR requests. More advanced conditional automation can be handled via APIs and webhooks.

To learn more about workflows in OpenProject, please refer to this page.

OpenProject currently does not offer fully customizable email templates. It is possible to add a custom email header and footer (including language-specific versions) that are appended to all outgoing emails. Additionally, the sender email address can be configured as well as the notification aggregation.

Since OpenProject is open source, it would be possible to customize this functionality (e.g. by developing a custom plugin).

XWiki supports rights at page level, so you can add specific access rules for one page without changing the rights model for the rest of the space or subwiki. This is useful when most content follows the same access pattern, but one page needs to be more restricted.

For example, a subwiki could be visible to a whole department, while one page containing sensitive information is limited to a smaller group. The page-level rule acts as an exception to the inherited setup.

There are a couple of important details:

• It is usually best to manage access through groups rather than assigning rights user by user.
• A page can be made more restrictive than its parent pages.
• For a large workspace, the cleanest approach is normally to keep broad rights inherited and only add page-level exceptions where they are genuinely needed.

XWiki’s local authentication supports configurable password policies (length, character classes, etc.) via standard user management and extensions.

For 2FA, the usual approach is to integrate XWiki with an identity provider (e.g. Entra ID, SAML IdP, LDAP/IdM with 2FA) and delegate authentication via SSO, so MFA policies stay centralized.

You can read more in the documentation: Authentication documentation.

Yes. Redirects can help preserve links when content is moved, renamed, merged, or reorganized.

This is especially useful when cleaning up duplicated content. Instead of leaving users with broken links, you can redirect them from the old location to the new consolidated page.

Both XWiki and OpenProject are open-source products and can be self-hosted.

The OpenProject Community edition is available free of charge and can be self-hosted. Enterprise editions add professional support and additional enterprise features.

Similarly, XWiki Standard is open source and can be self-hosted. This means a small organization can self-host the core XWiki and OpenProject products without license fees, but self-hosting also means taking responsibility for infrastructure, upgrades, backups, monitoring, security, and incident response.

Yes. Subwikis can be used to create dedicated spaces for specific audiences, such as customers, partners, departments, or projects.

Access rights can be managed through users and groups. This makes subwikis useful when you need stronger separation than a simple page tree, especially for customer-facing or partner-facing spaces.

Regarding licensing, the number of users is determined by the number of accounts listed in the XWiki user directory. Customer or external users who have accounts in the wiki are therefore counted as XWiki users. If you have a specific external access model in mind, it is best to confirm it with the XWiki team so the plan matches your use case.

A fully REST API-based import is not recommended, as some resources are not easily accessible and compatibility issues can arise depending on the Confluence version. You can, however, create scripts to export from Confluence spaces one after the other, organise them in batches, and then use the Confluence Migrator (Pro) to setup batch migrations.

In this way, the migrations will run one after the other and you will be able to review the reports as they are being completed. This method also ensures sufficient resources and produces a report for fixing broken pages after import.

Yes, users can be imported using dedicated authentication applications such as Active Directory (with LDAP user import), Entra ID, or other OIDC providers. This depends on the method and user management setup.

Since user management can involve authentication, groups, rights, subwikis, and provisioning rules, the best approach should be confirmed based on your setup.

If you need to add or manage hundreds of users programmatically, we recommend discussing the exact method with the XWiki team so it matches your authentication and access model.

Yes. Structured document types can be created using App Within Minutes. You can define fields, enforce formats, and improve consistency, making documentation easier to maintain and search.

Yes. You can enforce page templates or create structured document types using App Within Minutes. This ensures consistent formats for runbooks, incident reports, policies, or any other documentation type.

Yes. If you have specific requirements around hosting, support, migration, training, custom development, or enterprise deployment, you can contact XWiki SAS for a tailored offer.

XWiki gives you granular rights management, so you can create separate areas inside the same wiki and control access through users, groups, and permissions. For example, one section can be restricted to internal users, while another can be opened to a wider community.

The first thing you may want to do is configure an access policy for your wiki. Depending on what you intend to use your wiki for, you have 2 options. The first one is to configure your wiki to be public, so that people can edit and comment without necessarily being registered or logged in. The second one is to limit the access only to registered users, by configuring a private wiki.

If you need stronger separation between internal content, customer-facing content, and public information, subwikis or a dedicated deployment model may be a better fit.

Files stored in SharePoint can be migrated to XWiki using the Batch Import community extension, as demonstrated in this SharePoint migration guide.

Alternatively, you can convert office files into XWiki pages, using the Office import core feature.

For larger migrations, it is important to consider factors such as file volume, metadata, permissions, folder structure, and how users are expected to find and use the content. Depending on your goals, some documents may simply be migrated as files, while others may be converted into wiki pages to make them easier to edit, link, and maintain collaboratively.

The best migration approach depends on whether you want XWiki to serve primarily as a document repository, a knowledge base, or a combination of both.

Yes, you can organise your space exports in batches, which will trigger the migration of each space one after the other. Also, if you have a fairly small instance, you can use Confluence's backup export, export the whole confluence site, and migrate the full site in one run in XWiki. All three options (single space, batch, and backup export) are available in the Confluence Migrator (Pro).

Yes. XWiki can be installed on your own infrastructure. This is a good fit for organizations that need full control over data location, infrastructure, compliance, and customization.

XWiki has public documentation, a community forum, a community chat, and developer resources for teams that want to explore or troubleshoot independently.

Professional support is recommended when your organization needs predictable response times, contextual help, or support for a production instance.

XWiki and OpenProject can also be evaluated as an alternative to a Redmine and Redmine Wiki setup.

Our webinar focused on Jira and Confluence because of the current Atlassian situation, but the combination is not limited to Atlassian replacement projects. OpenProject can cover project planning, work packages, agile boards, Gantt charts, meetings, and project collaboration, while XWiki can provide the wider documentation, knowledge base, templates, structured content, and access management around that work.

The main difference is that this would not usually be a like-for-like replacement of Redmine's built-in wiki. The aim would be to keep project delivery in OpenProject and use XWiki for the more complete knowledge-management layer: project documentation, processes, requirements, decisions, technical documentation, and reusable knowledge.

Migration from Redmine should be assessed separately. The available options depend on the Redmine version, installed plugins, custom fields, issue types, attachments, permissions, wiki content, and whether the required data can be exported or accessed through the Redmine API.

XWiki and OpenProject are separate applications, so they are deployed and operated independently, then connected through the integration.

From the OpenProject side, the Community edition can be installed using Docker or Docker Compose. OpenProject also provides a Helm chart for Kubernetes deployments. The Helm chart can bootstrap OpenProject with optional PostgreSQL and Memcached components, while production environments can use their own managed database and infrastructure services.

From the XWiki side, an XWiki Helm chart is available for Kubernetes. It is designed to support both local deployments and highly available setups. For larger environments, XWiki can also use external services such as a standalone Solr instance when search load requires it.

A clustered architecture is not automatically necessary just because both products are used together. The right setup depends on expected concurrent users, storage volume, search and indexing load, attachment usage, availability requirements, backup and recovery objectives, and the identity and network architecture.

For a production environment, especially one replacing a large Jira and Confluence installation, the infrastructure should be reviewed as a joint architecture rather than treated as one shared container or one preconfigured stack.

Yes, you can host each application on whichever domain or subdomain you choose. XWiki and OpenProject are completely separate web applications, so there’s no requirement for them to share a domain. Many deployments use distinct domains or subdomains.

OpenProject can be used with the domain of your own choosing. For on premises, you can define the domain via your reverse proxy, load balancer, and configuration. For the OpenProject Cloud edition, you can select your own subdomain at the time of creation of your trial instance. Custom domains are available as an add-on through their support team, and require a DNS entry for your domain. Every OpenProject instance expects a single canonical host name.

For XWiki, you can also deploy it on any domain. Additionally, XWiki supports a virtual wiki feature where different subwikis can be mapped to different domain aliases (e.g. team1.wiki.company.com → Team1’s subwiki). This is optional; you can also simply use paths such as company.com/wiki/team1.

If XWiki and OpenProject need to integrate (e.g. via the integration extension or SSO), it’s fine if they are on separate domains. With SSO (SAML/OIDC), as long as both trust the same Identity Provider, users will have a seamless login experience even across domains.

Yes, XWiki can be used as a knowledge source for AI or RAG scenarios, but the integration should be designed carefully so that permissions, data access rules, and hosting constraints are respected.

The LLM Application is currently available as a beta extension and can provide an LLM chat assistant. In combination with the Index for the LLM Application, it can also provide answers based on wiki content or other indexed content.

The Index for the LLM Application supports indexing content from existing wiki spaces when explicitly configured. This is important because AI access to knowledge should not be treated as a general "index everything" shortcut. The setup should reflect what content should be used, who can access it, and where the AI service is hosted.

XWiki will also soon launch an MCP application, separate from the LLM App.

This depends on what you mean by sync, and it should not be treated as a standard Cloud feature.

Syncing pages, attachments, users, configuration, extensions, and full environments are different needs. XWiki has tools and extensions that can support replication or data movement in some scenarios. However, a Cloud-to-self-hosted synchronization setup should be scoped carefully before being used in production.

For example, the Replication Application can help share data between XWiki instances and demonstrates wiki page replication. However, using replication between XWiki Cloud and a self-hosted instance is not something we would present as a standard Cloud capability without technical validation from the XWiki team.

The standard XWiki Cloud offer is hosted in France on OVHcloud infrastructure. XWiki also uses Scaleway in France for encrypted backup redundancy and cold storage solutions.

This setup supports GDPR-aligned deployments and European data sovereignty requirements. XWiki Cloud also benefits from a security and compliance framework that includes automated backups, proactive monitoring, antivirus scanning, regular security maintenance, and hosting infrastructure with recognized certifications including ISO 27001.

If your organization requires data residency in Canada, the UK, or another specific country, discuss this with the XWiki team early in the evaluation process. Organizations with stricter internal policies or regulatory requirements can also deploy XWiki on their own infrastructure, which gives them full control over hosting, access management, integrations, and data residency.

Yes. During the webinar, we showed how Office documents can be converted into XWiki pages so they become editable wiki content, through the Office import feature.

XWiki can also work with files and documents through extensions and applications, including office-related integrations and PDF viewing. The best approach depends on whether you want to convert a file into a page, keep it as an attachment, or display it inside XWiki.

XWiki can interact with external databases and display the retrieved information inside wiki pages. But this is typically implemented through custom development or extensions rather than as a standard XWiki Cloud feature.

XWiki includes a Query Module that allows developers to execute queries against XWiki's own database and, when properly configured, against additional data sources. Combined with XWiki's scripting capabilities, structured data model, and application framework, this makes it possible to build pages, dashboards, reports, or business applications that display information coming from external systems.

For many use cases, however, XWiki's own structured data model may be a better fit than connecting directly to an external database. XWiki can store structured information through objects and properties, then display it through pages, forms, lists, and custom views without requiring a separate database integration. In fact, many teams use these capabilities to build lightweight business applications such as directories, inventories, project trackers, or knowledge management tools. With XWiki's App Within Minutes, these types of applications can often be created in... minutes.

If you need to read data from MySQL, MS SQL Server, or another external database, this should be treated as a custom integration project. The implementation details matter: read-only versus write access, authentication, network connectivity, hosting model, performance, maintenance, and security all need to be considered. For XWiki Cloud deployments in particular, external database connectivity should be discussed with the XWiki team to validate feasibility and security requirements.

XWiki does not provide a standard, one-click migrator for OneNote in the same way it does for Confluence. The right approach depends on the available export options, how the notebooks are currently organized, and what needs to be kept: sections and pages, embedded files, images, tables, links, permissions, tags, and page history.

In many cases, the work is less about copying OneNote files as they are and more about deciding how that information should live in XWiki afterward. Some content may become native XWiki pages, while documents and files can remain attached to the relevant pages. This can make the content easier to search, link, update, and manage with clear permissions.

For a large number of files, we would need to know what data can be exported from OneNote and run a few sample migrations. That lets us check the available export format, review how well the structure can be preserved, identify content that needs special handling, and define a realistic migration approach before processing the full collection.

For a large OneNote migration, we recommend contacting us for an initial assessment. We can review a sample of notebooks, assess the available export format and content structure, identify anything that needs special handling, and recommend a practical approach for moving the content into XWiki.