Running a self-hosted workplace suite alongside Microsoft 365

Retention copies sit wherever the mail and chat platforms store messages, so the answer must cover both estates. Under SEC Rule 17a-4(b)(4), broker-dealers must preserve originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years. In a coexistence design, Microsoft 365 keeps its own archive while the self-hosted mail server (for example Stalwart or mailcow) and chat platform keep theirs, so one retention rule may apply in two places. The evidence is the retention configuration, the storage location and backup records for each system, and proof that deletion and legal hold settings work as written. Confirm with your compliance officer and auditor whether a self-hosted archive meets the rule for your business and whether a third-party archive or WORM storage is required. DeployOpen prepares the configuration and evidence. It does not issue attestations or regulatory determinations.

Transmission protection is shown by encryption settings and the configuration that enforces them on every path. The HIPAA Security Rule at 45 CFR 164.312(e)(1) requires technical security measures that guard against unauthorized access to ePHI sent over electronic communications networks. During coexistence, mail flows between Microsoft 365 and the self-hosted server, and files may move between both estates, so each hop needs evidence. Typical evidence includes enforced TLS on SMTP and IMAP or JMAP connections, TLS on the file sync and share endpoints, certificate inventories, and mail gateway rules that block plaintext delivery of ePHI. Confirm with your privacy officer which paths carry ePHI, which encryption settings your risk analysis accepts, and how exceptions are documented. DeployOpen can prepare the configuration records and test results. The regulatory conclusion remains with your organization and its assessor.

Audit logs are produced by each component, so evidence for both estates must be collected from each source and correlated. The HIPAA Security Rule at 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. On the self-hosted side, Nextcloud, Keycloak, the mail server and the chat platform each write their own logs, and Keycloak exposes admin and login events. Microsoft 365 writes its own unified audit records. Collect these into one log store with synchronized clocks, retention periods and access controls for the logs themselves. The item to confirm is whether your auditor accepts two log sources if a single review point is not possible, and which events must be reviewed and how often. DeployOpen can design the log pipeline and document what each component records, but the review procedure and retention decision belong to your organization.

Keycloak records authentication events, administrative changes and client configuration, and these form the core identity evidence for coexistence. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 and provides single sign-on and user federation, so it is often the point where access to workplace components is decided. Auditors usually ask who can sign in to which application, when accounts were created, disabled or granted roles, and how a leaver's access was removed from both estates. Use the admin event and login event logs, realm and client exports under change control, and the directory source of truth (Active Directory, Entra ID through a bridge, or LDAP). Confirm with your auditor how long these records must be kept and whether the Microsoft 365 sign-in logs are reviewed alongside them. DeployOpen configures and documents the identity flows and prepares the access evidence for review.

Change records show that each upgrade was planned, tested, approved, backed up and reversible, and auditors expect this for every component in the coexistence estate. Upgrade cadences differ: Nextcloud publishes a new major version every four months, does not allow skipping major releases, and recommends a backup before every upgrade with third-party apps disabled until confirmed compatible. openDesk plans monthly minor releases and supports only the latest minor version. Keycloak has its own release cadence and recommends manual approval mode for operator updates. Keep a dated change log per component with the version before and after, the test evidence, the approver, the backup reference and any rollback steps. Confirm with your change advisory board which changes need prior approval and how the evidence is retained. DeployOpen can run upgrades under a written scope and document each change, while approval decisions stay with your organization.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, assessors and certification bodies make those determinations. In practice, DeployOpen configures the components, sets up log and backup pipelines, documents the data flows between Microsoft 365 and the self-hosted estate, and assembles the evidence packages that your assessor requests. The scope of each engagement is agreed in writing before work starts, so the list of evidence, the components it covers and the format of delivery are defined in advance. Ask your assessor early which evidence formats they accept and whether they want the evidence collected per component or per control. Engagements can be run as fixed-scope projects or as retainers for ongoing evidence collection.

