The shift from paper-based document management to Electronic Document Management Systems (EDMS) has fundamentally changed how engineering projects control, exchange and archive their documentation. On a large EPC project generating 80,000 documents across 15 engineering disciplines and 40 vendor packages, the difference between a well-configured EDMS and an improvised file server is measured in months of delivery delay, millions in rework costs, and the integrity of the handover package at project close-out.
Yet the EDMS is not a silver bullet. Across every industry — oil and gas, infrastructure, energy, nuclear, transport — the pattern repeats: organisations invest in expensive platforms and then fail to use them correctly. The technology is deployed; the governance is absent. The result is a powerful tool being used as a glorified shared drive.
This article examines what an EDMS actually does on an engineering project, how the major platforms compare, what a proper implementation looks like, and why governance always determines the outcome — not the software.
What Is an EDMS and What Does It Actually Do?
An Electronic Document Management System (EDMS) is a software platform designed to manage the lifecycle of project documents: creation, review, approval, distribution, revision management, archiving, and retrieval. On engineering projects, the EDMS serves as the project’s Common Data Environment (CDE) — the single controlled repository through which all formal document exchange occurs.
The core functions of an EDMS on an EPC project are:
- Document register management: maintaining a controlled register of all project documents with their current revision, status, discipline, document type, and metadata attributes
- Revision control: ensuring that only the current approved revision of a document is the active controlled copy, with all previous revisions retained as historical record
- Transmittal and distribution management: recording and tracking all formal issuances of documents to external parties, with response tracking and disposition code management
- Review and approval workflows: routing documents through defined review cycles, capturing reviewer comments, tracking response due dates, and escalating overdue reviews
- Vendor data management: tracking vendor document submissions against Vendor Document Requirements (VDR) schedules and managing the review cycle for vendor-supplied equipment documentation
- Reporting and dashboard: providing real-time visibility of document status, transmittal response rates, overdue reviews, and MDR completion percentage
- Archive and close-out: structuring the final document archive for handover to the owner/operator
The Major EDMS Platforms: A Practical Comparison
The following comparison covers the six platforms most commonly used on major EPC and infrastructure projects. The assessment is based on operational experience, not vendor marketing.
| Platform | Best Suited For | Key Strength | Main Limitation |
|---|---|---|---|
| Oracle Aconex | Large international EPC, multi-contractor | Industry-standard transmittal workflow, multi-organisation model, audit trail | Complex configuration, licensing cost, learning curve |
| Microsoft SharePoint | Single-organisation projects, domestic contracts | Microsoft ecosystem integration, flexibility, low cost if M365 licence exists | Requires significant customisation for EPC workflows; no native transmittal module |
| OpenText Extended ECM | Asset-heavy industries, operational phase | Enterprise-grade content management, integration with SAP and ERP systems | Implementation complexity, cost, less project-centric than Aconex |
| Procore | Construction phase, site management | Construction-focused features, mobile-first, strong RFI and submittal management | Weaker on engineering document control, limited for multi-discipline design |
| Dalux | BIM-integrated projects, infrastructure | Strong BIM viewer integration, growing in Scandinavia and Europe | Less established for large-scale EPC, smaller ecosystem |
| Mezzoteam | Medium-complexity projects, French market | French-language interface, good transmittal functionality, cost-effective | Smaller user base, less international recognition |
The EDMS platform should be selected based on the project’s specific requirements: number of organisations, document volume, contractual requirements (e.g., client mandates Aconex), geographic context, and the existing skills of the document control team. A familiar platform well-configured always outperforms an unfamiliar platform poorly deployed.
Oracle Aconex: The Industry Standard for Large EPC
Oracle Aconex has become the de facto standard for large-scale international EPC projects, particularly in oil and gas, energy, and major infrastructure. Its multi-organisation model — where each contracting party has its own separate register and transmittals occur between registers — reflects the contractual reality of EPC projects better than any competitor.
Key Aconex capabilities that matter on large projects:
- Multi-org architecture: Each contractor, client, and third party has a separate Aconex register. Documents are transmitted between organisations, maintaining each party’s controlled copy independently.
- Mail and transmittal module: Aconex’s dual-module approach (Mail for correspondence, Transmittal for document issue) provides a complete project communication record.
- Workflow engine: Review workflows can be configured with sequential or parallel routing, response deadlines, and escalation rules.
- Audit trail: Every action on every document is logged with a timestamp and user ID. This audit trail is invaluable in contractual dispute resolution.
- Field module: Supports site activities including field inspections and punch list management.
Aconex implementation requires careful planning. The most critical configuration decisions are the organisation setup, the document register metadata schema, the transmittal workflow design, and the user role matrix. These decisions must be made before the system goes live — retroactive reconfiguration is costly and disruptive.
SharePoint for EPC Document Control: When and How
Microsoft SharePoint is widely deployed as an EDMS on projects where the client organisation already uses Microsoft 365. When properly configured, SharePoint can serve effectively as a project CDE for small to medium-scale projects.
However, SharePoint’s default capabilities are not sufficient for EPC document control without significant customisation. The following elements must be developed or configured:
- A custom document register with mandatory metadata fields (document number, revision, status, discipline, document type)
- Version control settings that enforce the document lifecycle (draft → in review → approved)
- A transmittal mechanism — SharePoint has no native transmittal module; this requires a Power Automate workflow or a third-party tool
- Access control structure mapping to the project RACI
- A reporting layer (Power BI or custom dashboards) for MDR status visibility
For large multi-contractor EPC projects, SharePoint is generally not the right choice. Its single-tenant architecture does not accommodate the multi-organisation document exchange model that Aconex provides natively.
EDMS Implementation: The Critical Success Factors
Regardless of which platform is selected, the following factors determine whether an EDMS implementation succeeds or fails:
- Configuration before go-live: The metadata schema, workflows, naming conventions, and access rights must be fully defined and configured before the first document is uploaded. Post-go-live reconfiguration corrupts the document register and requires rework.
- Training before access: Every user must be trained on the specific project configuration before they are given access. Generic platform training is insufficient — users need project-specific training on the DCP, naming conventions, and workflow procedures.
- Data migration quality: If the project is migrating from an existing system, the migration must include data validation to ensure that document numbers, revisions, and metadata are correctly transferred.
- EDMS administrator continuity: The project EDMS administrator is a critical role. If this person leaves the project, their replacement must be properly briefed before they can maintain the system.
- Enforcement: The EDMS only works if all parties use it consistently. Any tolerance for parallel document distribution (email, SharePoint sharing links for controlled documents) undermines the system.
TERADOK’s EDMS Implementation service covers the complete implementation scope, from platform selection and configuration to user training and go-live support. For governance framework design aligned with ISO 19650, see our Project Information Governance service.
When the EDMS Alone Is Not Enough
The most expensive EDMS deployment failure pattern is the “tool without process” scenario. The platform is procured, configured to a basic standard, and made available to users — but no Document Control Procedure is issued, no transmittal workflow is trained, and no MDR is maintained. Within months, the EDMS becomes a document repository with no governance. Documents are uploaded inconsistently, naming conventions are ignored, and the system cannot produce a reliable view of project document status.
This pattern costs projects far more than a proper implementation would have. The EDMS becomes a liability rather than an asset: the register cannot be trusted, the transmittal log is incomplete, and the handover package requires extensive remediation work.
For megaprojects where document control is a critical delivery factor, the investment in proper EDMS configuration and governance is not optional. It is a project controls fundamental — as important as scheduling or cost management.
Frequently Asked Questions about EDMS
EDMS Implementation
Need EDMS Configuration Support?
TERADOK deploys and configures Oracle Aconex, SharePoint, OpenText and other EDMS platforms for complex engineering and infrastructure projects. Contact us for a free initial diagnostic.
Book a Consultation