How to Preserve Metadata When Migrating Construction Documents Between Procore and Autodesk Forma (ACC)

Most construction document migrations are judged on the wrong metric. Teams count files. They confirm the folder structure looks right. They tick the box and move on — and then, three months later, a document controller cannot filter the drawing register by revision status, the compliance team cannot prove which documents were issued for construction on a given date, and someone quietly starts rebuilding a spreadsheet on the side.

The files moved. The metadata did not.

Metadata is what turns a folder of PDFs into a project information model you can search, filter, review, audit, and hand over. It is also the part of a migration most likely to be treated as an afterthought, because it is invisible until it is missing. This article explains what construction metadata actually does, what breaks when standards are inconsistent, which field types genuinely transfer between Procore and Autodesk Forma, and how to map and validate metadata so the destination record is usable on day one.

Tech Tip:

What is construction metadata, and how is it used to manage project information?

Construction metadata is the structured information attached to a document that describes what it is, where it belongs, what state it is in, and who is accountable for it. The file itself is the deliverable. The metadata is what makes the deliverable findable and governable across thousands of other deliverables.

On most construction projects the fields that carry real operational weight are:

Field	What it controls	Who relies on it most
Status	Review workflows, issue gates, what is safe to build from	Document control, field teams
Revision	Which version is current; supersession of earlier issues	Everyone
Discipline	Filtering by architectural, structural, MEP, civil	Design and VDC teams
Level / Location	Zone, floor, or grid-based retrieval on site	Field and superintendents
Document type	Drawing, specification, model, report, certificate	Document control
Package	Procurement and subcontractor scope boundaries	Commercial, procurement
Approval status	Whether the document has cleared its review gate	PM, QA, owner
Title	Human-readable identification independent of filename	All stakeholders
Custom project fields	Client-specific or contract-specific classification	Owner, compliance

 

The filename alone cannot carry this load. Naming conventions encode some of it, but a filename is a single string: it cannot be filtered on independently, it breaks when someone renames a file, and it cannot express a status that changes over time while the document stays the same.

How metadata improves search and traceability of project files

Three practical gains follow from getting this right:

• Retrieval time collapses. Attribute-based filtering removes the dependency on folder knowledge, which is the main reason new team members and subcontractors struggle to find documents in the first weeks on a project.
• Supersession becomes visible. When revision and status are structured fields rather than filename fragments, superseded documents can be filtered out of a view instead of relying on people to notice.
• Reporting becomes possible. Outstanding submittals by package, drawings issued this month by discipline, documents still at draft status past their due date — none of these are answerable without consistent fields.

What problems arise from inconsistent metadata standards?

Inconsistent metadata standards break search, reporting, and automation at the same time. The most common symptoms are duplicate fields that mean the same thing (“Discipline” and “Disc.”), free-text entry where a controlled list should be used, the same value spelled several ways (“IFC”, “I.F.C.”, “Issued for Construction”), fields left blank because nobody made them mandatory, and classification schemes that differ between projects in the same company. The result is that filters return incomplete results, reports undercount, and teams stop trusting the system and revert to manual tracking.

These issues rarely originate in a migration. They accumulate quietly on the source platform and then become visible the moment data is moved, because migration is the first time anyone reads every field across every document at once. That is why the audit is worth doing before the transfer, not after:

Inconsistency	What it breaks	Fix before migrating
Free text where a list belongs	Filtering and reporting; values never group correctly	Convert to a controlled choice field and agree the value list
Duplicate or near-duplicate fields	Users populate one and filter on the other	Consolidate to a single authoritative field per concept
Inconsistent value spelling	Filters return partial results silently	Normalise values at source, or map variants during transfer
Blank mandatory-in-practice fields	Documents disappear from filtered views	Decide a default, or exclude those documents from scope
Project-specific schemes	Nothing is comparable across the portfolio	Define a company standard and map each project into it
Revision held only in the filename	No independent revision filter; renames break the chain	Extract revision into a structured field

 

What risks arise from a poorly planned metadata migration?