Yes, if the evidence is designed into the operating model from the start, but it becomes a recurring task that must have an owner. Plan which evidence is generated automatically (logs, backup reports, configuration exports) and which requires a human review step (access recertification, retention exceptions, change approvals). Assign an owner for each component and a calendar for reviews, because evidence that is not collected in the period under review is usually the gap an auditor finds. Ask your implementation partner for a written evidence inventory mapped to each component and to the controls your assessor cares about. Confirm internally how many staff hours the review requires, since that depends on the number of components, the number of users and the review frequency your assessor expects. DeployOpen can deliver the evidence inventory and collection scripts within a fixed scope, and optional retainers can cover ongoing collection.

The biggest drivers are the number of workloads you bridge, how complex your identity setup is, and whether regulated data crosses the boundary. Each workload pair (for example, file exchange, mail routing or chat) needs its own design, testing and cutover plan, so the count of bridges matters more than the count of users. Identity complexity adds work when you have multiple directories, hybrid Active Directory, or Entra ID that needs a directory bridge before federation is possible. Regulated workloads add evidence work: retention, audit logging and access records must be designed for both sides. The cost components are the people who design and run the bridges, the infrastructure and external services the suite needs, and any subscriptions for Enterprise editions. Ask for a written scope that lists each bridge, each identity source and each regulated data class before you compare quotes.

Some teams can, especially those with Kubernetes, identity and mail operations experience already in house. The work typically spans identity federation, Kubernetes operations, mail routing and DNS, file exchange, and user support, so you need skills in each area or a partner to cover the gaps. A practical test is whether you can name an owner for every bridge and every fallback path, and whether those people have time alongside their current duties. If the answer is no for any area, a fixed-scope engagement with a written deliverable list can cover that gap while your staff keep ownership of the running system. DeployOpen plans, implements, integrates and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.

Internal staff remain essential because they hold knowledge of your directory, your mail flows, your retention rules and your business owners. Expect requests for named contacts in identity, mail, security and compliance, plus access to your existing Microsoft 365 tenant configuration for coexistence design. Business leads must decide which user groups move first and which workloads stay put until later. Security and compliance staff must review the evidence each component produces and confirm it meets your internal policy. Support staff need time for pilot feedback, user communication and training. In an illustrative pilot with one department, the main internal demands usually come in the design review and the first two cutover weeks, not during steady state. Ask the implementation partner to list these internal roles in the scope so you can staff them before work begins.

Duration depends on scope, so no single timeline applies to every organization. The main variables are how many workloads move, how many user groups are involved, how complex the identity federation is, and how much regulated data must be migrated and retained. Each wave of users typically needs a design step, a pilot, a cutover and a stabilization period before the next wave starts. Platform timing also matters: openDesk releases minor versions monthly and only the latest minor version is supported, and Nextcloud publishes a new major version every four months, so your upgrade rehearsals need to fit those cadences. Ask for a phased plan in the written scope that shows each wave, its entry criteria and its exit criteria, and check each phase against your own change calendar.

Enterprise support scope depends on the product and the vendor, so confirm the coverage in writing before you rely on it. ZenDiS recommends openDesk Enterprise Edition for production, and its documentation describes SLA-backed second and third level support and patches for the suite, sold as SaaS or for on-premises installation. Nextcloud Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum. The published list prices start at 71.29 euros, 104.99 euros and 204.75 euros per user per year respectively for 100 or more users, according to Nextcloud's pricing page, with lower rates from 200 users. Those per-user rates apply to Nextcloud Enterprise only, not to other components in the stack. Ask the vendor which components the subscription covers, what response times apply and whether the subscription is per user or per instance.

Send a written scope that lists the workloads to bridge, the user groups and their order, the identity sources to federate, the regulated data classes involved, and the internal roles you can staff. Add the Microsoft 365 licensing you keep during the transition, the target hosting location, and the upgrade cadence you expect the suite to follow. Ask the partner to return deliverables, acceptance criteria, assumptions, dependencies and a phased timeline tied to those assumptions. A quote follows from the written scope, and DeployOpen does not publish a price list. Compare quotes on the same scope, and separate one-time work (design, bridge build, migration, training) from recurring items (subscriptions, support retainers, infrastructure and operations staffing).