Autodesk Construction Cloud migration playbook 2026: from BIM 360 to ACC unified

It was sprint week — five teams across three disciplines, final coordination model due Friday. Then, at 11:47 on Tuesday morning, the BIM Manager at a 400-person architecture and engineering practice got a message she will not forget: "I can't save. BIM 360 Docs says read-only." She forwarded it on to the project lead. The project lead forwarded it to IT. IT checked the Autodesk status page and found a banner that had been sitting there since the previous evening: BIM 360 Docs was undergoing maintenance ahead of an account-level migration to Autodesk Construction Cloud. The migration had been scheduled. The notification had gone to the account admin. The account admin had left the company three months earlier. Nobody else had seen it.

For forty-six minutes, 400 users across seven active projects had read-only access to their documents. Revit cloud models opened and immediately showed detached status — the workshared central file on BIM 360 Docs was inaccessible for save-back. Two teams had already begun their morning session, made changes in local copies, and were now unable to synchronise. When write access returned, the BIM team spent the next two hours sorting out who had saved what, where the conflicts were, and which local copies were safe to sync. No data was lost. But the schedule slipped by a day on three projects.

This is not a story about a Autodesk infrastructure failure. The incident was a foreseeable consequence of a migration that was not planned, not communicated, and not stress-tested against the practice's actual workflow. The migration tooling worked exactly as documented. The problem was that nobody in the practice had read the documentation.

If your practice is still on BIM 360 — or mid-migration — this article is the one that practice did not have in time.

What's actually happening

The platform consolidation

Autodesk Construction Cloud (ACC) is Autodesk's unified construction project management platform. It consolidates what was previously a collection of separate products — BIM 360 Docs, BIM 360 Build (formerly BIM 360 Field), BIM 360 Coordinate, BIM 360 Plan, and PlanGrid — into a single environment with a unified project shell, unified user management, and a shared document store.

The transition is not a cosmetic rebrand. The underlying data model, permission architecture, and API layer are materially different from BIM 360. When Autodesk says "unified," they mean that a project in ACC is a single object in their system, and all modules — document management, issues, RFIs, submittals, clash detection, insights — live within that single project rather than being separate products with separate logins and separate data stores.

ACC is built on the same Autodesk Platform Services (APS) infrastructure that powers the developer-facing API layer, which we covered in depth in our post on the Forge-to-APS migration playbook. That post covers the developer and API side. This one covers the BIM Manager and IT lead side: the platform-level migration that your users will live through.

The five modules that matter for most AEC practices migrating from BIM 360 are:

ACC Docs — the replacement for BIM 360 Docs. Document management, sheet management, transmittals, and the Revit cloud model host. The folder structure and file management look similar to BIM 360 Docs but the permission model is substantially redesigned.

ACC Build — consolidates BIM 360 Build and BIM 360 Field. Issues, RFIs, submittals, forms, daily logs, observations, and meeting minutes all live here. Build is where field-to-office workflows happen.

ACC Model Coordination — the replacement for BIM 360 Coordinate and BIM 360 Glue for the ACC tier. Automated clash detection, model aggregation, and issue creation from clash sets. This module imports models from ACC Docs and runs multi-discipline coordination.

ACC Bridge — the cross-project document and model sharing tool. Bridge allows a folder or set of documents in one ACC project to be shared with another ACC project, with controlled sync cadence. It is the tool that makes federated multi-project workflows possible without duplicating files, and it is new — there is no direct BIM 360 equivalent.

ACC Insight — the analytics and reporting module. Dashboard-level data across projects: issue metrics, submittal cycle times, RFI aging, model coordination progress. Replaces the rudimentary BIM 360 Insights product and is substantially more capable.

Why Autodesk is moving away from BIM 360

BIM 360 was itself a consolidation effort, absorbing Buzzsaw, Autodesk 360, and several earlier products. But the consolidation was architectural patchwork. BIM 360 Docs and BIM 360 Build had different login flows, different permission models, and different data layers for years. A document uploaded in BIM 360 Docs was not natively visible in BIM 360 Build without explicit linking. The products shared a brand but not a platform.

ACC was built to fix this. The promise — and, in practice as of 2026, largely the reality — is that a user logs in once, lands in a project, and all modules are within that same project context. An issue created in Build can reference a document from Docs without a separate link-sharing step. A clash found in Model Coordination generates an issue that lives in Build. Insight pulls data from all of these without separate API tokens.

The commercial rationale is straightforward: Autodesk wants per-project licensing (ACC is typically licensed per project rather than per user for some modules) to sit alongside per-user seat pricing, which is how they can serve both large enterprises and smaller practices with a single product. The BIM 360 per-product, per-user model was becoming increasingly complex to manage and to price competitively.

As of June 2026, Autodesk has communicated that BIM 360 will enter a maintenance-only mode, meaning no new features will be developed for BIM 360 products. Existing BIM 360 subscriptions continue to be honoured, and Autodesk has not published a hard end-of-life date for BIM 360 data access — they have been careful to commit to a data retention and access period. But the direction is unambiguous: ACC is the platform Autodesk is investing in, and BIM 360 is the platform they are migrating customers away from. Practices that have not begun planning their migration should begin now, not because BIM 360 will disappear overnight, but because migrations at scale take longer than teams expect — especially when active projects are involved.

