Engineering and architecture
Moving project files from an office server to the cloud: AEC checklist
By SourceX Editorial · Updated
Short answer
To move AEC project files from an office server to the cloud, assess the archive before choosing a platform: retention periods, legal holds and records that must stay intact with their links. Then protect CAD and BIM references, pilot one live project, migrate in waves and verify counts, references and permissions before retiring the server.
Key takeaways
- Assess the archive first: closed projects, retention status and legal holds decide what moves, how and when.
- CAD external references and Revit central models fail more quietly than ordinary files, so test them in a pilot.
- Keep the old server online and read-only until every migration wave passes verification.
- Migration is the cheapest moment to tag which closed projects carry client restrictions and which are firm-owned.
What should an AEC firm do before moving files to the cloud?#
An AEC firm should assess its project archive before it chooses a cloud platform, because the archive, not the active work, holds most of the risk. Active projects are visible and get tested by the people using them. Closed projects carry retention obligations, legal holds and broken references that nobody notices until a claim or a renovation request arrives.
The checklist runs in five stages: assess the archive, question the destination, protect CAD and BIM references, set structure and permissions, then pilot, migrate and verify. Common destinations include SharePoint and OneDrive, Egnyte, Autodesk Docs or a hybrid with local caching, and the stages apply to each of them.
Stage 1: assess the archive before anything moves#
Archive assessment means deciding, project by project, what moves, what stays read-only and what must be preserved exactly as it is. Run it with the COO or records owner, not IT alone, since the answers depend on contracts and claims history.
Preserving a record intact is different from moving it. A folder renamed during migration still opens, yet no longer matches the paths cited in transmittals, logs and correspondence.
- Inventory project folders by project number, client, status and last-modified date.
- Mark closed projects against the firm's retention schedule, and send any past their period to the principals for a documented decision rather than silent deletion.
- Confirm legal holds with counsel, and exclude held folders from any cleanup, renaming or deduplication.
- Identify record sets worth preserving intact with their internal links, such as RFI and submittal folders with attachments, issued sets with xrefs and model archives.
- Note projects with client restrictions on storage location or access, including security-sensitive work.
- Find orphaned data: personal home folders, scan dumps, old email exports and departed staff's drives.
Stage 2: questions to ask any cloud destination#
A cloud destination for AEC files should be judged on how it handles large, linked design files, not on storage price alone. Vendors change features often, so confirm each answer against current documentation and a hands-on test with your own files.
| Question | Why it matters for AEC files |
|---|---|
| How are large CAD and BIM files synced and cached? | Branch offices and remote staff open the same large files daily, and slow opens stall production. |
| Does it support file locking or check-out? | Two people saving the same drawing create conflicting copies that are hard to reconcile. |
| How are Revit central models and worksharing handled? | Central models behave differently from ordinary files and may need a supported collaboration route. |
| What path length and character rules apply? | Deep AEC folder trees and special characters can block uploads or break references. |
| Can permissions follow project teams and outside consultants? | Project-level access keeps client-restricted work limited to the right people. |
| Are retention labels and legal holds available? | Records obligations should survive the move rather than depend on manual discipline. |
| How would you export everything if you left? | There will be a next migration, and a clear exit path protects the archive. |
Stage 3: protect CAD and BIM references#
CAD and BIM references are the part of an AEC migration most likely to fail quietly. Drawings open, but xrefs, images and sheet sets point to a drive letter or server path that no longer exists.
A typical failure looks harmless: a mapped drive letter retired on cutover day. Every drawing that used it as an absolute path shows missing references, and the repair lands on production staff during deadlines if nobody audited paths first.
- Audit xref paths in AutoCAD and Civil 3D drawings, and convert absolute paths to relative ones where firm standards allow.
- Map Civil 3D data shortcut projects and update their working folder settings after the move.
- Decide how Revit central models will be hosted, and archive closed models together with their linked files.
- Collect plot styles, fonts, templates and title block libraries into a standards folder that moves first.
- Keep Bluebeam markups attached to the PDFs they reference, and export markup summaries before closing review sessions.
- Test one drawing set of each type end to end: open, reference, plot and save.
Stage 4: folder structure, naming and permissions#
Folder structure should be settled before the first file moves, because restructuring afterward breaks links twice. Keep the project number at the root of every project path and resist a full redesign during the migration; changing how people find work and where it lives at the same time doubles the confusion.
Set permissions by project and role, with a named owner for each project folder. Outside consultants and contractors get access through defined shared areas rather than links into internal folders, and closed projects move to an archive area that most staff can read but not change.
Write the naming and structure rules on one page. New hires and acquired offices will follow a written standard; they will not follow one that lives in a single IT manager's head.
Stage 5: pilot, migrate in waves, verify#
Verification turns a migration from a copy job into a records event the firm can stand behind. Pilot one active project with a real team, migrate the archive in waves by year or office, and verify each wave before starting the next.
Keep the old server online and read-only until every wave passes. Decommission only after sign-off, and keep a documented final backup according to the retention schedule.
| Check | How to run it | Pass condition |
|---|---|---|
| File counts and sizes | Compare source and destination per project folder | Counts and total sizes match |
| Integrity | Hash a sample of files on both sides | Hashes match |
| Timestamps | Spot-check created and modified dates | Original dates kept, not reset to migration day |
| References | Open sample drawing sets and models | No missing xrefs or links |
| Permissions | Test access as staff, consultant and archive roles | Each role sees only what it should |
| Legal holds | Confirm held folders with counsel | Held folders untouched and still protected |
Illustrative: a two-office architecture firm leaves its file server#
Illustrative: a fictional architecture firm with two offices runs projects from a Windows file server, with Revit models, consultant AutoCAD backgrounds and Bluebeam markups in each project folder. The server is near the end of its warranty, and the digital practice leader plans a move to a cloud file platform with local caching.
The archive assessment finds closed projects past the firm's retention period, one project on legal hold and many drawings with absolute xref paths to a mapped drive. The firm moves standards and active projects first, converts xref paths during the pilot and leaves the held project untouched in a read-only area. Closed projects past retention go to the principals, who keep those with complete RFI and submittal histories as a tagged archive rather than deleting them.
After cutover: what the archive is for#
A migrated archive is more than insurance against claims. Closed projects with intact RFI logs, submittal reviews, design review markups and change documentation record how the firm solves problems, which supports training, detail reuse and, for some firms, licensing of de-identified records.
SourceX reviews archives through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Large archives stay in the firm's own storage, the initial fit check uses metadata only, and nothing moves without the firm's approval. Client-restriction tags added during migration make any later rights review simpler.
Frequently asked questions
Should we migrate closed projects at all?
Usually yes, though not necessarily to the same place as active work. Closed projects within retention can move to a read-only archive area or lower-cost storage, as long as they stay searchable and intact. Projects past retention need a documented decision by the firm, not a default.
Can we clean up duplicate files during the migration?
Carefully. Duplicates in AEC folders are often intentional, such as issued sets that match working sets or files copied into transmittals. Never deduplicate folders on legal hold, and limit cleanup to clearly redundant areas such as personal scratch folders.
Who should own the migration, IT or operations?
Both. IT owns the platform, sync and security. Operations, usually the COO or records owner, owns retention decisions, legal holds and what counts as a record. Leaving records decisions to IT alone tends to mean keeping everything or deleting the wrong things.
What about project email stored outside the server?
Include it in the archive assessment even if it migrates separately. Project email often explains the decisions behind RFIs and changes. Check where it lives, whether it is filed to projects, and whether mailbox retention settings will remove it. If teams work in Microsoft Teams, Microsoft states that files shared in chats are stored in the sharer's OneDrive while channel files sit in the team's SharePoint site, so retention settings need to cover both.
How should we handle consultant files we received?
Keep them, since they are part of the project record, but tag them as third-party material. Consultant backgrounds and models usually belong to the consultant, which matters for any later reuse or licensing decision.
Sources
- Microsoft states that files shared in Teams chats are stored in the OneDrive account of the user who shared them, while files uploaded to channels are stored in the team's SharePoint site, so they need OneDrive or SharePoint retention policies. Source
Related resources
- InsightDo you need client consent to license de-identified RFIs and submittals?
- InsightOwner-furnished vs firm-produced documents: what can an AEC firm license?
- InsightDoes AIA B101 let an architect license project records for AI?
- QuestionDo I need customer consent to license support tickets?
- QuestionCan I see a sample contract?
- IndustryLegal data
See if your company qualifies
A short company assessment. No data uploads are needed.