Intranet software RFP questions

The LDAP connection is documented in the Nextcloud server manual, so LDAP and Active Directory users can sign in with their directory credentials. Nextcloud also documents OpenID Connect and SAML user authentication backends. Confirm in writing which of these apps your target major version ships in the community build, which ones carry vendor support, and whether your identity provider's SAML certificate and attribute rules need an enterprise support contract. Support matters most when a login outage stops the whole intranet, so ask for the support hours and response times in the signed scope, not only the feature list. Read the Nextcloud LDAP documentation before the RFP so your questions match the current app names.

Nextcloud sells Enterprise per user per year with a 100-user minimum. Its pricing page lists 71.29 euros for Standard, 104.99 euros for Premium and 204.75 euros for the third tier, per user per year for 100 or more users, with lower rates from 200 users. Standard includes one year of maintenance. Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support. The third tier adds support up to 24/7 with response times down to one hour. These are list prices, so ask for the negotiated rate, how users are counted (active or licensed), and whether clustered hosting is in scope. Identity configuration is a separate line item from the subscription.

XWiki Pro lists Active Directory and Azure Active Directory SSO applications, so for those connectors the paid edition is the vendor's documented route. XWiki Standard is the free open source version. The community xwiki-contrib OIDC project is an OpenID Connect option you can evaluate without the Pro bundle. Before you choose, confirm whether the extension supports your XWiki version and your identity provider's current login flows, who maintains it after go live, and whether XWiki SAS support covers it. XWiki Pro and support subscriptions are tiered by user count: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000), Business (up to 10,000) and Enterprise (unlimited). Pricing is the same for cloud and on-premises deployments.

Four parties usually carry cost, and the split should be written down. The software vendor is paid for the subscription or support tier you choose. Your directory and identity provider licensing runs through your existing agreements, and any SSO feature that needs a higher license tier should be confirmed with that provider. Your internal identity team spends time on app registrations, groups, certificates and access reviews. An implementation partner is paid for configuration, testing and documentation under a fixed scope. DeployOpen plans, implements, integrates and documents self-hosted platforms inside your environment, and a quote follows from the written scope. Ask every partner which items are one-time (setup, attribute mapping, testing) and which recur (certificate renewal, upgrades, support).

Start from the directory as the source of truth. Joiners need an account and group membership, either created on first sign-in or through provisioning, with groups mapped to the spaces, folders or wiki permissions they need. Movers need old group memberships removed as well as new ones added, so ask whether group sync removes memberships or only adds them. Leavers need a disabled directory account to stop new logins, but disabling the account at the identity provider does not always end an existing session or remove local data. Confirm session lifetime, token revocation and whether local accounts remain after departure. Map each intranet space to one owning group, keep nested group depth shallow, and run a quarterly access review of space membership.

Build a staging instance connected to a test tenant of the identity provider, not production users. Test sign-in for each role group, attribute mapping for email, display name and groups, and the behavior when a user is missing an attribute. Record signing certificate and key expiry dates and name a renewal owner, because an expired certificate can lock every user out. Keep a documented local administrator account for break-glass access and test that it works without the identity provider. Check clock synchronization between servers and the identity provider, since timing errors cause intermittent token failures. Test logout, session timeout and mobile or desktop sync clients, which often use different token paths. Ask for the test results as a named deliverable in the scope.

The biggest red flag is an answer that assumes SAML or OpenID Connect is available on every tier without naming the edition, module or connector. Other warning signs include no named owner for certificate renewal, a quote that covers the platform but leaves out directory mapping, testing and leaver handling, no plan for what happens when the identity provider is down, and a claim that setup is simple without a sample attribute map or group design. Ask for the named edition, the connector and its version, the list of supported identity providers, the support hours that apply to a login outage and a written test plan. Also ask which parts are one-time work and which recur each year.

It can, if the intranet uses a standards-based login that the identity provider can enforce, but confirm this for each platform and connector before you rely on it. Conditional access policies usually apply at the identity provider, so the intranet application must be registered there and included in the policy. Mobile and desktop clients may use separate token flows, and legacy protocols or app passwords may bypass the policy, so test each client type. Check how the platform handles MFA prompts inside its own apps and whether file sync clients need separate app registrations. Record these decisions in the security design and map them to your access control evidence. Independent auditors and certification bodies issue any assessment, so treat the mapping as preparation only.

Nextcloud publishes a new major version every four months, and each major version receives maintenance for one year. Maintenance releases during that year address known critical bugs and security problems on a monthly basis. Your partner's plan should map each major version you run to its end-of-life date, so you know when the next upgrade is forced. The current supported lines and dates are listed in the Nextcloud maintenance and release schedule, and your partner should confirm them against that page at the time of signing.

No. Nextcloud does not allow skipping major releases, so an installation must move through each major version in order. A jump of several versions means several planned upgrade cycles, each with its own testing and rollback point. Ask the partner to show how they will sequence upgrades for your current version, how many major steps remain to the target, and how long each step will keep you on a supported line. The Nextcloud upgrade manual describes the official procedure that the plan should follow.

A full backup of the database, the data directory and the configuration must be taken and verified before each upgrade, because Nextcloud's upgrade process is the riskiest routine change to the platform. The partner should state where backups are stored, how often they run, how restores are tested, and who approves the rollback decision. Ask whether restore tests are included in the scope or billed separately, and whether they cover the full stack (database, files, search index and caches). Backup retention and location should match your own data retention rules.

Third-party apps should be disabled before an upgrade and re-enabled only after they are confirmed compatible with the new version. Ask the partner to maintain an inventory of every installed app, its version and its owner, and to run a staging upgrade that re-enables each app with test users before production. Apps that fail or have no compatible release need a documented decision: replace, retire or keep them on hold. Confirm whether app testing is part of each upgrade in the fixed scope or charged as a separate item.