The permission model change: the most critical difference

If you read nothing else in this section, read this. The permission model change between BIM 360 Docs and ACC Docs is the single most common source of post-migration access problems.

BIM 360 Docs permission model is role-based and project-level. You assign users to roles (Admin, User, Report Only), and roles determine what actions are permitted across the entire project. Folder-level permissions exist in BIM 360 Docs, but they inherit from and are constrained by the top-level role assignment. The effective permission model is: project role sets the ceiling; folder-level settings cannot grant more than the ceiling.

ACC Docs permission model is additive and folder-level first. You add users to a project with a base role (Admin, Member, or Member — limited access). You then grant folder-specific permissions to those users. A user can be a Member at the project level — which by default gives them no document access — and then be granted specific permission to specific folders. This is more granular and more flexible than BIM 360, but it means that migrated users who had project-level read/write access in BIM 360 Docs do not automatically have that access on the same folders in ACC Docs after migration.

The Autodesk migration assistant (discussed in detail in the playbook section below) attempts to map BIM 360 roles to ACC roles and to carry over folder-level permissions where they exist. In our observation, this mapping works reliably for simple permission structures — one role, all users at that role level, minimal folder-level customisation. For practices with complex permission hierarchies — external consultants with read-only access to specific sub-folders, project-level roles overlaid with folder-specific overrides, guest accounts with time-limited access — the migration assistant carries over the structure but requires manual verification of the outcome.

The symptom when it goes wrong: users report they can view a document but cannot upload a revision. Or they can upload but cannot create a transmittal. Or the project admin cannot see folders they created in BIM 360 because the root-level folder permission was not carried. These are not data loss events — the documents are still there — but they are workflow-blocking access issues that look like corruption from the user's perspective.

Revit cloud model links: the other critical breakage

BIM 360 Docs is where Revit Collaboration for Revit (formerly C4R, now just called cloud collaboration) stores workshared central files. When a Revit model is saved to BIM 360 Docs, the .rvt file on disk embeds a reference to its cloud location using BIM 360 Docs project and folder identifiers.

When the project is migrated to ACC, those project and folder identifiers change. The BIM 360 Docs URNs are different from the ACC Docs URNs. A Revit model that was worksharing to BIM 360 Docs will, after migration, open with a "Central Model Not Found" warning if it still points to the BIM 360 location, or a "Model Detached" state if the ACC environment has not been properly configured in the user's Revit session.

Autodesk's migration tooling handles the central file re-hosting as part of the project migration process. The .rvt files on disk are updated with the new ACC identifiers. However, this re-hosting requires that the migration is completed in a specific sequence: all users must check in and close their local copies before migration, the central file must be clean (no outstanding saves or syncs), and the migration must be confirmed complete before any user opens Revit against that project. Any user who has a local workshared copy open during or immediately after migration and attempts to sync-to-central will encounter errors — because the central they are syncing to no longer exists at the BIM 360 address.

This is what happened in the incident at the beginning of this article. The migration ran while users had active local sessions. Write access was restored when the migration completed, but the Revit worksharing state was inconsistent between users who had been mid-session.

Custom attribute mappings and the metadata problem

BIM 360 Docs supports custom attributes — user-defined metadata fields attached to documents. These are used extensively by information-mature practices for status tracking, review state, discipline code, and other metadata that supplements or replaces the structured naming convention.

Custom attribute schemas do not migrate automatically. The attribute definitions must be recreated in ACC Docs after migration. Documents that previously had attribute values populated will have those values orphaned — the document is in ACC Docs, but the attribute structure it belonged to no longer exists, so the values are invisible.

Additionally, BIM 360 Docs and ACC Docs have different field structures for native metadata. The status workflow states in BIM 360 (e.g., "In Review," "Approved," "For Information") are not identical to the ACC Docs status vocabulary, and the migration does not attempt to map them semantically — it preserves the raw string values where it can, which sometimes results in status values that do not match any valid ACC Docs status, leaving documents with no displayable status state.

Project templates: the silent gap

BIM 360 projects can be created from project templates that pre-configure folder structure, role assignments, permission groups, and custom attribute schemas. These templates are not migrated to ACC. If your practice has invested in BIM 360 project templates as part of a standardised project setup process, those templates must be rebuilt as ACC project templates from scratch.

More subtly: the project template in ACC works differently from the BIM 360 template. In ACC, the template defines the starting state — folder structure, default permission groups, module configuration — but does not continuously enforce it. In BIM 360, some practices had third-party tools or admin scripts that periodically re-applied template settings to enforce compliance. Those tools, if they used the BIM 360 Data Management API, will not function against ACC projects without modification.

If your practice maintains project setup templates, build the ACC versions before your pilot project migration, not after. A pilot project set up manually without the template will create a false positive — everything looks fine, but the template gap is invisible until the first templated project is attempted.

The pattern

The small-practice, one-IT-person scenario

A 40-person practice with a single IT manager and no dedicated BIM Manager is the scenario where the migration most frequently goes wrong through neglect rather than bad planning. The IT manager handles Autodesk licensing because it is part of their software management remit. The BIM 360 administrator account is often the IT manager's personal Autodesk account. When Autodesk sends migration readiness notices and account administrator notifications, they go to that account.