The main risks are silent ones, the migration reports success while the information degrades. Fields fail to create at the destination, dropdown values are dropped because they do not exist in the destination list, field types are converted and lose meaning, revision history is flattened, and nobody notices until the data is needed for a review, an audit, or a handover. By then the source project may be closed or the licence surrendered.

1. Fields that do not exist at the destination. Platforms differ in whether a tool can create a missing field. Where it cannot, every value written to that field is lost unless an administrator creates it first.
2. Dropped list values. Choice and dropdown fields typically only accept values already present in the destination list. A value that is not there is not added, it is skipped, usually quietly.
3. Type conversion loss. A number or boolean stored as text still displays, but it can no longer be sorted numerically, compared, or used in a conditional rule.
4. Flattened version history. Migrating only the latest version discards the revision trail. This is a legitimate choice for an active-work migration and a serious problem for a closeout or audit archive.
5. Revision-named files landing as separate documents. Three revisions of one drawing arrive as three unrelated files rather than one document with three versions, so supersession is invisible.
6. No evidence of what happened. Without a per-file, per-field log, there is no way to distinguish “transferred correctly” from “transferred with the metadata missing” — and no basis for a sign-off.

Every one of these is preventable at the mapping stage. None of them is easy to fix after the fact at scale.

What should teams consider when migrating construction metadata?

Treat metadata as its own workstream with its own owner, not as a setting inside the file transfer. Before any documents move, teams should agree which fields must survive, confirm those fields exist at the destination and match by type, check that every dropdown value is present in the destination list, decide whether metadata will also be used to filter what gets migrated, and run a sample transfer that is validated field-by-field before scaling to live projects.

Step 1: Inventory the fields that must survive

Start from use, not from inventory. For each field, ask what breaks if it arrives empty. Fields used for search, review routing, contractual status, or handover are non-negotiable. Fields nobody has filtered on in two years are candidates for retirement — a migration is a reasonable moment to stop carrying them.

Record for each field: the source name, the destination name, the field type, whether it is a controlled list, whether it is mandatory, and who signs off that it arrived correctly.

Step 2: Confirm the destination fields exist — and know which ones can be created

This is the step most often skipped, and platform behavior differs in ways that matter. With Graitec File Sync:

• For Autodesk Construction Cloud / Forma, BIM 360, and SharePoint, custom fields of supported types can be created at the destination if they do not already exist.
• For Procore, fields cannot be created by the sync. Only fields already defined in Procore can be populated. Any Procore-bound field must be set up by an administrator in advance.

That single asymmetry determines the sequencing of a two-way workflow. If Procore is a destination anywhere in your plan, the Procore field setup has to happen first.

Step 3: Validate field types against what actually transfers

Field type support is not uniform across platforms. The table below reflects how File Sync handles each type between supported systems:

Type	ACC / Forma	SharePoint	BIM 360	Procore	Transfer behavior
Text	Text	Text	Text	Text	Create and update supported in all systems (update only for Procore)
Date	Date	Date	Date	Date	Create and update supported in all systems (update only for Procore)
Array	Drop Down	Choice	Drop Down	Single Select	Create and update supported (update only for Procore); only existing list values are populated
Number	Not natively supported	Number	Not natively supported	–	SharePoint to ACC / BIM 360 only; stored as text
Boolean	Not natively supported	Yes/No	Not natively supported	–	SharePoint to ACC / BIM 360 only; stored as text

 

The practical reading: text, date, and choice fields are your reliable carriers. If a field needs to remain numerically sortable or usable in a conditional rule at the destination, confirm the destination supports that type natively before you design a workflow around it.

Step 4: Check every dropdown and choice value

Choice fields fail differently from text fields, and more quietly. A sync will populate a dropdown value only if that value already exists in the destination list — it will not add new list items. A source value of “Issued for Construction” written to a destination list containing only “IFC” does not create a new option and does not raise an error at the file level; it produces a metadata mismatch.

Export the full set of distinct values for every choice field at source, compare it against the destination list, and reconcile the two before the first run. This is usually a short task and it prevents the single most common category of silent metadata loss.

Step 5: Decide whether metadata should also control scope

