Connected to Microsoft Is Not the Same as Built on Microsoft
A connector can make legal content reachable.
Epona365 keeps legal work inside Microsoft 365 and SharePoint.
Cloud Solutions
The market often talks about Microsoft integration as if every model were the same. It is not. There is a difference between a legal DMS that stores documents in a separate platform and connects back to Microsoft, and a legal DMS that uses Microsoft 365 and SharePoint as the foundation.
With an external DMS, documents usually live outside the Microsoft 365 tenant. Microsoft may be able to access some of that content via a connector, depending on configuration and capabilities.
That can support search and discovery, but the underlying document environment still has its own security model, permission logic, audit trail, metadata structure and product roadmap. That means governance must be understood across multiple layers: one layer for the DMS and one layer for Microsoft 365. Another layer for integrations and later, another set of questions for Copilot, AI tools or agents.
For some organizations, that architecture may be acceptable. For others, especially those standardizing on Microsoft, it creates a question worth asking.
“Is this really a Microsoft 365 legal work environment, or is it a separate legal DMS with a Microsoft connection?”
A Connector
Is Not the Same as Native
AI needs context as a matter is not just a file. It includes emails, versions, permissions, document types, confidentiality, client context, timelines, knowledge and working history. For legal teams, the practical question is therefore simple: “Does the environment help AI understand the legal file, or does it only point AI towards a document?” That is where architecture becomes important. If documents, email, and matter context live in Microsoft 365 and SharePoint, they can align more naturally with Microsoft identity, permissions, collaboration, governance, and AI services. If legal documents are stored in a separate DMS, access may be possible via a connector, but the context around that access can become more limited or fragmented.
A connector can make content accessible, but a Microsoft-native legal platform can embed legal content into the working environment. That distinction becomes more important as legal teams move from search to AI-supported workflows, from prompts to agents, and from document retrieval to matter preparation, knowledge reuse and governance-aware automation.
as the foundation, with Epona adding the legal layer on top of that platform.”
Epona365 Is Built on Microsoft 365 and SharePoint
Epona365 takes a Microsoft-native approach. It is built on Microsoft 365 and SharePoint. SharePoint is the document foundation, while Epona adds the legal layer that standard Microsoft 365 does not provide out of the box: matters, email filing, legal metadata, permissions and matter context. That means legal work stays close to the environment that lawyers already use every day: Outlook, Word, Teams, SharePoint, and the browser.
This is a different story from placing legal documents in a separate container and connecting them back to Microsoft later. Epona does not ask firms to choose between Microsoft and legal structure. It brings legal structure into Microsoft.
That distinction is especially relevant for organizations with a Microsoft-first strategy. In that case, the question becomes less about buying another legal application and more about extending the Microsoft platform to properly support legal work.
As Bart Bogaerts put it in the input: “Customers are not only choosing Epona; they are choosing Microsoft as the foundation, with Epona adding the legal layer on top of that platform.”
Governance Follows the Architecture
The connector-versus-native discussion also affects governance. Microsoft Purview is designed to help organizations govern and protect data across Microsoft 365. If legal documents live in SharePoint, Purview can be part of the same governance strategy around classification, labels, retention, audit, data loss prevention and information protection.
If legal documents are stored in a separate DMS, governance may rely more heavily on integrations, mappings, or parallel policy models. That does not make external DMS platforms wrong. iManage and NetDocuments are established legal document management systems with strong legal-market heritage. For some organizations, they remain the preferred choice. The point is not that one architecture is always right for every firm, but that architecture now matters more than ever.
When legal teams prepare for Copilot, AI and agents, they need to understand where their documents live, which permissions apply, where governance is enforced and how much context AI can use.
Read more on Microsoft Purview in our article: Copilot Is the Ambition. Purview Is the Reality Check.
The Strategic Question
for Legal Teams
For organizations with a Microsoft-first strategy, the question is straightforward:
“Do we want legal documents, email, and matter context inside our Microsoft 365 environment, or in a separate DMS connected back to Microsoft?”
It affects how lawyers work in Outlook, Word, Teams, and SharePoint. It affects how governance is applied and it affects how knowledge can be reused. But it also affects how Copilot and future AI workflows can operate on legal content. This is why Epona’s position is simple. Microsoft 365 provides the foundation. Epona365 adds the legal DMS layer. Epona KMS adds the knowledge layer.
A connector can help Microsoft find content, but a Microsoft-native legal platform helps legal work live where Microsoft, governance, and AI are already developing.