The problem is that the IT manager does not know what the BIM coordinator's daily workflow looks like. They do not know which of the six active projects have Revit cloud models. They do not know that the structural consultant's team has guest access to the Documents folder on three of those projects. They initiate the migration, follow the steps, and get a green "migration complete" status — and then spend the next week dealing with access tickets from users who cannot see their folders, consultants who cannot open shared links, and a Revit user whose central file is now showing as detached.

The large multi-office, multi-discipline practice

The 400-user practice in the opening scenario represents the large-practice pattern. The risks here are not ignorance — the practice likely has BIM Managers, information managers, and IT staff who understand the technology. The risks are coordination and communication: ensuring that all 400 users know what is happening, when it is happening, and what to do in the transition window.

Large practices typically have:

• Active projects at multiple phases, some with imminent delivery deadlines
• External consultant access on dozens of projects, managed by external IT teams
• Custom integrations — document numbering automation, transmittal tools, project dashboards — built on the BIM 360 API
• Licensing structures that may differ between project teams (some on ACC licenses from newer projects, some on BIM 360 subscriptions from older ones)

The large-practice migration should be budgeted as a project, not a task. In our observation across practices of this scale, a well-planned migration with proper discovery, pilot, and verification phases takes eight to twelve weeks from decision to completion for all active projects. Practices that attempt to compress this into two or three weeks create the conditions for the access incidents described above.

The JV and external-consultant-heavy project

Joint venture projects and projects with large consultant teams introduce a structural complication: not all users are within your Autodesk account. Guest users in BIM 360 Docs — external consultants added to your project with their own Autodesk accounts — are migrated differently from internal users.

In the BIM 360 model, guest access is managed by adding an external user's Autodesk ID to a project. Their account is external; their access is per-project. In ACC, the same model applies at the project level, but the unified account layer means that the external user's home environment — their own practice's Autodesk account — may itself be undergoing migration at a different pace or on a different account structure.

The practical complication: if your ACC project has been migrated and you reinvite an external consultant by email, they accept the invitation and land in the ACC project. But if that consultant also has BIM 360 projects from their own practice's account that they access through the same Autodesk ID, they may see a confusing mix of BIM 360 and ACC project environments in their home screen. This is not a technical problem, but it generates support requests and onboarding friction that consumes BIM Manager time.

The API-integrated practice

Practices that have built custom integrations on BIM 360's API — whether using the BIM 360 native APIs or the underlying Forge (now APS) Data Management API — face a migration that is simultaneously a platform migration and an API migration. We covered the API layer in depth in the Forge-to-APS migration playbook; the short version here is:

• BIM 360 project identifiers (hub IDs, project IDs, folder IDs) change in ACC. Any integration that has hardcoded or stored BIM 360 identifiers will need those identifiers updated for the ACC equivalents.
• The BIM 360 Data Management API endpoints work against ACC projects, but the project identifiers returned are different. A cached project ID from a BIM 360 API call will return a 404 when used against the ACC Data Management endpoint for the same project.
• Custom webhook subscriptions against BIM 360 project events do not automatically carry over to ACC. Webhook re-registration against the ACC project is required.

If your practice has a dashboard, a document management overlay, a transmittal automation tool, or any other integration built on BIM 360 API calls, add an API migration workstream alongside the platform migration. The two can be done in parallel if planned; they create incidents if discovered after the platform migration is complete.

The fix

Phase 0: Discovery (two to three weeks before migration)

Discovery is the phase that most practices skip or compress. It is the most important phase.

1. Audit your Autodesk account

   Log into the Autodesk Account portal (manage.autodesk.com) with an Account Admin credential. Navigate to Users > Product Access. Export the full user list, including their assigned products and their role in each BIM 360 project. You need to know: how many users are on BIM 360 products, which products they are assigned, and whether those products have ACC equivalents in your current license tier. This export is the baseline for your permission re-mapping work.

2. Inventory active projects

   List every active BIM 360 project. For each project, record: the project name, the BIM 360 project ID (from the BIM 360 project settings URL), the number of users (internal and guest), whether it has an active Revit cloud model (i.e., a .rvt file on BIM 360 Docs being used for cloud worksharing), and the number of documents. Projects with active Revit cloud models are your highest-risk items and must be migrated with explicit user coordination. Projects that are in archive or read-only status are the lowest risk and can be migrated first as a dry run.

3. Map custom attributes

   Open BIM 360 Docs Admin for each project and export or document the custom attribute schemas — the names, data types, and allowed values for every custom attribute. You will need to recreate these in ACC Docs after migration. If you have seven projects with seven slightly different attribute schemas, now is the time to standardise them before you recreate them in ACC. A migration that also achieves attribute schema consolidation delivers compounding value.

4. Identify integrations and API consumers

   Ask your IT team, your BIM team, and your project managers: what tools connect to BIM 360 automatically? This includes: Revit cloud worksharing (always), any custom addins that publish or retrieve documents from BIM 360, third-party platforms like BIMcollab, BIM Track, or Newforma that sync with BIM 360 Docs, and any internal dashboards or automation scripts. For each integration, you need a migration path or a temporary workaround. Start this conversation during discovery; do not discover integrations after migration.

