Every CCMS has to live somewhere. Most ship their own store, access model and audit trail, so IT takes on a parallel platform. Dx5 uses the SharePoint you already run.
When the CCMS is a separate platform, IT has to operate two of everything: two access-control regimes, two audit-log destinations, two data-residency stories, two disaster-recovery plans, two license agreements with two procurement contracts. The CCMS team manages the platform, the IT team manages everything else, and coordination across that boundary is what consumes the project.
The cost is not in the license fee. It is in the procurement, the security review, the data-residency clearance, the audit-log integration, and the parallel access model that has to be reconciled with the corporate one. For a regulated-industries customer every one of those reviews is a multi-month exercise, so the evaluation takes longer than the implementation and the conversation becomes about platform fit rather than content design.
For an organization that already runs Microsoft, adopting Dx5 is a SharePoint application decision, not a new-platform decision. The legal, procurement, security and data-residency conversations are largely answered before they begin, because the answers are the same ones the customer already gave for SharePoint itself.
| With a separate CCMS platform | With Dx5 on the SharePoint substrate |
|---|---|
| A parallel access model, reconciled with the corporate one | Entra ID, conditional access and role assignments inherited from the SharePoint estate IT already operates. |
| A second audit-log destination and its own logging pipeline | SharePoint audit logs, with Microsoft Sentinel or any other SIEM fed through standard SharePoint connectors. |
| A second data-residency story to clear with legal and compliance | The Microsoft data-residency commitments the tenant is already provisioned and cleared against. |
| A second disaster-recovery plan to write, approve and test | Your existing SharePoint backup, restore and recovery policy. Dx5 does not require a separate plan. |
| A second license agreement and a second procurement contract | A SharePoint application decision inside a platform procurement that has already completed. |
| A multi-month security review of an unfamiliar platform | The security review your organization has already been through for SharePoint itself. |
That is the practical difference between Dx5 and every other CCMS on the market. The technical capabilities, components, content references, conditional profiling, content keys, controlled vocabulary, audit trail, are standard DITA capabilities and are broadly comparable across the category. The structural difference is where the content lives. Dx5 puts it inside the platform your IT department already runs. Other CCMS systems put it inside one they are about to be asked to take on.
Dx5 stores DITA components, content maps, and metadata inside Microsoft SharePoint. From the IT department's perspective it is one more SharePoint application: with the access-control posture, audit trail and backup model the rest of the SharePoint estate already has.
Dx5 sits inside the Microsoft 365 stack the customer already operates. Four surfaces, none of them new to the organization.
Components, content maps and metadata are stored as items in SharePoint libraries, alongside the rest of the content estate.
Authoring happens in the Word your tenant already licenses. DxAuthor+ applies the DITA structure behind the ribbon.
Tasks route through Teams notifications, Outlook tasks and Planner where the customer uses it. No separate workflow inbox.
Analytics run on the SharePoint data directly, so there is no export step and no second reporting store to keep in sync.
None of this requires a parallel platform. The same Microsoft 365 administration center that controls the rest of the tenant controls Dx5. The same governance and compliance posture applies: the same identity model, the same audit trail, the same data-residency commitments, extended to content management without changing the underlying IT story. What each of these surfaces does with the content is set out in more detail on its own page.
The vendor-neutral architecture guide: what running DITA on the SharePoint substrate means, and what it changes in the IT review.
The other half of the argument: subject matter experts stay in Microsoft Word while DxAuthor+ applies the structure.
Rule-based quality checks that run across every component in the SharePoint repository, not just the file in front of the author.
The deployment, identity and data-residency view, written for the people who have to sign the platform off.
No. On Microsoft 365 it runs inside the SharePoint Online the organization already subscribes to, so there is no new server, license tier or hosting arrangement to procure. On-premise it runs on the customer's own SharePoint Server, which is infrastructure the IT department is already operating and patching.
DitaExchange is a Microsoft partner and its products are Microsoft 365 certified. The SharePoint integration uses the SharePoint Framework, which is Microsoft's own extension model and is supported by Microsoft tooling long term. There is no bespoke fork of Word: the authoring tool is the standard Microsoft Word the tenant already licenses.
Yes. SharePoint Server on-premise is supported from 2019 onward, including air-gapped installations for defense, nuclear and sovereign-cloud customers. Organizations moving to cloud in stages can run a hybrid topology in the meantime rather than choosing one or the other up front.
Less than for a separate platform, because most of the answers are already set. Identity, data residency, audit logging, encryption, backup and network posture are whatever the tenant is configured for, and the CCMS inherits them rather than declaring its own. The line-by-line version of that review is on the DITA on SharePoint page.
It does not reorganize what is already there. Dx5 manages components inside the SharePoint libraries it uses, and deployments usually start in one site collection with one editorial team before scaling with the estate around them. The documents sitting elsewhere in the tenant stay documents until somebody converts them, and that conversion is a deliberate project with DxMigrationTool rather than a side effect of an installation.
Dx5 deployments usually start with one SharePoint site collection, one set of libraries, and one editorial team, then scale with the SharePoint estate they are already part of.
