Shared Construction Document Control: A Five-Step Migration Playbook

Shared construction document control gives project parties an agreed process for identifying, reviewing, issuing and retaining project records. This playbook helps owners, document controllers and IT teams migrate those records while preserving their context. Scope drawings alongside contracts, RFQs/RFPs, supplier documents and handover evidence. Where existing construction tools leave a defined gap, a document platform can provide a governed process alongside them; assess the AODocs Capital Projects and Finance & Procurement offerings against the controls actually required.

A migration must preserve the information needed to retrieve the authorized document for its stated use, trace decisions and recover safely. The five steps below provide a planning framework, with primary guidance reviewed on October 2, 2026. Project owners must approve the actual requirements, access rules and acceptance criteria.

Step 1: Inventory records, dependencies and responsibilities

Inventory sources

Begin by identifying all repositories and sources people use, including those outside the formal document system. Inventory should include:

• Existing DMS or SharePoint
• Shared drives
• Email
• Submittal portals
• Local registers
• Handover repositories
• paper files
• file servers

Record for each:

• The collection boundary
• Export date
• Counting method
• Logical records
• Attached files
• Historic versions
• Bytes (storage size)

A workbook listing submittals is not the submitted packages themselves, just as a tracker for architectural drawings is not the controlled files.

Assign responsibilities

For each record, identify who is responsible as the process involves creating, checking, approving for sharing, authorizing, issuing, and accepting records:

• Creates
• Checks
• Approves for sharing
• Authorizes
• Issues
• Accepts

Assign each task to a named responsible person. The UK BIM Framework's information-management guidance recommends assigning these functions across project parties, and those responsibilities may sit with project managers or other team members rather than assuming one job title performs them all.

Define authoritative systems

Agree which system is authoritative for each record class and where new work belongs during migration. Teams can share a controlled workflow while retaining different authoring, project or business systems. Map the interfaces and required evidence before choosing transfer or integration routes.

Where ISO 19650 applies, use the owner's agreed information standard to define the required workflow, metadata and responsibilities. A consistent folder structure alone does not establish compliance.

With records inventoried and responsibilities assigned, the next step is to map identity, revision, state, and evidence.

Step 2: Map identity, revision, state and evidence

Version control mapping

Keep version control and document-control fields separate

Map the stable business document ID, source and target system IDs, revision, and classification as part of construction document management so drawings, specifications, and related project data remain in a single source of truth. An application's file-version number is not necessarily the project's revision code. Preserve the relationship instead of guessing from filenames.

Version control tracks changes and retained file versions; it does not establish that the newest file is approved for construction. Map the project revision code, approval/issue decision and permitted use separately. Managed document versions in AODocs libraries illustrate the software mechanism, not an automatic authorization rule.

Business status, CDE state, and permitted use answer different questions. An RFI may be Answered while its related document remains unsuitable for construction. The UK BIM Framework describes Work in Progress, Shared, Published, and Archive, with revision and status metadata communicating development and permitted use. Its UK examples are not automatic naming rules for a US contract. Apply the owner's agreed information standard. UK BIM Framework Part C, pp.11-15 and 19-27.

Teaching example, not client data: the IDs and revision codes below are illustrative. They are not prescribed US or UK codes.

Preserving history

Preserve history without manufacturing approval

Keep source actors, timestamps, decisions and transmittal/package references distinct from the import event. Preserve the required revision history and evidence relationships. If native history cannot move, preserve its export and record links, disclose the limitation and agree whether it is acceptable. Importing a file must not imply that a review happened in the new system.

Quarantine unresolved revision or authorization conflicts. Agree naming and retention rules from project requirements; do not universally strip revision information from filenames or invent retention periods.

Assigning access by task

Assign access by task

Access should be assigned by task using role-based permissions for authorized users, including field crews and office teams, rather than by a simple internal/external split. AODocs document-level permissions can be configured to reflect those responsibilities.

Shared information can be approved for exchange before it becomes Published. Archive preserves development and transaction history throughout the workflow; Superseded describes a revision's condition. The Part C workflow examples show client review in Shared before authorization and acceptance. AODocs workflows illustrate configurable states, transitions and permissions; test the proposed implementation against the agreed rules.

With identity, revision, state, and evidence mapped and preserved, the next step is to pilot difficult cases and reconcile the results.