5. Identify account administrator gaps

   Confirm that every BIM 360 project you intend to migrate has a current, actively monitored Account Admin on the Autodesk Account. If your current Account Admin is someone who has left the organisation, or whose account is no longer actively used, you need to add a new Account Admin before migration begins. Migration notifications, confirmation emails, and migration status updates all go to the Account Admin. If nobody is watching that inbox, you will miss critical steps.

Phase 1: Pilot project migration (one to two weeks)

Do not migrate your full project portfolio in one operation. Choose one completed or archived project for your first migration — ideally a project that has finished and is in read-only state, so the migration cannot impact live work.

1. Select and prepare the pilot project

   Choose a completed project with a full document set, custom attributes, and a record of user access. A project with 200–500 documents is ideal — large enough to surface issues, small enough to verify the migration outcome manually. Confirm with the project manager that the project is complete and that no active work is expected during the migration window.

2. Run the Autodesk migration assistant

   The Autodesk migration assistant is accessed from the BIM 360 Account Admin panel. Navigate to Account Admin > Projects > [Project Name] > Settings, and look for the "Migrate to Autodesk Construction Cloud" option. If you do not see it, your account tier or subscription may not yet have ACC enabled — contact Autodesk support to confirm your account is ready. The assistant will run a pre-migration check that reports on: estimated migration time, document count, custom attribute count, active users, and any known issues. Review this report before proceeding.

3. Execute the pilot migration

   Run the migration. The migration is performed by Autodesk's backend systems; your role is to initiate it and monitor completion. Typical migration times for the Autodesk assistant range from a few minutes for small projects to several hours for projects with tens of thousands of documents. Monitor the Account Admin panel for completion status.

4. Verify the outcome

   After migration, verify the following in the ACC project: (a) all folders are present and match the BIM 360 folder structure; (b) all documents are present, with correct version history; (c) user access is correct — test with at least two user accounts at different permission levels; (d) custom attributes — do the attribute schemas exist, and do existing documents show their attribute values; (e) links — if documents were linked between BIM 360 projects, test that those links resolve correctly in ACC. Document every verification result.

5. Document what the assistant did not carry

   The pilot will surface items the migration assistant did not carry. Common findings: custom attribute schemas missing (you will need to recreate them manually), guest user access not carried (re-invite the guest users), folder-level permissions simplified to role-level (verify and adjust), and project template settings not applied (the ACC project starts without your standard template structure). Document each gap with the specific remediation step required.

Phase 2: Permission mapping (one week, concurrent with pilot verification)

While the pilot project is being verified, use the discovery output to build your permission re-mapping plan.

1. Build the BIM 360 to ACC role map

   Create a spreadsheet with three columns: BIM 360 role/permission, ACC equivalent, and delta (what changes). The key mappings are:

   BIM 360 Account Admin → ACC Account Admin (direct equivalent) BIM 360 Project Admin → ACC Project Admin (direct equivalent) BIM 360 User with read/write on all folders → ACC Member with explicit read/write on root folder (maps correctly in simple cases; verify in complex folder structures) BIM 360 User with read-only on specific sub-folders → ACC Member — limited access with folder-specific read permission (requires explicit folder grants; does not auto-map) BIM 360 Guest with project-level read → ACC Project member invitation with read permission (requires re-invitation; does not auto-migrate)

2. Assign permission owners

   For each project in your migration plan, assign a named person responsible for verifying user access after migration. On large projects, this is the BIM Manager or Information Manager. On smaller projects, it can be the project architect or project engineer. The person must have a verified ACC Project Admin credential. Distribute the verification checklist before migration day, not after.

