Which open-source platform replaces SharePoint as an intranet
When SharePoint is the intranet, news pages and wiki as well as the file store, the replacement has to cover more than documents. XWiki is the platform to evaluate for intranet pages, wikis and news-style content, because it is built around structured, linked pages with its own permissions and extensions. Nextcloud with Collectives covers lighter team wikis that sit next to the files, which suits smaller teams that want one login and one place for documents and notes. Neither product is a full replacement for every SharePoint site, so the first task is an inventory of which sites are really pages and which are document libraries.
A practical split is to keep binary documents, versioned files and co-authoring in Nextcloud with Collabora Online, and move narrative content such as policies, how-to pages, announcements and team wikis into XWiki. Links between the two should be designed up front: decide which system is the source of truth for each policy or procedure, and avoid copying the same document into both. Confirm with each vendor whether the current XWiki and Nextcloud versions support the authentication model you need, such as LDAP or Active Directory, OpenID Connect or SAML, and check whether your Microsoft 365 connectors are still required once the migration is complete.
SharePoint lists, workflow automations, approval chains and some site-level features have no direct equivalent in either platform, so they must be redesigned or moved to another tool before cutover. Map each list and workflow to a named owner and a replacement decision, and treat that mapping as a gating item for the project. Ask any implementation partner to document which SharePoint features are out of scope, how permissions will be reconstructed group by group, and how the intranet will be supported after go-live. Confirm current support windows and upgrade paths for each product in writing, because both platforms require planned major upgrades to stay supported.
Mapping SharePoint intranet capabilities to open-source options
This table maps the intranet and team site capabilities that SharePoint usually covers to XWiki, Nextcloud with Collectives, and Nextcloud with Collabora Online. Read each row as a fit assessment: where a platform covers the need directly, where it needs configuration or add-ons, and where you should plan for a gap or a different design.
| Capability | XWiki | Nextcloud with Collectives and Collabora Online |
|---|---|---|
| Team sites and shared spaces | Spaces and nested pages organize teams, with per-space rights. Confirm the space model fits your site hierarchy. | Team folders and group folders hold shared files. Collectives adds shared wiki-style spaces. Confirm team folder quotas and admin tooling in your target version. |
| Document libraries and version history | Attachments are stored with pages, which suits fewer, linked documents rather than large libraries. Confirm attachment versioning behavior. | Files keep version history and sync through desktop and mobile clients. Document libraries map well to Nextcloud folders. |
| News pages and announcements | Pages and blog-style content can publish news. Homepage and layout design require configuration work. | Collectives pages can host announcements. Nextcloud has no native hub-style news feed, so plan for a separate publishing approach. |
| Wikis and knowledge pages | Strong fit. Wiki syntax, page history, comments and linking are core features of the platform. | Collectives provides wiki pages with editing and history. Feature depth is narrower than a dedicated wiki, so test with your largest page sets. |
| Co-authoring Office documents | Not a document editor. Office files are typically edited in Office desktop apps or a connector. | Collabora Online edits .docx, .xlsx and .pptx inside the browser and co-authoring is available through the Nextcloud integration. Confirm format fidelity with your templates. |
| Permissions and groups | Rights can be set per space and page and can follow directory groups. Confirm inheritance rules for your structure. | Permissions apply to files, folders and shares, and LDAP or Active Directory groups can be used. Confirm group sharing rules against your SharePoint permission model. |
| Search | Built-in search covers page content. Confirm indexing of attachments and performance at your content volume. | Full-text search is available through the Nextcloud ecosystem, and All-in-One bundles it. Confirm which file types are indexed. |
| Single sign-on | OpenID Connect and Active Directory integration are available through extensions. Confirm the extension versions for your target release. | LDAP and Active Directory users can log in with directory credentials. OpenID Connect and SAML backends are documented. Confirm the configuration for your identity provider. |
| Mobile access | Browser access works on mobile devices. Confirm the editing experience for your needs. | Native iOS and Android clients sync files and access Collectives. Confirm offline and app management policies for your users. |
| Workflows, lists and hub navigation | Gap: structured lists and approval workflows are not core features. Plan to use a separate workflow or form tool. | Gap: SharePoint lists and approval workflows have no direct equivalent. Plan for a separate workflow or database tool and a navigation design. |
When XWiki or Nextcloud Collectives fits the intranet
SharePoint often serves as the intranet, with news pages, wikis and team sites alongside documents. The options below cover different parts of that job, so the decision starts with which pages and workflows must move and who maintains them. Each card names the trade-off you accept with it.
XWiki Standard for the intranet
XWiki Standard is the free, open source edition, licensed under LGPL 2.1, and its official Docker images come in MySQL, PostgreSQL and MariaDB variants running on Tomcat for amd64 and arm64v8. It suits a self-hosted intranet where news, policies and team wikis need structured pages and a clear page history. The trade-off is that you run and patch the platform yourselves. Choose one release line before you build: stable, long term support (LTS) or the intermediate LTS, and plan upgrades on that line.
XWiki Pro connectors and SSO
XWiki Pro bundles XWiki with business applications, connectors and support from XWiki SAS. Its listed features include Active Directory and Azure Active Directory SSO applications, File Manager, Polls, Calendar and connectors for Google Apps, Office365 and OnlyOffice. This fits organizations that need directory sign-in and Microsoft-era integrations on the wiki. The trade-off is a subscription, so confirm which connectors you need and whether each is included in your chosen tier before you assume parity with SharePoint web parts.
Nextcloud Collectives for team wikis
Nextcloud Collectives adds shared, Markdown-based wiki spaces to Nextcloud, so team knowledge sits next to the files that Nextcloud already holds. It works well when teams want one login, one permission model and a light wiki rather than a full intranet platform. The trade-off is that its page features are narrower than XWiki's, so test structured content, templates and macros against your real pages. Confirm the Collectives app version compatibility with your Nextcloud major release before you upgrade.
Nextcloud plus XWiki pattern
Some organizations keep documents and collaborative files in Nextcloud with Collabora Online, and place the intranet pages, policies and process wikis in XWiki. Each platform then owns one job: file storage and co-authoring in Nextcloud, structured pages in XWiki. The trade-off is two systems to back up, patch, monitor and give consistent identities through the same directory. Write down which content lives where, and link between them rather than duplicating documents.
Splitting documents and pages between a file platform and a wiki
Use a simple test: if the item is a formal document that needs versions, approvals, co-authoring in a word processor or a fixed file format, it belongs in Nextcloud with Collabora Online. If the item is a page that people edit in place, such as news, how-to procedures, team handbooks, glossaries or onboarding notes, it belongs in XWiki or Nextcloud Collectives. The split is driven by how content changes, not by which team owns it.
- Formal documents: policies, signed contracts, templates and anything exported to PDF for distribution stay as files in Nextcloud.
- Evolving pages: procedures, FAQs and team pages move to a wiki, where edits are tracked per page and linked by title.
- News and announcements: keep them in the wiki, with the file attached only when the source is a formal document.
- Duplicates: decide one master location for each item and link to it from the other side.
- Mixed content: a procedure that refers to a signed form should keep the form as a file and describe the process on the page.
Before migrating, review SharePoint pages and libraries and tag each item with its owner and its intended home.
Many organizations cannot move every library on the same schedule. A transition period in which SharePoint keeps some documents while Nextcloud takes others is possible, but it creates two places to search and two sets of permissions. Treat it as a bridge with an end date rather than a permanent layout, and record which library moves in which wave.
- Inventory: list each library, its owners, its size and the external users who access it.
- Freeze rules: agree a cut-off date after which new documents go only to Nextcloud.
- Read-only archive: keep old SharePoint libraries read-only until retention obligations are met.
- Links: replace links in wiki pages with links to the new Nextcloud location as each wave completes.
- Search: confirm which search tool covers the old libraries during the bridge period.
Confirm with your legal and records teams how long SharePoint copies must be retained and whether the export preserves the version history you need.
XWiki pages should point to the authoritative file rather than copy it. A link keeps one version of the document in circulation and makes it clear which copy is current. Nextcloud sharing links and folder paths are the usual targets. Confirm the exact linking and embedding options in the XWiki version you run, since integration features depend on the edition and installed extensions.
- Stable targets: link to Nextcloud folders or share links that will not change when a file is replaced.
- Access control: a link does not grant access. Users still need Nextcloud permissions for the target.
- Connector options: XWiki Pro lists Google Apps, Office365 and OnlyOffice connectors, which you should check against your Nextcloud setup before assuming they apply.
- Attachments: attach small reference files to wiki pages only when the wiki must hold a copy, such as a template for offline use.
- Broken links: plan a check that finds links to files that were moved or deleted.
Ask your implementation partner to document the link pattern you choose so that authors know where to link when they add a new page.
Users should sign in once and reach both platforms with the same identity and group membership. This matters for the split because access follows the directory, not the platform. Nextcloud's LDAP app lets LDAP and Active Directory users appear in Nextcloud and log in with directory credentials, and Nextcloud also documents OpenID Connect and SAML authentication backends. For XWiki, the community project xwiki-contrib/oidc provides OpenID Connect support, and XWiki Pro lists Active Directory and Azure Active Directory SSO applications. Confirm which of these fit your identity provider and edition.
- Directory source: decide whether Active Directory, LDAP or an OpenID Connect identity provider is the single source of users and groups.
- Group mapping: map directory groups to Nextcloud groups and to XWiki groups so that access matches on both sides.
- Leavers: confirm that disabling an account in the directory removes access to both platforms.
- Testing: verify single sign-on with a test group before enabling it for all staff.
- Support: check whether the XWiki and Nextcloud configurations are supported by your chosen support provider.
Review the chosen authentication method with your security team before rollout, and document which identity source is authoritative.
A split only holds if someone owns the boundary. Without clear ownership, documents drift into wiki pages and pages get copied into folders, and both drift out of date. The governance model should name who decides where content goes, who reviews it and who retires it. This is an operating decision, and it works the same whichever platform hosts each side.
- Content owners: name an owner for each space, library and wiki section.
- Review cycles: set a review date for procedures and a retention rule for formal documents.
- Archive rules: define when a wiki page or folder is archived and who approves removal.
- Training: brief authors on the rule of thumb and on where to link instead of copy.
- Metrics: track stale pages and orphaned files with reports from each platform, and confirm the report types each version provides.
Ask your implementation partner for a written governance model as part of the scope, so the rule is agreed before any content moves.
How to move SharePoint sites, pages and documents
This sequence moves SharePoint document libraries to Nextcloud and pages and news to XWiki, with an inventory, a placement decision for each content type, verified permissions and a tested rollback path. The result is a documented cutover that staff can use without losing version history or links.
Inventory sites, libraries and content types
The project lead, with site owners and the SharePoint administrator, lists every site, document library, page, news post, list, workflow and external sharing link in scope. For each item, record its owner, size, file count, path length, version depth and whether it is still used. Retire sites nobody has opened in a long time before any copying starts. The output is a signed inventory that becomes the migration baseline and the source for acceptance checks.
Decide where each content type lands
Business owners and the platform team assign each inventory item to one of three destinations: Nextcloud for files and folder-based team content, XWiki for pages, news and knowledge articles, or retirement. Lists, workflows and custom web parts usually have no direct equivalent and need their own decision, often a separate tool or a rebuilt process. Record the decision and the owner for each item. The output is a placement register that avoids the same document being stored in both platforms.
Export documents with version history
The migration engineer exports document libraries using a method that keeps version history, such as Purview eDiscovery exports where the organization holds the required Microsoft 365 license, or a supported migration tool chosen after testing. Export a pilot library first and confirm that file names, modified dates, metadata and version counts survive. Note any files that fail because of path length and fix them at the source. The output is an exported archive with a manifest that lists every file and version.
Map groups and permissions to Nextcloud
The identity team maps SharePoint groups, site owners and external sharing to Nextcloud groups, folder permissions and share settings. If the organization uses Active Directory, connect Nextcloud through its LDAP app so users log in with directory credentials and group membership drives access. Test a sample of folders with users from each group and confirm that access matches the inventory. The output is a permission matrix signed by each site owner.
Convert and import pages into XWiki
The content team converts SharePoint pages and news posts into XWiki pages, since Confluence Migrator Pro only reads Confluence sources and does not handle SharePoint. Expect manual or scripted conversion of page layouts, web parts and embedded lists, and keep the original HTML or exported page as a reference. Import into a staging XWiki instance, then check internal links, images, attachments and page hierarchy. The output is a staging wiki that the content owners have reviewed page by page.
Import files and validate links
The migration engineer imports the exported libraries into Nextcloud and confirms file counts, checksums for a sample of files, version history where the import path preserves it, and permissions after import. Scan for links that point to old SharePoint URLs, then update them in documents and wiki pages or add redirects in the intranet home page. The output is a validation report with counts, exceptions and sign-off from each site owner.
Cut over with a tested rollback plan
The project lead schedules a cutover window agreed with business owners, makes SharePoint read-only for migrated sites, runs a final delta copy and switches users to Nextcloud and XWiki. Before the switch, write down the rollback steps, who can approve them and what data would be lost if rollback is needed after users start editing. Keep the SharePoint source available until owners confirm the new sites. The output is a cutover record with the rollback test result and a date for decommissioning the old sites.
What does replacing SharePoint intranet cost and take?
What does it cost to replace SharePoint intranet with self-hosted tools?
The cost is the sum of staff time, hosting, database, backups, optional support subscriptions and any outside consulting, and only some of these are one-time. Staff time for planning, configuration, migration and testing is usually the largest first-year item, while hosting, backups and support recur every year. No public price for a complete intranet replacement exists in the sources used here, so ask every bidder to split the quote by these components. Support for Nextcloud is sold as Standard, Premium or Ultimate, with list prices starting at 71.29 euros per user per year for Standard, according to the Nextcloud pricing page. XWiki consulting is listed at 1200 EUR per day and training at 1500 EUR per day by XWiki pricing, and that consulting requires a Business or Enterprise support plan.
Can our internal team replace SharePoint without outside help?
A team with Linux, container or PHP administration experience and someone who owns the content can do much of the work in-house, and the open-source packages are free to self-host. Outside help becomes more useful for directory integration, permission mapping across many sites, large content migrations and sign-off on security controls. Nextcloud All-in-One is the official installation method and bundles the database, caching, backups and optional office editing, which lowers the initial build effort. Confirm internally whether you have the skills to run upgrades, because Nextcloud requires one major version at a time with a backup before each step.
What does our organization need to provide before the work starts?
The work depends on four inputs: read access to the directory, named content owners for each site or space, a decision maker who signs off on permissions, and access to the current SharePoint environment for export. Nextcloud's LDAP app can make directory users appear in Nextcloud and log in with their directory credentials, and it also documents OpenID Connect and SAML backends, so confirm which of these your identity provider supports. Content owners must decide what stays as a file, what moves into a wiki and what is retired. Permission sign-off should happen before migration, because mapping SharePoint groups to new groups is hard to undo once users rely on them.
How long does the migration depend on the content inventory?
Timing depends mostly on how much content there is, how many sites carry custom lists, workflows or pages, and how many people must review their own material. A complete inventory of sites, libraries, page counts, file counts, path lengths and version history is the first deliverable and sets the schedule. Ask any provider to state durations in the written scope, since this guide does not supply a duration for an intranet replacement. Confluence wiki content is one example where the XWiki side offers a tool: Confluence Migrator Pro is priced from 2000 EUR and carries a 30 page trial limit per migration, according to the XWiki Store listing.
What drives the cost of a SharePoint replacement up or down?
The main drivers are user count, the number of sites and pages to convert, how much custom SharePoint workflow logic exists, integration with identity and email, and the level of vendor support you require. Storage size affects hosting and backup costs, and Nextcloud Enterprise pricing rises with tier and user count. Reducing the scope to documents and a wiki, instead of rebuilding every SharePoint list, usually lowers the effort. Ask for the quote to state which components are included, the user count assumed, and what happens when the user count grows.
Does replacing SharePoint intranet need a support subscription?
A support subscription is optional for the software itself, since Nextcloud Hub and XWiki Standard are free to self-host. Organizations usually buy support when they need response times, long maintenance periods, or vendor-backed fixes. Nextcloud Premium includes a maintenance lifecycle of 5 or more years, and Ultimate adds support up to 24/7 with response times down to 1 hour, according to the Nextcloud pricing page. Decide early whether your security and compliance program requires vendor support, because that choice changes the recurring cost more than any other single item.
What does the migration project need from DeployOpen?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so request a written scope that separates design, build, migration, testing, training and post-launch support.
How Nextcloud release cycles affect the file platform
Nextcloud ships a new major version every four months, and each one receives about one year of support through monthly maintenance releases that address known critical bugs and security problems. That cadence is faster than most intranet platforms, so the file platform needs an upgrade calendar owned by a named person, not an occasional project. Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026 with end of life in September 2027, and Nextcloud 36 (Hub 27 Winter) is scheduled for 17 February 2027. Check the Nextcloud maintenance and release schedule before setting windows, because the dates in your plan must match the version you actually run.
Major releases cannot be skipped. Nextcloud requires administrators to move one major version at a time, so a server that falls two versions behind needs a chain of upgrades rather than one jump. Each step should start with a full backup of the database, the data directory and the configuration, and with a restore test on a staging copy. Before every upgrade, disable third-party apps and re-enable them only after the vendor or community confirms compatibility with the new version. Team sites, content types, and the document libraries that depend on custom apps are the first things to break, so record which apps are installed and who owns each one.
Plan each upgrade window around the intranet features your users depend on, including the Collectives app if you use it for wiki-style pages, the LDAP or SSO connection, and Collabora Online, which must be checked against the new release. Confirm with your Nextcloud partner or support plan how long a staging rehearsal takes for your installation size, and whether your subscription, if you buy one, includes the maintenance lifecycle you need. Schedule the windows well before a version reaches end of life, so an unplanned emergency upgrade does not become the normal way the platform changes.
Where SharePoint features do not carry over
SharePoint intranets combine document storage with lists, approvals, navigation and search, and each of these behaves differently on a self-hosted stack. The cards below name the gaps most likely to affect an intranet migration, and what to confirm in your own environment before you commit to a target design.
Lists and tracker data
SharePoint lists act as lightweight databases for trackers, registers and request forms. Nextcloud's file platform does not replace them directly, and a wiki such as XWiki stores pages rather than structured rows with column types and item-level permissions. Inventory every list, export its items, and decide per list whether it becomes a table in a separate database tool, a wiki page or a file. Confirm which list features your users depend on, such as views, validation and item-level security.
Workflows and Power Automate-style automation
Approval routes, reminders and actions triggered by file changes are often built in Power Automate or SharePoint workflows. Neither Nextcloud nor XWiki provides a drop-in equivalent, so each automation needs a named replacement, such as Nextcloud's own workflow features or a self-hosted automation tool, plus a test run against real approval paths. Ask which flows are business critical and who owns them after the move.
Hub navigation and site structure
SharePoint hub sites group related team sites under shared navigation, branding and search scope. A wiki or file platform will need its own information architecture, with a home page, space or folder structure and menus that you design rather than inherit. Map each hub and its associated sites to a target space, then review navigation with the people who publish news and manage sites.
Content types and metadata
Content types bind columns, templates and retention rules to documents, so that a contract or policy carries the same fields everywhere. Nextcloud handles tags, folder rules and some metadata, but it does not reproduce SharePoint content types one for one. Document your current content types, the metadata each requires, and which retention or classification rules depend on them before choosing a folder or tag scheme.
Fine-grained permissions
SharePoint allows unique permissions on individual items, libraries and sites, and inheritance can be broken at many levels. Nextcloud sharing works through users, groups and folder or file shares, and the model is simpler. Audit broken inheritance in your current tenant, then test the target model with groups fed from your directory, for example through the LDAP app, to confirm that access matches policy.
Search depth and mobile apps
SharePoint search indexes sites, metadata and managed properties across an organization, and its mobile apps provide intranet news and document access. Nextcloud offers full-text search through optional components, and its mobile clients focus on files and sync. Test search on your own corpus, including scanned PDFs and attachments, and confirm which mobile functions staff need on phones before retiring the current apps.
How DeployOpen scopes and delivers the intranet replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an intranet replacement, that means agreeing in writing which team sites, news pages and wikis move to XWiki, which document libraries stay in Nextcloud, and how the two connect before any work starts.
How we scope
- Inventory every SharePoint site, library, news page and list, and mark which ones hold documents and which hold wiki-style content.
- Record which identity source, groups and site permissions must map to Nextcloud and XWiki accounts.
- Agree in writing which pages, libraries and workflows are in scope, with deliverables and timelines fixed before work starts.
How we build
- Deploy Nextcloud with Collabora Online for document libraries, and XWiki for news and team pages, inside your own infrastructure.
- Configure single sign-on through your directory, and test that permissions match the mapped SharePoint groups.
- Test the platforms, harden their configuration and document the link structure that sends users from wiki pages to shared files.
How we hand over
- Deliver runbooks covering installation, backup, upgrade order and the one-major-version-at-a-time rule for Nextcloud.
- Document the page and file taxonomy, ownership rules and the migration decisions for each SharePoint item.
- Provide evidence for your own compliance assessments, noting that independent auditors and certification bodies issue any audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Agree the upgrade calendar for Nextcloud and XWiki releases, with a backup taken before each change.
- Ask for the support scope, response expectations and upgrade responsibilities to be written into the retainer before you sign.