Metadata is not only cargo, it can be the filter. Rather than migrating an entire project and sorting it out at the destination, you can limit a transfer to files matching specific metadata values: only documents at status “Approved”, only a given discipline, only a given package.

This is particularly useful for staged migrations, for issuing a controlled subset to an external party, and for building a closeout archive that contains only issued documents rather than every draft ever uploaded.

How do teams validate metadata after migration?

A pilot on one representative project is worth more than a full-scale run you cannot verify. Choose a project with the messiest metadata you have, not the cleanest,  the clean one will not surface the problems.

**What to check in the sample:**

• File counts and folder structure against the source inventory
• Each mapped field, on a sample spanning every document type and discipline
• Choice fields specifically,  confirm the value landed on the correct list item, not blank
• Number and boolean fields, confirm whether they arrived as text and whether that is acceptable
• Version stacks, where all-version transfer was used
• Revision-named files, where they should have been grouped as versions of a single document
• Documents at the edges: longest names, unusual characters, largest files, oldest records

**Read the activity log, not just the file count.** File Sync reports metadata outcomes per file, which is what makes field-level validation practical at scale:

Log message	What it means	Action
Metadata updated	The field was successfully populated or updated at the destination	No action; spot-check a sample to confirm values are correct
Could not create attribute	The field could not be created at the destination	Have an administrator create the field manually, then re-run, expect this for Procore destinations
Metadata mismatch	The field exists, but the source value does not match any value in the destination list	Reconcile the choice list values, then re-run the affected files

 

Failed and skipped files can be retried from the log without re-running the entire workflow, which is what makes iterative validation on a large migration realistic rather than theoretical.

Who is responsible for maintaining metadata quality?

Two failure modes are worth naming. The first is treating metadata as an IT task: IT can configure fields but cannot decide what “Status” should mean on this project. The second is treating it as purely a document control task: document control can define the standard but cannot create fields or grant permissions. A metadata migration needs both in the room, early.

What tools support large-scale metadata migration projects?

At small scale, manual re-entry and CSV re-import can work. At project or portfolio scale they do not, because neither carries custom fields reliably, neither produces per-file evidence, and both scale linearly with document count. Large migrations need a tool that maps fields between platforms, respects destination field types and list values, transfers metadata as part of the file operation rather than a separate pass, and logs the result of every field write. Graitec File Sync is built for this in a construction context, supporting metadata transfer across Autodesk Construction Cloud / Forma, BIM 360 Docs, Procore, SharePoint, Egnyte, and Dalux.

	Manual export and re-upload	Graitec File Sync
Custom metadata	Usually lost; re-keyed by hand if at all	Custom and system fields transferred as part of the operation
Field creation	Created manually at the destination, one at a time	Supported types created automatically on ACC / Forma, BIM 360 and SharePoint; pre-created for Procore
Choice value handling	Mismatches discovered by users, weeks later	Mismatches reported in the activity log at run time
Version history	Flattened to the latest file	All-version transfer available for migration-style operations
Revision-named files	Land as separate unrelated documents	Unify Versions groups revisions as versions of a single document
Scope control	Everything, or a manual selection	Filter by metadata, folder, file type, or file size
Evidence	No record beyond someone’s memory	Per-file activity log with metadata status and retry from log
Repeatability	Repeated by hand each time	Saved sync configuration, schedulable and reusable

 

How File Sync handles metadata between Procore and Autodesk Forma

Once the mapping work is done, the configuration itself is short. The typical workflow:

1. Create or open a workspace, then create a sync.
2. Select the source connection, then the source project and folder.
3. Select the destination connection, then the destination project and folder.
4. Enable Include Metadata. All available source fields are selected by default — deselect any that should not travel, or select a specific subset.
5. Optionally enable Filter by Metadata to restrict the transfer to files matching a chosen field value, such as a status or discipline.
6. Configure the supporting options: include subfolders, all-version sync, Unify Versions for revision-named files, file type and size filters, and the schedule.
7. Save and run the sync, then review the destination and the activity log field by field.

For a first migration, run this against a pilot project with metadata deliberately included but scope deliberately narrow. Validate, adjust the mapping, and only then widen the scope.