The maintenance window depends on your user count, database size, number of apps and whether the intranet must stay available to staff during the change. Ask the partner to propose a window for each upgrade, state the expected downtime in writing, and explain how they will communicate the window to employees. For a high-availability design, ask how the partner handles rolling changes across cluster nodes. Confirm the approval process for emergency security patches, because monthly maintenance releases may need to be applied outside the planned calendar.

Nextcloud's published pricing differentiates tiers by maintenance length, support hours and response times, so these are the dimensions to compare when you evaluate a partner or subscription. According to Nextcloud's pricing page, the Standard tier includes one year of maintenance, Premium adds a maintenance lifecycle of five years or more with extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. Treat these as examples of what to compare, not as the terms you will receive. Ask each partner to state its own service levels, response times, escalation path and support hours in a signed document.

A written commitment should list the systems covered, the support hours, the response and resolution targets by severity, the escalation contacts and the exclusions. It should also state who handles vendor escalations, whether security patches are applied within a defined period, and what happens when a major upgrade fails. Ask whether support covers the application only or also the operating system, database, reverse proxy and backups. Any figure the partner proposes should appear in the contract, and any service level you rely on should be tested in a tabletop exercise before go-live.

Yes, many teams perform Nextcloud upgrades in-house, but the work recurs every four months and the planning, testing and backup steps must be repeated each time. The cost question is whether your staff have the time, skills and on-call coverage to do this on schedule within each supported year. Ask a partner to quote two options: a one-time upgrade with handover documentation, and an ongoing retainer that covers each major and monthly maintenance cycle. Compare both against your internal capacity, and check what the handover includes, such as runbooks, backup test records and an app inventory.

Scope, user count, integrations, migration volume and edition choice drive most of the cost. Scope covers which spaces, workflows and branding you need on day one. User count affects licensing for commercial editions, and the tier you buy sets the ceiling. Each directory, document system or mail integration adds design and testing work, and each legacy content source adds inventory, cleanup and migration effort. For XWiki, the Confluence Migrator Pro extension is priced from 2000 EUR according to XWiki Store, and XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support plans, so those line items are part of the picture. Ask any partner for a quote built from a written scope with each driver listed separately.

One-time costs cover discovery, installation, theming, directory integration, content migration and user onboarding. Recurring costs cover software subscriptions or support plans, hosting, backups, security patching, version upgrades, monitoring and ongoing moderation. Nextcloud Enterprise, for example, is sold per user per year, with list prices starting at 71.29 euros for the Standard tier at 100 or more users according to Nextcloud's pricing page, so licensing recurs. Upgrades also recur because Nextcloud publishes a new major version every four months and supports each one for a year. Ask the partner to separate one-time and annual figures in the quote, and to state which upgrades are included in the retainer.

Your team must provide directory access, named content owners and a sign-off process. Directory access means a service account with read rights to the user and group objects the intranet needs, plus the attributes used for roles and spaces. Content owners decide which pages, news and files move, which are archived and who approves the information architecture. Sign-off covers the scope document, the test plan, the go-live date and the acceptance criteria for migration. Without named decision makers, timelines usually slip because questions wait in queues. Confirm these responsibilities in the written scope so that delays have a clear owner.

Yes, many internal teams run self-hosted intranets, but they need dedicated skills and capacity. The team must handle the web server and database stack, identity integration, backups, restore tests, security patches and upgrades, and must follow the supported upgrade path. Nextcloud, for example, does not allow skipping major releases, so administrators must upgrade one major version at a time, back up before each upgrade and disable third-party apps until they are confirmed compatible. Teams without that routine often choose a partner for the first deployment, a retainer for upgrades, or both. Assess your staff's experience with the chosen platform before deciding.

The edition question depends on the platform and the authentication method you require. Nextcloud's LDAP app lets Active Directory and LDAP users log in with directory credentials, and Nextcloud also documents OpenID Connect and SAML authentication backends. Confirm with the vendor and your partner which of these are included in the edition you plan to run, because enterprise support tiers and feature sets differ. For XWiki, XWiki Pro lists Active Directory and Azure Active Directory SSO applications, while the free XWiki Standard edition is a separate choice. Ask the partner to test your actual directory and SSO flow in a staging environment before the edition is final.

Yes, moderation and content upkeep need a named owner, because an intranet without maintenance becomes outdated quickly. Moderation includes reviewing posts, removing content that breaks policy, and approving new spaces. Content upkeep covers archiving old pages, updating policies and checking that links and attachments still work. Effort depends on the number of spaces, the volume of posts and how many departments publish. Plan this as a recurring role inside communications, HR or IT, and decide whether a partner will provide it. Ask for the moderation model, escalation path and reporting in the scope document.

Compliance requirements change the scope by adding controls, logging and evidence work to the implementation. Regulated organizations often need audit logging, encrypted transport, access restrictions by role and documented retention. For example, the HIPAA Security Rule at 45 CFR 164.312 requires transmission security for ePHI and audit controls that record and examine activity in systems containing ePHI, so an intranet that touches patient information must be designed with those controls in mind. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports. Confirm your obligations with your compliance team before scoping.

A support retainer is worth considering when you cannot absorb upgrades, security patches and incident response internally. Retainers are available from DeployOpen for ongoing support, upgrades and continuous testing, and they are priced against the agreed scope. Before signing, compare response expectations, the upgrade path for the platform's major releases and the handling of third-party apps. For Nextcloud Enterprise, the vendor's tiers differ in maintenance length and response times, which is a useful reference point when comparing support levels. Ask each partner to describe what is covered, what is billed separately and how urgent issues are escalated.