本文へ移動
DocumentMS

Alternatives

Open source DMS alternative and the real cost of self-hosting

Open source document management is genuinely viable when you have engineering capacity to run it. The costs that get underestimated are OCR infrastructure, upgrade testing, backup verification, penetration testing and producing audit evidence — none of which the licence saving covers.

Why teams consider open source

The reasons are usually good ones. No per-user licence, so cost does not scale with headcount. Full control over where content sits, which settles data residency and sovereignty questions without a vendor conversation. The ability to read and modify the code, which matters to some security functions and to organisations with a policy preference for open source. And no vendor lock-in, at least in the sense that the data and the software are both yours.

For organisations that already run infrastructure — a platform team, a database function, a security team that patches things — these are real advantages and the arithmetic often favours self-hosting decisively at scale.

The reason this page exists is that the arithmetic is usually done on the wrong figures. A licence comparison puts a per-user subscription against zero, which is accurate and incomplete. The costs that decide the outcome are operational, they recur, and they are borne by people rather than by a budget line — which is precisely why they get left out of the business case.

The actual decision

What self-hosting actually costs

Not an argument against open source — an argument for costing it honestly. If you can absorb the left-hand column, the licence saving is real.

Keep

  • Infrastructure: servers or cloud instances, database, object storage, search cluster, and headroom for growth
  • OCR and transformation: recognition is compute-intensive and is the component most often under-provisioned
  • Patching and upgrades: security updates on the application, database, OS and every dependency, plus regression testing against your customisations
  • Backup verification: not taking backups, which is easy, but proving restores work, which is the part that is skipped
  • Security assurance: penetration testing, vulnerability management and producing evidence of both for auditors
  • Availability: monitoring, on-call, and someone whose evening is interrupted when it stops

Move or reconsider

  • The assumption that "free" refers to total cost rather than to licence cost
  • The idea that a proof of concept on one server predicts production behaviour at volume
  • Comparisons that omit the search infrastructure, which is usually the first thing to strain
  • The expectation that an auditor will accept "it is open source" as an answer about control assurance

Options

The main open source options

All four are real projects with real deployments. This is a summary of where each fits, not a ranking — evaluate them properly if self-hosting is your direction.
  1. Alfresco Community

    Suits. Organisations needing an extensible content platform with a proper content model, records management and a Java-based ecosystem.

    Trade-off. The most capable of the four, and the most demanding to operate. Assumes real engineering capacity, and the community edition differs from the commercial one.

  2. OpenKM Community

    Suits. Teams wanting a more conventional document management feature set — folders, metadata, workflow — without building on a platform.

    Trade-off. Lighter to run than Alfresco. The community edition is meaningfully narrower than the professional one, so check which features your requirement actually needs.

  3. Mayan EDMS

    Suits. Document-centric use cases built around scanning and OCR, particularly where Python is a familiar stack.

    Trade-off. Good at capture and indexing; lighter on workflow, approvals and formal records management than the requirement usually turns out to need.

  4. Paperless-ngx

    Suits. Small teams and individuals digitising paper, with excellent OCR and tagging for the scale it targets.

    Trade-off. Not built for organisational document control — no approval chains, no retention programme, no permission granularity of the kind an audit expects. Excellent at what it aims at.

Migration

If you are moving from self-hosted to managed

The reverse journey, which we see about as often. Usually triggered by a person leaving or an upgrade nobody wants to own.
  1. Step 1: Inventory the customisations

    List every custom behaviour, script, scheduled job and integration. This determines whether a managed product can meet the requirement at all — business logic living in the repository has to find a new home first.

  2. Step 2: Export via the standard interface

    Most open source repositories expose CMIS or a REST API. Export documents with metadata and version history, and reconcile counts before decommissioning anything.

  3. Step 3: Apply retention on the way in

    Self-hosted repositories often hold years of content nobody has reviewed. Migration is the moment to apply record classes and retention rather than moving everything and deferring the problem.

  4. Step 4: Retire the infrastructure deliberately

    Decommission with a documented plan: final backup retained per your schedule, certificates and credentials revoked, and the decommissioning itself recorded as evidence.

What tends to go wrong

  • Custom behaviours and scheduled jobs have no equivalent in a managed product; identify what business logic depends on them before assuming a migration is viable
  • Search index configuration and custom analyzers may not have direct equivalents — establish which searches are business-critical early
  • Content added directly to storage outside the application will not appear in an API export; check for it
  • If the deployment has never been penetration tested, migration is a reasonable moment to find out what was exposed rather than to quietly move on

Being straight about it

When open source is the right answer

When you already run infrastructure. If your organisation operates Java or Python applications, databases and search clusters as a matter of routine, the operational cost that dominates this decision for everyone else is a marginal addition for you. At that point the licence saving is largely real, and at high user counts it can be substantial.

When self-hosting is a requirement rather than a preference. Sovereignty rules, sector-specific hosting mandates and some contractual terms simply require the application to run on infrastructure you control. No amount of storage-backend flexibility on a managed product satisfies that, and vendors who suggest otherwise are answering a different question.

When you need behaviour no vendor ships. Custom content models, repository-level behaviours firing on document events, bespoke lifecycles — a closed product cannot offer these at any price. If your requirement genuinely needs them, extensibility is decisive and everything else on this page is secondary.

The honest counter-case is narrow: if nobody is accountable for operating it, self-hosting produces an unpatched, unmonitored, unrestorable system holding your records — which is a considerably worse outcome than a licence fee. The question is not open source versus commercial. It is whether you have the team.

FAQ

Replacing open source document management: common questions

The questions we get from teams part-way through this decision.
Is open source document management secure?

The software can be, and open code has genuine review advantages. The deployment is a separate question, and it is the one that matters: an unpatched instance with a default configuration and untested backups is insecure regardless of the licence. Security here is an operational property, not a property of the source model.

What does self-hosting really cost?

Infrastructure, OCR and transformation compute, search sizing at volume, patching and upgrade testing, backup verification, penetration testing, monitoring and on-call. None of it appears in a licence comparison. Cost it as a fraction of an engineer’s time per month and compare that with the subscription — the answer varies enormously by organisation, which is exactly why we cannot tell you what it is.

Can we self-host DocumentMS?

No. It is a managed cloud product. You can point it at your own S3 bucket or Azure container so document bytes sit in your region under your keys and logging, which addresses data residency — but the application runs as a service. If the requirement is that the application runs on your infrastructure, we are not a candidate and Alfresco or OpenKM are the better places to look.

Will an auditor accept an open source system?

Yes, if you can evidence the controls. Auditors ask about access control, change management, backup and recovery, monitoring and vulnerability management — not about the licence. The practical difficulty is that on a self-hosted system, producing that evidence is your job, and organisations that skipped the operational costing are usually the ones that also skipped this.

Bring your actual requirements. If staying is the better answer for your situation, we would rather say so on the call than six months into an implementation.