Engineering and architecture
BIM 360 to Autodesk Construction Cloud: archiving old projects
By SourceX Editorial · Updated
Short answer
In a BIM 360 to ACC migration, archive every closed project before access to the old account ends, in formats your firm controls: current and superseded sheets, markups, issues, RFIs, submittals and their attachments, plus an index that keeps record IDs linked. The rule: if a record explains why a drawing changed, export it, because final PDFs alone lose that history.
Key takeaways
- Closed projects need their own archive plan, because migration work usually centers on live projects.
- Final drawing sets alone lose the versions, markups, issues, RFIs and submittal responses that explain design decisions.
- Export structured records as spreadsheets and file attachments in folders named by record ID so the links survive.
- Test the checklist on one closed project and compare it with the live hub before running it across the portfolio.
- Decide what the archive is worth keeping and assessing before access to the old account ends, not after.
Why do closed BIM 360 projects need their own archive plan?#
Closed BIM 360 projects need their own plan because migration work naturally centers on live jobs, while closed projects hold years of the firm's review history. Teams choose which active projects move to Autodesk Construction Cloud, rebuild templates and permissions, and the finished work sits untouched until someone asks where it went.
Start by confirming in writing what your Autodesk agreement and reseller say about access to the old account, which content any migration covers, and when read access changes. Do not rely on a forum thread or a colleague's memory, since dates and scope differ by account and have shifted over time.
Once read access ends, anything not exported is out of practical reach. A firm can usually rebuild a drawing set from its own servers, but it cannot rebuild the issue thread that explains why a stair was redesigned or the RFI answer that settled a disagreement with the contractor.
What is lost if you only download the final drawings?#
Downloading only the final drawing sets loses nearly everything that explains how the design got there. The current sheet shows the answer; the surrounding records show the question, the reviewer, the alternatives considered and the reason for the change.
| Record type | What it holds | What is lost if skipped |
|---|---|---|
| Document versions | Superseded sheets and models with upload dates and version numbers | The sequence of design changes and when each one was issued |
| Markups and review comments | Reviewer notes placed on sheets during internal or client review | Who caught which problem, and on which version |
| Issues | Type, status history, assignee, location pin and linked documents | Coordination problems and how they were closed |
| RFIs | Contractor questions, reviewer routing, official responses and attachments | The firm's documented answers and the sheets they changed |
| Submittals | Items, spec sections, review steps, response actions and returned files | The stamp history and the reviewer's conditions |
| Transmittals and shares | What was sent, to whom and when | Proof of what each party received at each milestone |
| Meeting minutes and checklists | Decisions, action items and completed QA or inspection steps | The decision trail between formal documents |
Archive checklist for each closed project#
The archive checklist for a closed project should be identical every time, so a coordinator can run it without guessing and a principal can confirm it later. Run it on one representative project first, compare the export against what you see in the live hub, and fix the checklist before scaling up.
Expect gaps. Older projects may have used fewer modules, and some review content may have lived in email or on a file server instead. The readme is where those gaps get written down, which is far more useful later than a silent hole.
- Record the project name, number, hub location, dates, client and team roles at closeout.
- Download the full folder tree from document management. Check whether the bulk download includes superseded versions; if not, pull the milestone versions of key sheets and models separately.
- Export issues, RFIs and submittals as spreadsheet files, and as report PDFs if those keep comments the spreadsheets drop.
- Download every attachment and response file into folders named by the record's ID.
- Export markups on key review sets, or print those sets to PDF with markups visible.
- Save meeting minutes, checklists, daily logs and transmittal records where those modules were used.
- Count records per module in the live project, such as issues, RFIs, submittals and documents, and compare the counts with the export.
- Write a readme stating what was exported, what was unavailable, any count differences, who ran the export and when.
- Have the project manager or a principal confirm the archive is complete before the project is closed out of the old account.
Which formats keep an archive readable later?#
Formats your firm can open without a subscription keep an archive readable later. The test is simple: could someone open this file on a clean laptop after the BIM 360 account, and today's software versions, are gone?
| Content | Archive format | Why |
|---|---|---|
| Drawing sheets | PDF, ideally PDF/A where your tools support it, plus native files | PDF opens anywhere; natives keep editability for reuse |
| Models | Native files plus an open exchange format such as IFC | Natives may need specific software versions; IFC widens future access |
| Issues, RFIs and submittals | Spreadsheet or CSV exports plus PDF reports | Fields stay searchable; PDFs keep layout and comments |
| Attachments | Original files in folders named by record ID | Each answer stays tied to its question |
| Archive index | One spreadsheet with a row per exported record | Anyone can find a record without opening every folder |
How do you keep the links between records intact?#
Record IDs keep the links intact: an RFI number, a submittal number and a sheet number are the joins that turn a stack of exports into a project history. When those IDs appear in file names, folder names and spreadsheet exports, anyone can follow an RFI from question to response to the revised sheet.
Use one naming pattern across all projects, such as project number, record type and record ID, and resist renaming files by subject. Subject names drift; IDs do not. Where a record references a document, keep the document's version number so the link points to the sheet as it was, not as it ended up.
Record the software release that saved each native model as well. Revit files generally cannot be opened in a release older than the one that last saved them, so a note of versions saves guesswork when someone needs a model years from now.
Keep the archive index as a single spreadsheet with one row per exported record, so a reader can find any RFI or submittal without opening folders. These columns cover most needs:
- Project number and name, plus the old hub and project identifiers.
- Record family and record ID, such as RFI, submittal, issue or sheet number.
- Document version or revision the record refers to.
- File path of the export and its attachments.
- Export date and the person who ran it.
- Contract form and any ownership or confidentiality note from the project agreement.
- Retention rule and any legal hold that applies.
Who should run the archive, and who signs off?#
The digital practice leader should own the archive process, project managers should confirm each project is complete, and a principal should sign off on what is kept and where. IT handles storage, permissions and backups, but should not be the one deciding which records matter.
Before anything is removed from the old account, check three things: client contracts that require the firm to retain or return project records, any legal hold on projects with open claims or disputes, and the firm's own retention schedule. A project with an open claim is preserved in full, whatever the general plan says.
Restrict the finished archive to the people who need it. Old hubs often contain consultant files, contractor submittals and contact details for project participants, so the read-only archive needs the same care as the live system had.
Illustrative: a mid-size firm archives its closed BIM 360 hub#
Illustrative: a fictional architecture and interiors firm, Wren Hollow Studio, ran project delivery in BIM 360 for several years and moved its active work to Autodesk Construction Cloud. Closed projects stayed in the old hub, and the only plan was to download final sets before access ended.
A test export on a closed library renovation showed the problem. The final PDFs were already on the file server, but RFI responses, submittal stamps and issue threads existed only in BIM 360. The digital practice leader wrote a checklist, ran it per project, filed attachments by record ID and built a single index spreadsheet.
The principals then reviewed the index. Projects with open claims were preserved in full and locked. Projects under owner-drafted contracts that claimed all project data were flagged for counsel. The rest, where the firm's own review comments and RFI responses made up most of the record, were kept in a separate restricted folder so the firm could decide later, with counsel, whether to assess them for licensing.
How SourceX approaches archived BIM 360 projects#
SourceX treats an archived BIM 360 hub as a possible source of project records, assessed through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The Supply step uses metadata only, such as record families exported, years covered and contract types, and no files are shared during that initial assessment.
If a package proceeds, the SourceX Evidence Packet documents provenance, licensing rights, permitted use, the privacy record and release authorization for each project included. Large model and drawing sets stay in the firm's own storage or ship on encrypted drives, and the firm approves every step.
Frequently asked questions
Can we archive closed projects without migrating them to ACC?
Usually, yes. Many firms move only active projects and archive closed ones to their own storage. Confirm with Autodesk or your reseller what happens to the old account and when, then run the archive checklist on each closed project before that point, keeping the readme and index with the files.
Should the archive include project member lists?
Keep a record of roles and companies, because it explains who reviewed and answered what. Personal contact details are another matter: store them in a restricted part of the archive, and remove or mask them in any copy shared outside the firm or prepared for licensing.
What about consultant and contractor files in our hub?
Archive them with the project, but label them by author. Consultant drawings, contractor submittals and manufacturer product data were created by others, so they carry different rights from the firm's own review comments. That distinction matters for reuse and for any later licensing discussion.
How long should we keep the BIM 360 archive?
There is no single answer. Contract retention clauses, state claims periods, insurer guidance and legal holds all bear on it. Set the period in a written retention schedule agreed with counsel and your professional liability insurer, then apply it the same way to every project.
Can the export be automated instead of done by hand?
Partly. Autodesk offers APIs, and some accounts include data extraction tools, so check what your subscription covers. Scripted downloads still need someone to check completeness and naming against the checklist, so plan a short manual review of each project even when the download itself is automated.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.