We recently assisted a US-based international insurance brokerage with building a cloud-native document management system on Azure. The system, which manages over 100 million documents, leverages the Veladocs Content Service to manage content in Azure. Early in the project, versioning came up. The assumption on the table was a familiar one: “Azure Blob Storage supports versioning. We’re covered.”

It’s an easy assumption to make. The documentation is right there. Versioning: supported. Box checked.

The problem is that cloud storage versioning and ECM versioning are built for fundamentally different purposes. They share a name, and they share the basic idea of keeping prior copies of a document. Beyond that, they diverge quickly, and the gap tends to surface at the worst possible time, well into implementation, when untangling it is expensive.

This is the first in an occasional series where we examine cloud features that, at first glance, appear to satisfy ECM requirements. Versioning is a good place to start, because the mismatch is so common and so avoidable.

What ECM Versioning Is Actually For

In a document management context, versioning is not a backup mechanism. It’s a governance and traceability tool. It exists so that people, not just systems, can understand a document’s history, know which version they’re looking at, and trust that the version chain reflects reality.

That requires a few things that most ECM practitioners take for granted.

• Human-readable version numbers. ECM documents have versions like 1.0, 1.1, 2.0. These numbers carry meaning: major versions typically reflect significant milestones or formal approvals; minor versions reflect incremental edits, or draft/in-progress versions. The version number is a communication tool that tells a reviewer, an auditor, or a downstream system something meaningful about where a document is in its lifecycle.
• Version continuity after deletes. When the latest version of a document is deleted, ECM systems do not make the document disappear. They simply promote the prior version to become the new latest. Delete version 2.1 from a document with versions 1.0, 2.0, and 2.1, and you expect to be working with version 2.0 as the current version. The document remains available and the version history remains intact.
• Implicit version labels. Many ECM systems support labels like LATEST (the most recently created version) or ACTIVE (the version currently visible to users, which may not be the latest). These labels enable things like permanent document links that always resolve to the right version, regardless of how many new versions have been created since the link was made.

None of these is an exotic requirement. They’re the baseline for any organization managing documents with any kind of governance expectation.

Where Azure Blob Storage Falls Short

Azure Blob Storage versioning does what it was designed to do: it protects against accidental overwrites, and it lets you retrieve prior states of an object. For general-purpose cloud storage, that’s exactly right.

For ECM, it falls short in three specific ways.

1. Version identifiers are timestamps, not version numbers. Azure Blob Storage assigns each version an ISO 8601 timestamp as its identifier, something like 2026-04-14T23:18:20.8598537Z. That’s precise and useful for the storage layer. It’s meaningless to a document manager, a compliance officer, or a business user trying to understand a document’s history. There’s no concept of major versus minor versions, no human-readable numbering, and no way to introduce one within the native Azure versioning model.
2. Version deletion breaks document continuity. In Azure Blob Storage, deleting the current version of a blob does not promote the previous version. It removes the current version entirely, leaving the blob with no current version at all. From a user’s perspective, the document simply vanishes. It does not reappear until entirely new content is written to it. For ECM use cases where version management is a routine part of document governance, this behavior creates a meaningful gap between what users expect and what the storage layer actually does.
3. There’s no concept of implicit version labels. Azure Blob Storage has no native mechanism for designating a version as LATEST or ACTIVE in any business-meaningful sense. The storage layer tracks which version is “current” in a technical sense, the most recently written object, but it has no way to pin a particular version as the one that should be served to users or referenced by external systems, independent of when it was created.

It’s worth noting that these gaps are not unique to Azure. AWS S3 versioning operates on the same object-storage principles: opaque system-generated version IDs, no coherent chain management on deletion, and no support for semantic version labels. Organizations building ECM functionality on top of S3 will hit the same limitations.

How Veladocs Bridges the Gap

For the insurance brokerage customer, the Veladocs Content Service was deployed into their Azure environment to address this directly. Rather than working around Azure Blob Storage, Veladocs layers ECM versioning semantics on top of it, storing version intelligence in Azure’s own blob metadata system, with no external database or additional infrastructure required.

The result is a versioning model that works the way document management teams expect: human-readable version numbers (1.0, 2.0, 3.0), a reliable version history that travels with the document itself, and version-aware retrieval that ensures systems and users always access the right version. Documents uploaded outside of Veladocs are handled gracefully as well. The service detects missing metadata and automatically falls back to sequential version assignment.

For this customer, the approach fully met their requirements. Their use case did not require every feature on the ECM versioning roadmap, and that’s worth acknowledging. Not every organization needs the full depth of ECM versioning on day one. But every organization managing documents at enterprise scale needs more than a timestamp.

What to Ask Before You Assume You’re Covered

If your organization is evaluating cloud-native document management and you’re planning to rely on Azure Blob or S3 versioning to satisfy your ECM requirements, it’s worth pressure-testing that assumption before you’re deep into implementation.

The documentation will confirm that versioning is supported. It won’t describe what’s missing, because from a cloud storage perspective, nothing is missing. The platform is doing exactly what it was designed to do.

The question isn’t whether Azure or S3 does versioning. It’s whether what they do is ECM versioning. In our experience, the answer is no, and it’s exactly the kind of gap that Veladocs was built to close.

This is the first post in an occasional series examining cloud features that appear to check the ECM box but don’t hold up under closer scrutiny. Stay tuned for more.

In the meantime, if you’re working through a cloud document management project and want to talk through where the gaps might be, reach out and Contact Us.