Step 3: Pilot difficult cases and reconcile the results

Pilot scope and selection

A contained pilot is useful, but a clean folder alone cannot validate the migration. Include:

• Missing or invalid metadata
• Historical revisions
• A newer review revision alongside an authorized issue
• Linked RFIs/submittals
• External access
• Revision-heavy records
• Representative file sizes
• Native-file dependencies
• Required user routes

Include revision-heavy records and test current and superseded drawing retrieval through the required office and field routes. Record whether each user can retrieve the authorized issue for the stated task and how stale or unavailable copies are handled.

Testing and validation

Test business usability, end-to-end transfer and performance separately. The AODocs migration guide, pp.21-26 makes pilot scope dependent on the purpose of the test and identifies source export capacity as a potential bottleneck. Include the actual revision history, file sizes, native dependencies and user routes needed to measure the proposed migration.

Reconciling results

Reconcile source IDs to target IDs, including required versions, metadata values, and evidence relationships. Compare unchanged binaries with checksums where supported. If links or contents are intentionally transformed, validate that approved transformation separately; matching file counts cannot establish correctness.

Use the master document register to expose missing required records and unresolved exceptions. Require valid mandatory fields and evidence for records released for a stated use. Test permitted and denied access, including search and external routes, and configured workflow transitions. Add mobile/offline tasks where required. In the teaching example, confirm that construction-use retrieval returns authorized R01 while R02 remains review-only. Record the result and approver for each test.

If AI retrieval is included, inspect its actual permissions, issue/state filters, and cited revisions. Do not assume a Published-only default or treat correct citations as proof that every answer is correct.

With pilot results reconciled and exceptions identified, the next step is to plan each cutover and rehearse recovery.

Step 4: Plan each cutover and rehearse recovery

Cutover planning

Choose waves around connected workflows and business risk. Set dates from measured extraction/import rates, remediation and validation effort, staff availability and dependencies. Confirm the proposed document platform's supported transfer and recovery routes. A document count alone cannot establish a reliable migration duration or a schedule benefit.

Before switching users, name the decision owner and recovery owner. Agree severity-based stop criteria. A missing critical issue or unauthorized exposure must not be averaged into an acceptable overall percentage. Document permitted exceptions and their owners.

Freeze in-scope source writes as agreed, capture the final baseline/delta, import and reconcile, then validate routing and access before opening target writes. Verify that backups and exports contain what recovery needs; a file copy may omit decisions, permissions, or relationships.

Recovery after target writes

AWS cutover guidance distinguishes rollback without changed data from recovery after new transactions. Apply that consistency principle to document records; it is not a document-platform replication recipe.

After target writes begin, reopening the old source alone can lose new files, revisions, metadata, approvals, issues, or deletions. Capture those changes, their relationships, and any downstream impact on field execution. The named owners must choose fix-forward or recovery and reconcile them into the chosen authoritative environment using a supported, rehearsed method before work resumes. If the systems cannot export or restore the necessary context, resolve that readiness gap before cutover.

With cutover and recovery plans in place, the final step is to train users and monitor the controls, including context preserved in external business applications such as accounting software.

Step 5: Train users by task and monitor the controls

Training and demonstration

Prepare users in a safe pilot/training environment before their wave. Have them demonstrate the duties they actually hold:

• Retrieve an authorized issue
• Submit a review
• Issue a transmittal
• Inspect history
• Reconcile a deliverable

Train office and field users on the tasks they perform, including supported mobile and offline routes where needed. Document controllers do not automatically need full IT administration; match training to assigned duties and the configured workflow.

Incident management and monitoring

Agree incident ownership, escalation, and service coverage from staffing and contracts. The AODocs migration guide's change-management section, p.37 emphasizes role impact, tailored training, and feedback, including the use of collaboration tools.

Monitor unresolved exceptions, access changes and current-issue retrieval failures. Test required office, mobile and offline routes against the supported configuration. Address cached, printed and externally distributed copies in the operating procedure; a repository cannot automatically recall every copy. Apply the same reconciliation discipline when preparing the handover documentation checklist.

If your project needs a shared document-control workflow, discuss the requirements with AODocs. Bring the source inventory and a representative record package so the conversation can focus on mapping, controls, and what must be demonstrated before cutover.