3. Prepare the guest user re-invitation list

   From your discovery export, extract all guest users (users whose email domain is not your practice's domain). Prepare a re-invitation list: user name, email, project, folders they need access to, and the permission level required. Plan to send re-invitations within 24 hours of each project migration completing.

Phase 3: Data freeze and Revit preparation (72 hours before migration of live projects)

This phase is specific to projects with active Revit cloud worksharing. It is the phase where most real-world incidents occur — including the incident in the opening of this article.

1. Issue the data freeze notice

   Seventy-two hours before the scheduled migration window, send a notice to all project users. The notice should specify: the exact migration window (start and expected end time), that all Revit cloud models will be inaccessible during migration, that users must synchronise-with-central and close Revit before the migration window begins, that no local saves should be made during the migration window, and the contact for questions. Send this to internal users by email, to external consultants by project communication channel. Get explicit acknowledgement from the Revit team leads.

2. Pre-migration Revit worksharing audit

   Six hours before the migration window, confirm that all central files are in a clean state. Open each Revit cloud model as a detached copy and check: are there any local saves in progress (the central file should show no outstanding local changes), does the model open cleanly without errors, and is the model at the correct synchronised state. If any model shows a conflict or an uncommitted local copy, resolve it before migration begins. Do not proceed with migration if there are outstanding local Revit copies that have not been synchronised.

3. Confirm all users are closed out

   One hour before the migration window, send a final notice. Ask project leads to confirm that their team members have closed Revit. If you have a practice Slack or Teams channel, a quick roll-call confirmation is sufficient. Do not assume that a sent email equals a read email. Revit cloud sessions that are left open during migration may lose unsaved changes, as the session will be disconnected when the central file's cloud location changes.

Phase 4: Migration execution (live projects)

1. Execute within the maintenance window

   Initiate the migration for the live project via the Account Admin panel. Log the start time. Monitor the Autodesk status page (status.autodesk.com) and the Account Admin migration status panel simultaneously. Do not proceed with any other project migrations until this one shows "complete" status.

2. Immediate post-migration Revit re-connection

   After the migration completes, the Revit central files need to be re-validated by one user before the team can resume work. Have one designated person (the project BIM lead) open each Revit cloud model fresh from the ACC Docs file location — not from a local copy. They should open it as the central, confirm it loads with the correct worksharing state, and confirm the Cloud Model header in Revit shows the ACC project path (not the BIM 360 path). If it loads correctly, they should synchronise-with-central to write a fresh sync record. Only after this successful verification should the rest of the team attempt to rejoin the workshared model.

3. User access verification

   Within two hours of migration completion, the assigned permission owner should run the access verification checklist: log in as a non-admin user, navigate to each project folder, confirm read and write access as expected, attempt to upload a test file, and delete it. If any permission discrepancy is found, correct it in the ACC Admin panel immediately — do not defer access issues to the next day.

4. Guest user re-invitation

   Send re-invitations to all guest users on the migrated project within 24 hours. The re-invitation should include clear instructions on what they will see: they will receive an email from Autodesk inviting them to an ACC project, they should accept using their existing Autodesk account, and they will find the project in their ACC home screen rather than in BIM 360. Offer a 15-minute orientation call for any external team that has not used ACC before.

Phase 5: Post-migration verification and ACC Bridge setup

1. Run the document reconciliation check

   Compare document counts between BIM 360 and ACC for each migrated folder. The Autodesk migration assistant provides a count; verify it against what you see in ACC. Check that version history is intact for key documents — open a document's version history and confirm the version count matches BIM 360. Spot-check three to five documents for custom attribute values.

2. Rebuild custom attribute schemas

   In ACC Docs Admin, navigate to Document Management > Document Settings > Custom Attributes. Recreate each custom attribute schema from your discovery documentation. Apply the schemas to the relevant folders. For documents that previously had attribute values that were lost in migration, you will need to re-populate them — this is the most labour-intensive part of the post-migration cleanup. If the attribute data is critical (e.g., approval status, review state), prioritise re-population of the most recently active documents first.

3. Configure ACC Bridge for cross-project sharing

   If your practice has projects that share documents across BIM 360 project boundaries — for example, an urban design project that shares base files with an architecture project and a civil engineering project — BIM 360 handled this through project-to-project linking (a limited feature that required both projects to be in the same BIM 360 account).

   ACC Bridge is the replacement and it is substantially more capable. Bridge allows you to set up a controlled sync between folders in different ACC projects. The host project publishes documents to a Bridge connection; the receiving project pulls those documents. You can configure Bridge to sync automatically or on-demand, and you can set the receiving project's permissions so that Bridge-synced documents are read-only in the receiving project.

   To configure Bridge: in ACC Admin, navigate to Bridge > New Connection > and select the source folder. Add the receiving project or projects. Set the sync cadence (recommended: on-demand for large document sets, automatic for small shared reference sets). Test with a single document before configuring the full folder set.

4. Update external integrations

   For each external integration identified in discovery, execute the migration:

   BIMcollab or BIM Track integrations: re-connect the integration using the ACC project credentials. The integration settings will need the new ACC project ID, which is available from the ACC Admin panel under Project > Settings.

   Custom API integrations: update stored project identifiers from BIM 360 project IDs to ACC project IDs. If the integration uses the APS Data Management API, the project hub ID (the b. prefix hub) and project ID will be different for ACC projects. Update webhook registrations. Test each integration endpoint before declaring the integration migration complete.

   Revit cloud model links to external projects: if models in your migrated project have linked Revit models from external consultant projects (structural or MEP models linked into your architectural model), those links need to be re-acquired after migration. Open the host Revit model, go to Manage Links, and reload the linked models from their new ACC Docs locations. If the external project has not yet been migrated to ACC, the linked models will still resolve from BIM 360 — but plan for a re-link when those external projects migrate.

The rollback strategy

Every migration plan needs a rollback strategy. The good news is that Autodesk's migration is one-directional but non-destructive: migrating to ACC does not delete the BIM 360 source data. BIM 360 projects remain accessible in read-only mode after migration. This means your rollback strategy is not a technical rollback (you cannot un-migrate an ACC project back to BIM 360) but an operational rollback: if the ACC migration fails to meet your verification criteria, you can instruct users to continue working in BIM 360 read-only while you resolve the issues, then attempt the migration again.

For Revit cloud worksharing, the rollback is more nuanced. If a Revit central file was re-hosted to ACC during migration and the ACC worksharing environment has issues, reverting means re-hosting the central file back to BIM 360 — a process that requires the file to be saved locally (detaching from ACC) and then re-published as a new central on BIM 360. This is a significant disruption to worksharing state. The best protection against this scenario is the pre-migration verification: do not migrate a Revit project until you have verified the ACC environment in the pilot project phase, and do not migrate Revit-heavy projects until you have proven the Revit re-connection workflow works reliably.

Anti-patterns

Migrating all projects at once

The most common anti-pattern is treating the ACC migration as a bulk operation: initiating migration for every BIM 360 project in a single admin session. The Autodesk migration assistant supports this and will queue all projects for migration. But it means all your Revit cloud models are in flux simultaneously, all your guest users need re-invitation at once, and any migration issues affect the entire portfolio rather than a single project.

Why it fails: Migration issues multiply with portfolio scale. A permission mapping problem that affects ten users on one project is a manageable support ticket. The same problem multiplied across 40 projects simultaneously is a practice-wide outage. And issues tend to cluster: if your custom attribute schema had an edge case that the migration assistant does not handle, every project with that schema will fail the same way.

Do instead: Migrate in cohorts. Archive and completed projects first (lowest risk, no active users). Then active projects with no Revit cloud models. Then active projects with Revit cloud models, in order of ascending risk (smallest team, least active, farthest from delivery deadline first).

Skipping the pilot

Some practices see the pilot project as unnecessary delay and proceed directly to live project migration based on the Autodesk documentation alone. The documentation is accurate but general. It describes what the migration assistant does for typical configurations. It does not know about your practice's specific combination of custom attributes, folder structures, permission hierarchies, and external integrations.

Why it fails: Issues discovered in a pilot project are learnable lessons. Issues discovered when migrating a live project with an imminent delivery deadline are incidents. The pilot project is explicitly where you expect to discover gaps — the permission mapping issue, the missing custom attribute schema, the guest user re-invitation requirement. Run the pilot on a completed project precisely so that finding these gaps has no consequence.

Do instead: Always run a pilot. Budget at least one week for the pilot, including the verification phase. Use the pilot output to update your migration checklist before any live project migrates.

Migrating during active sprint weeks

The opening incident is the archetype. A migration that touches Revit cloud worksharing should never be scheduled during a high-activity period — sprint weeks, review preparation periods, submission deadlines, or the week before a coordination freeze.

Why it fails: Even a perfect migration creates a disruption window. Users need to close Revit, wait for migration, then re-open and validate. On a quiet Friday afternoon, this is a thirty-minute interruption. On a Tuesday during sprint week, it is a team-wide context break that costs two to three hours of productive work, including the time to verify that everyone's local copies are in sync after the migration.

Do instead: Schedule live project migrations for Friday evenings or weekend maintenance windows. For projects in multiple time zones, choose a window that is off-hours for all active team locations, not just the office initiating the migration.

Relying on the migration assistant for complex permission structures

The migration assistant handles role-to-role mapping reliably. It does not reliably handle complex hierarchical permission structures where users have different permissions at different folder levels, or where roles have been customised extensively from the BIM 360 defaults.

Why it fails: Practices with complex permission structures have typically built those structures over years, adding folder-level exceptions one at a time until the resulting structure is difficult to audit even in BIM 360. The migration assistant creates an ACC permission structure that is plausible given the source data but may not match the intended behaviour — especially for users who had view-only access to one sub-folder and edit access to an adjacent sub-folder. These users may find their ACC permissions collapsed to a single level.

Do instead: For projects with complex permission hierarchies, plan for manual permission reconstruction in ACC rather than relying on the assistant. Use your discovery documentation to rebuild the permission structure from scratch in ACC after migration, then verify against the BIM 360 source.

Assuming third-party integrations will self-heal

Some practices assume that third-party tools — BIMcollab, BIM Track, Newforma, Trimble Connect — will detect the ACC migration and update their configuration automatically. They will not.

Why it fails: Third-party integrations are configured with specific project credentials: a project ID, a hub ID, an OAuth token scope. When the BIM 360 project is migrated to ACC, the project ID changes. The integration's stored configuration still points to the old BIM 360 project ID, which now returns 404 on any ACC API call. The integration appears to work (the tool opens, the project name is visible) but document syncing, issue pushing, and document retrieval silently fail.

Do instead: For each third-party integration, execute an explicit re-connection procedure as part of the migration plan. Most major tools — BIMcollab Zoom, BIM Track, Newforma — have published guidance for ACC re-connection. Follow it, and test explicitly after re-connection.

Treating the migration as complete when the assistant shows "done"

The migration assistant completion status means the Autodesk backend has finished its transfer operation. It does not mean your practice's workflows are functioning correctly. The verification phase exists precisely because "migration complete" and "migration verified" are different states.

Why it fails: The migration assistant does not know about your Revit worksharing state, your custom attribute values, your guest users, or your integrations. It runs its process and reports success for that process. The rest — the verification, the Revit re-connection, the guest user re-invitation, the integration update — is your responsibility.

Do instead: Never communicate a migration as complete to users until the full verification checklist has been signed off. The verification checklist (see the audit checklist at the end of this article) should be co-developed with your project teams before migration begins.

Case studies

Case study 1: The 400-user practice, revisited

The practice in the opening scenario completed a successful migration on a second attempt, eight weeks after the incident. The incident report had identified three root causes: no active account admin monitoring the Autodesk Account notifications, no pre-migration communication to users, and no Revit worksharing verification before the migration window.

The remediation plan assigned a named BIM Manager as the Autodesk Account Admin lead, with a shared inbox monitored by two people. They ran the discovery phase over two weeks, inventorying 27 active BIM 360 projects. Of those, 14 had active Revit cloud models.

They migrated the 13 non-Revit projects first, over a three-week period. Each project was migrated on a Friday evening with a two-hour verification window before Monday morning. They discovered two permission mapping issues in the first batch — both in projects that had complex consultant access structures — and resolved them using manual ACC Admin panel configuration.

The 14 Revit projects were migrated over four weekends, in groups of three or four. Each migration was preceded by a Thursday afternoon notification to all project users with explicit instructions to check in their models, confirmed by a roll-call in the project Teams channel. No project had a Revit session open at the time of migration. Re-connection was verified by the project BIM lead before the weekend ended. No data was lost.

The total migration effort for 27 projects was approximately 80 hours of BIM Manager and IT time, spread over eight weeks. The practice's assessment at the end: the migration itself was manageable; the incident in the first attempt was entirely preventable.

Case study 2: Infrastructure and civil engineering consultancy — ACC Bridge as a workflow improvement

A specialist civil and infrastructure consultancy with 80 staff migrated to ACC as part of a joint venture project where the principal architectural firm was already operating on ACC. Before migration, the consultancy was on BIM 360 and sharing models with the architectural firm through a manual download-and-upload workflow — a civil engineer would export a model from BIM 360 Docs, send it by email, and the architectural BIM Manager would upload it to BIM 360 as a new version. Version control was a spreadsheet.

Post-migration, both firms are on ACC. The architectural firm set up an ACC Bridge connection from their coordination model folder to the civil consultancy's project. Civil staff can now upload updated models to their own ACC Docs folder, and those models automatically sync into the architectural firm's coordination project on their defined cadence — in this case, twice weekly on Tuesday and Thursday.

In the six months following the bridge setup, the joint venture recorded zero manual model transfer events. Version discrepancies between the architectural coordination model and the civil model were eliminated as a class of issue — the architectural team always has access to the latest civil model without any manual action.

This outcome would not have been possible in the BIM 360 era without significant manual process. ACC Bridge, while not a headline feature in Autodesk's marketing, was the single most impactful operational change this consultancy experienced in the migration.

Case study 3: Resolving the custom attribute loss

A MEP engineering firm with 120 users had invested heavily in BIM 360 Docs custom attributes for document management. They had built a status tracking system using eight custom attributes: discipline, system type, review round, reviewer name, review status, approval date, contractor distribution date, and as-built flag. These attributes were populated on approximately 14,000 documents across 18 active projects.

The migration assistant carried the folder structure and documents correctly. It did not carry the custom attribute schemas. On the morning after migration, the MEP firm's document manager discovered that none of the 14,000 documents showed any custom attribute values — the attributes were present as empty fields on some documents, and completely absent on others, depending on how the migration had handled schema carryover.

Recovery required three steps. First, the attribute schemas were rebuilt manually in ACC Docs Admin — a three-hour task. Second, the attribute values needed to be re-populated. For the most recently active documents (approximately 2,000 documents that had been updated in the previous 90 days), the team used a manual re-population workflow: each project BIM lead was given a subset of documents and a reference export from BIM 360 (exported before migration) showing the attribute values, and re-populated them over two weeks. For older documents (12,000+), the firm accepted that the historical attribute data was lost and put a policy in place to populate attributes on new revisions going forward.

The total remediation cost was approximately 120 hours of staff time. The firm's post-incident assessment identified the recovery plan clearly: the custom attribute export from BIM 360 before migration should have been a formal deliverable, not a post-migration afterthought. They have since created a migration pre-flight checklist that includes a structured custom attribute export for every project before migration begins.

Case study 4: The API integration rescue

A 60-person construction management firm had built an internal dashboard using the BIM 360 Data Management API. The dashboard displayed RFI counts, submittal status, and open issue counts by project, pulling data every four hours via a cron job. The integration used stored BIM 360 project IDs and a long-lived OAuth 2.0 token.

After migration to ACC, the dashboard continued to display data — but the data was stale. The cron job was calling the BIM 360 Data Management endpoints with the old project IDs, which returned 404 responses. The error handling in the cron job silently swallowed 404 responses and displayed the last-known values rather than reporting the failure. The dashboard looked operational.

The firm discovered the issue three weeks after migration when a project manager noticed the dashboard's open RFI count had not changed despite several RFIs being closed. IT investigated and found 504 hours of silent 404 responses in the API logs.

Recovery required updating the stored project IDs from BIM 360 format to ACC format (which the IT developer extracted from the ACC Admin API), updating the OAuth token scope to ACC project scopes, and adding explicit error reporting to the cron job so that API failures surface as alerts rather than silent stale data. The total fix took one developer day.

The lesson applicable to all API-integrated practices: Silent failures in API integrations are worse than loud failures. After any infrastructure migration, add explicit health checks to all integrations — verify that the API is returning current data, not cached data from before the migration. A health check that fails loudly is infinitely preferable to a silent failure that misleads users for weeks.

Limits and caveats

This playbook assumes a standard Autodesk Account structure

The playbook above covers the migration path for a practice that uses a single Autodesk Account, with BIM 360 projects within that account, and where both internal and external (guest) users are managed through the standard Autodesk identity system. Practices with more complex structures — multiple Autodesk Accounts, enterprise SSO integration, or federated identity management through a corporate Azure AD or Okta tenant — will encounter additional steps that this playbook does not cover.

Specifically: if your Autodesk Account is linked to an enterprise identity provider (IdP) for single sign-on, the ACC migration may interact with your SSO configuration in ways that require co-ordination with your IdP team. User account mappings between your IdP and Autodesk's identity system may need to be updated. We recommend engaging Autodesk's enterprise support team before migration if you have SSO enabled.

The Autodesk migration assistant capabilities change with account tier

The migration assistant functionality described in this playbook is based on the version available to Autodesk Construction Cloud Pro and Enterprise tier accounts. Essential tier accounts (the entry-level ACC subscription) may have access to a subset of migration tooling. If your practice is on an Essential tier subscription, verify with Autodesk support which migration features are available before planning.

ACC does not replicate every BIM 360 feature

Some BIM 360 features have no ACC equivalent, or have ACC equivalents that behave differently. Specific areas where we have observed differences in practice:

BIM 360 Glue-specific workflows: BIM 360 Glue (the older clash detection and model aggregation tool) has been largely superseded by ACC Model Coordination. But BIM 360 Glue supported some model aggregation workflows — particularly for Navisworks-native coordination — that ACC Model Coordination does not directly replicate. If your practice had Navisworks-centric coordination workflows running through BIM 360 Glue, verify the ACC Model Coordination capability against your specific workflow before committing to migration.

BIM 360 Field forms: Custom forms built in BIM 360 Field do not automatically migrate to ACC Build. Form structures need to be rebuilt in ACC Build's form builder. The data from completed forms in BIM 360 Field is accessible in BIM 360 (read-only) but does not populate into ACC Build's form records.

Data residency: BIM 360 projects in certain regions (particularly the EU, where BIM 360 supported EU data residency) need to verify that their ACC account is configured for the correct data region. ACC supports regional data residency, but the region must be confirmed at account setup time. A BIM 360 EU-hosted project that is migrated to an ACC account not configured for EU data residency will have its data moved to the default US region. This has GDPR implications for practices operating under EU data protection law.

This playbook covers the migration, not the long-term ACC operational model

Getting your projects onto ACC is the migration. Using ACC effectively as your long-term platform is a separate operational discipline. ACC's full capabilities — Model Coordination automated clash sets, Insight analytics dashboards, Bridge multi-project workflows, the ACC Cost module for contractor-side budget management — require ongoing configuration, user training, and process adaptation that goes beyond the scope of this migration playbook.

We will cover ACC operational best practices — including Model Coordination setup for multi-discipline projects, Insight dashboard configuration, and Bridge workflow governance — in future posts.

Sources and further reading

The following primary sources were consulted for this article. All URLs were verified accessible in June 2026.

• Autodesk Construction Cloud Help Centre — Getting Started — Autodesk's official help documentation for ACC, covering product modules, admin configuration, and user workflows. The canonical first reference for any ACC product question.

• Autodesk Construction Cloud Docs Help — Permissions Overview — Specific documentation on the ACC Docs permission model, folder-level permissions, and role assignments. Essential reading before any migration that involves complex permission structures.

• Autodesk Platform Services (APS) — Data Management API reference — The Data Management API documentation covering both BIM 360 and ACC project identifiers, project structure, and the API differences between BIM 360 and ACC projects. Relevant for practices with API integrations.

• Autodesk Community — ACC Migration forum threads — Practitioner-reported migration issues, workarounds, and Autodesk staff responses. The most current source of known issues not yet documented in official help content.

• Autodesk BIM 360 Docs — Custom Attributes documentation — BIM 360 Docs official help, including the custom attributes documentation that describes the attribute schema structure, data types, and the document report export that is the source for pre-migration attribute data backup.

• Autodesk ACC Bridge — Overview documentation — ACC Bridge official documentation covering cross-project sharing, sync cadence configuration, and permission management for Bridge connections. Relevant for any multi-project or multi-organisation workflow.

• Autodesk University — "BIM 360 to ACC Migration: Lessons from the Field" (AU 2023) — A practitioner presentation from Autodesk University 2023 covering real-world migration experiences, common failure patterns, and recommended phasing approaches. One of the most useful practitioner-facing resources on migration practice.

• Autodesk status page — status.autodesk.com — Real-time and historical Autodesk service status. Relevant during migration windows to monitor for platform-side issues that could affect migration timing.

• AECbytes — Autodesk Construction Cloud Review — Independent AEC technology analysis of the ACC platform, covering product strengths, limitations, and comparison to BIM 360. Not a migration guide, but useful context for understanding where ACC represents genuine advancement vs. feature parity with BIM 360.

• BIMcollab — ACC Integration Setup Guide — BIMcollab's documentation for re-connecting BIMcollab Zoom to an ACC project after migration. Directly relevant for practices using BIMcollab as their primary issue management and BCF coordination platform.

• buildingSMART International — BCF 3.0 specification — The BIM Collaboration Format specification that underlies ACC's issue management interoperability with third-party tools including BIMcollab, BIM Track, and Solibri.

• ISO 19650-2:2018 — Information management using building information modelling — Part 2: Delivery phase of the assets — The standard that defines the CDE workflow states (WIP, Shared, Published, Archived) that ACC Docs implements. Understanding ISO 19650 CDE states clarifies why the permission model differences between BIM 360 and ACC matter for information management governance.

BIM Mobius publishes practitioner-level content for AEC professionals working with digital construction workflows. This article reflects current platform behaviour as of June 2026. Autodesk's ACC product and migration tooling continues to evolve; verify specific steps and timeline commitments against current Autodesk documentation before executing a migration.