Revit Central Model: ACC or File Server — A Comparison
Revit central model: ACC or a file server — compare risks, speed, access rights and InfoSec requirements to choose the right option for your team.
What the debate is about: where to store the Revit central model
The Revit central model is the main project file the team works on together. Each person opens a local copy, makes changes and synchronizes with the central model to send their updates and receive colleagues’ changes. So the storage location is more than a “folder”—it’s a critical point: if access is unstable or permissions are misconfigured, everyone’s work stalls.
Usually the choice comes down to two options:
- store the model in Autodesk Construction Cloud (ACC) and work through cloud synchronization;
- keep the file on a corporate file server (in the office or a data center) and connect over the local network or via VPN.
This directly affects downtime and data-loss risk because Revit performs many small read/write operations when opening, saving and synchronizing. Any channel instability, latency, VPN drop, overloaded server, lock problems or permission conflicts cause sync errors, “broken” local copies and time spent on recovery.
Before a pilot it’s useful to agree on basic assumptions, otherwise the comparison will be unfair: who works in the model (in‑house staff, remote workers, contractors), where they connect from (one office, several sites, home networks), how support is organized (who manages the server, VPN, accounts, backups) and what InfoSec constraints exist (is cloud storage permitted, what logging and access requirements apply).
A simple example: a team in Almaty and a contractor in another city. With a file server over VPN, synchronization may noticeably slow down and a drop at the wrong moment leads to manual repair of local files. In ACC you remove the VPN tunnel risk, but questions arise about accounts, access policies and cloud approval by InfoSec.
If the organization is large and regulated, involve InfoSec and IT from the start, not after the first incident. In such projects a systems integrator (for example, GSE.kz) often helps gather requirements, prepare a pilot and resolve sensitive points about access and responsibilities in advance.
Two approaches: file server and Autodesk Construction Cloud
When you compare ACC and a file server, you evaluate more than “where the file lives”: you assess the whole collaboration method—how users connect, who manages access, how failures are handled and where responsibility boundaries lie.
Option 1: central model on a file server
Typically the central Revit file sits on a network share (SMB) in the office or data center. Office users connect over the LAN and domain permissions. Remote users add VPN; in heavier scenarios teams use RDP so Revit runs on a remote PC “near” the server.
Strength: IT usually already knows how to support this: familiar backups, policies and tools. Weakness: performance depends heavily on the network between user and server. Any connection instability turns into long synchronizations and increases the risk of workset and local-file issues.
Option 2: Autodesk Construction Cloud
In ACC the central model is placed in a cloud project and collaboration happens via cloud synchronization. The team connects from office, home or while traveling without exposing file paths. Administration is often easier: you can add participants faster, limit access by project and folder, and see activity.
Practical example: if designers are in Almaty and Astana, the server scenario often bottlenecks on VPN and interoffice links. In ACC the bottleneck is more often each user’s internet quality, but you don’t have to extend access into the company’s internal network.
Cloud does not eliminate internal InfoSec requirements. You still need to agree on accounts, MFA, permissions, storage and auditing. In regulated organizations an integrator like GSE.kz usually joins at the access-architecture and support-scheme stage.
Regardless of storage choice, some things in Revit don’t change: naming rules and worksets are needed, a clear “who owns the model and permissions” scheme, regular checks and backups (implemented differently), and a short team protocol—how to open, how to sync and what to do on conflict. Moving storage won’t fix model chaos.
Data risks: what breaks most often and why
The worst scenario is when the team loses time because the central model is corrupted or cannot synchronize. Risks exist both on a server and in ACC, but causes differ.
Loss of connection and model corruption
On a file server the most common issue is connection problems: network drops, overloaded VPN, unstable Wi‑Fi at the office or site. During sync Revit writes many changes and a disconnect can produce errors or even corrupt the central model. In ACC the risk shifts toward external dependence: if a user has unstable internet or cloud access is temporarily restricted, work also stops. The chance of corruption due to local network micro-pauses is typically lower in ACC.
Example: a designer in a branch connects to the head office central model via VPN. During the day the connection “jumps”, syncs hang and the team starts saving local copies “just in case”. This quickly leads to version chaos.
Synchronization conflicts and human factor
Most problems come from habits, not technology: working hours without syncing, parallel edits in the same area, “borrowed” elements, warnings ignored, manually copying the central file into a folder or messenger, and no naming/versioning rules for exports.
ACC often enforces discipline because work is centralized and external participants are easier to add by role. On a server discipline relies on administration and regulations.
Backups and recovery
Don’t check “do we have backups”, check “can we restore within an acceptable time”. On a server it’s easier to set backups per your standards and keep copies where InfoSec requires, but the responsibility is fully yours. ACC covers part of the tasks, yet restoring a specific model state still should be practiced in a pilot: who requests a rollback, who approves it and how long it takes.
Contractors and external participants
The more external people, the higher the risk of leaks or accidental deletion. On a server this is often handled with broad “project-folder” access and sharing via copies. In ACC you can limit rights more precisely and revoke access faster once work completes. If transparency and control are critical, start comparisons from this block.
Speed and stability: what the team will feel
The argument usually starts from impressions: for some, syncs take minutes; for others, seconds. Practically, the team perceives network delays and predictability more than “cloud vs server.”
With a server central model, the best experience is for users on the same LAN as the server. Opening the model, Synchronize with Central, exporting views and saving are smooth while the network and server disk subsystem cope. But once VPN, long routes and unstable links appear, sync performance depends on latency (ping) not only bandwidth.
ACC often benefits distributed teams: the path to the cloud for each user may be shorter and more stable than to the office via VPN. This is noticeable when some designers work from home or a branch. Still, speed can vary with internet quality, and perceptions differ even within the same team.
Measure not only complaints but objective metrics: latency stability to the storage point, VPN quality (packet loss, disconnects, tunnel reestablishment), office network load at peak hours, file-server performance and consistent Revit settings on workstations.
A fair comparison needs identical actions on the same model at the same time. For example: take one “heavy” model, fix steps (open, create local file, 3 syncs, export 2–3 views) and run the test with 3–5 users: one in office, one via VPN, one in another city. Record times in a table rather than discussing them in chat.
Practical example: if a team in Almaty works from the office and colleagues in Astana connect via VPN to a server in Almaty, the office will feel “everything is fast” while remote users constantly wait for sync. In such cases tidy the network and server first, then compare with an ACC pilot. As a systems integrator, GSE.kz often sees that proper network and infrastructure tuning gives results comparable to changing storage, without process surprises.
Access rights: managing users without surprises
Permissions in Revit can break the process as badly as weak internet. It’s not only “who can open the file” but who can modify the central model, load links, create local copies and see worksets.
Access is needed at several levels: project, folder, the central model itself, and linked files (IFC, CAD, families, point clouds, shared coordinates). If any level is closed or misconfigured, Revit shows odd errors: from inability to create a local file to “lost” links.
On a file server the typical problem is not lack of rights but unpredictability. NTFS permissions, sharing and inheritance can conflict. A user may appear in the project group but be able to read and not write in a subfolder, inherit rights through multiple groups so it’s unclear which wins, lose access after a folder move or owner change, or accidentally gain excess rights via inheritance and then can’t update links though the model opens.
In ACC access is usually simpler: by project and folder with separate invitations for externals. This is better for contractors because they get exactly what they need without access to your file server and internal resources.
A silent threat on both cloud and server is account lifecycle. Decide in advance who creates users, who approves rights and what happens on termination. Good practice: temporary contractor access with an expiration date and regular reviews of who actually worked on the project last month.
InfoSec and compliance: what to agree
The choice between server and ACC often hinges not on convenience but on what InfoSec will approve. Gather answers to common questions and document them before the pilot, otherwise it can be stopped by a formal restriction.
Questions InfoSec asks
InfoSec wants to know where data is physically stored, who connects and how, and whether you can prove who did what. For a file server the emphasis is on share permissions, domain accounts, backup and recovery. For ACC it’s on cloud responsibility model, identity management, action logging and rules for working with external contractors.
At minimum check: where files and backups are stored and the RPO/RTO, whether action logs exist and who reviews them, how access revocation works (tokens and local copies included), how data is protected in transit and at rest at the organization level, how contractor access is formalized and how quickly it can be revoked.
Devices, remote access, passwords and MFA
A common trap: the model is stored “correctly” but users access it from unmanaged laptops. Agree whether working outside the network is allowed, if corporate VPN is required, whether managed devices (MDM/EDR) are mandatory and whether local caches are permitted.
Practical scenario: a government client allows work only from domain-joined devices with MFA and prohibits exporting data to personal drives. Then a server needs a strict remote-access scheme and ACC needs account settings and sign-in policies.
To avoid decisions based on words, create a collaboration protocol, a role-based access matrix, an account policy, backup and recovery tests and a list of responsible parties (IT for infrastructure, InfoSec for control, project manager for discipline).
If you need a neutral assessment and a package of documents for InfoSec approval, systems integrators often do this. For projects in Kazakhstan these tasks are commonly done with GSE.kz so InfoSec requirements are considered before procurement and deployment.
How to choose for your organization
The choice usually depends not on “what’s trendier” but on constraints: where the team is located, who participates and which InfoSec rules are non‑negotiable. It’s essentially a question of managed risks and collaboration convenience.
A server approach is simpler when you have one office, a stable LAN and strict isolation from external access. It works well when all participants are in the same LAN, contractors don’t connect directly and InfoSec requires that the model remains physically inside the perimeter.
ACC often wins when the team is distributed across cities, there are external contractors and many approvals. There predictable synchronization, role-based access and clear out-of-office work matter more.
Quick direction questions: where are 80% of users, do external designers or clients need regular access, how critical is downtime, what limits you more (network channels or InfoSec policy), and does a client require a specific data location or audit capability?
Then check the “conditions that break the paper design.” ACC needs stable internet and pre-agreed InfoSec rules (accounts, MFA, device control, action logs). A server needs discipline: backups, folder-permission control, unified Revit versions and a clear workflow—otherwise the scenario “someone accidentally overwrote the central” happens more often than you think.
Sometimes hybrid scenarios help, if permitted: keep the internal central model on a server and distribute controlled sets/exports to externals via cloud; or use ACC for projects with contractors while archiving and long-term storage follow the organization’s local rules.
To avoid debates, pick a representative project and run a 2–4 week pilot with a real team. Measure sync times, conflict counts and IT support costs. For Kazakhstan organizations with government requirements this is crucial: a technically convenient option may fail without formal InfoSec approval. GSE.kz usually starts with a pilot and a requirements matrix so the decision passes both operations and security review.
Step-by-step evaluation and pilot plan
The ACC vs server debate is most often settled by a short pilot. Describe exactly what you will test and agree how to measure results.
1) Prepare scenarios and source data
Take repeatable daily operations: open the model, create a local file, synchronize, export to NWC/IFC, connect links (architecture, structures, MEP). Five to seven scenarios and one or two mid-size models are enough—avoid “perfect demo” files.
Collect infrastructure inputs: where participants are located, their internet, proxy/firewall restrictions, workstation resources, VPN and interoffice link setups.
2) Run the pilot and collect metrics
Run the pilot on a real project with a limited group, e.g. 6–10 people from two offices. For comparison it’s critical that users perform the same scenarios.
Capture metrics, not just impressions: time to open and first sync, frequency of conflicts and sync errors, time lost to disconnects, number and reasons for support tickets, and time to recovery after a failure (file, access, version).
After the pilot produce a short 1–2 page summary: what worked, what didn’t, which InfoSec limits appeared and what process changes are needed. If you lack internal resources, an integrator such as GSE.kz can run the pilot and document results so IT and InfoSec accept them.
Common mistakes and traps during rollout
Problems usually come from unchanged collaboration rules that remain “in people’s heads.” Even after choosing a storage option, without agreements the team quickly faces conflicts and “who broke the model” disputes.
On a file server teams often mix folder rights, worksets and models. A user may see the project folder but not be able to sync, or conversely gain excessive access. A simple matrix—roles (modeler, coordinator, BIM manager) and allowed actions (open, sync, publish, archive)—helps.
Another typical error is working over unstable VPN without sync rules. People keep models open all day, rarely Sync, close a laptop “on pause” then return to long conflicts or corrupted local files. Short rules are needed: when to Sync, what to do on disconnect and when to always close the model.
An underrated risk: backups exist but recovery was never tested. Quarterly do a test: restore a copy of the central model, open it, sync and confirm the archive is readable and the recovery steps are clear.
User training is often skimped on and that’s costly. A two-hour practical session on a real project usually pays off quickly: when to create a local copy, how to close models correctly, how to handle warnings and not block colleagues.
Finally, pilots are often based on impressions. Agree upfront on metrics: average open and sync times, number of conflicts and errors per week, how often a BIM coordinator intervened, recovery time after failures and a short team satisfaction survey.
Short checklist and next steps
If the debate drags, fix requirements and run a quick check. It will reveal where risks are truly higher for your setup.
Pre-choice checklist
Check network and remote work: measure latency and its stability in office and home, evaluate VPN impact on sync and peak-hour load. Define access and account handling: roles, administration, external participants, MFA and action logging. Set data handling: backups, real recovery tests on a live project, version storage and behavior of links (Revit links, families, shared parameters). Agree team processes: sync rules and workset practice, who owns models and libraries, and the incident-response order. Separately align InfoSec: data location, encryption and access requirements, audit and documentation list.
One simple test: take a typical project, include 3–5 people in different locations and compare where more time is spent waiting for sync, where conflicts are frequent and who has a clear support path.
Next steps
Run a minimal pilot for 2–4 weeks to decide by facts, not opinions.
- Fix success criteria: open and sync times, conflict counts, recovery time after incidents, and access provisioning convenience.
- Inventory: links, servers, policies, external participants and InfoSec requirements.
- Set up the pilot and support: who issues access, who logs events, and how problems are escalated during the day.
- Summarize and write the protocol: which option you choose, why, and who is responsible for backups, access and updates.
If you lack internal resources, engage an integrator experienced in aligning access and InfoSec and supporting infrastructure. For organizations in Kazakhstan it’s often convenient to do this with GSE.kz, especially if you’re also planning workstations or server infrastructure for BIM.
FAQ
Why is the choice of storage for the Revit central model so important?
The central model is the single source of truth for team work: everyone synchronizes with it. If the storage location causes delays, disconnects, or permission confusion, you lose time to sync errors, conflicts and recovery—and sometimes risk corrupting the model.
Which is usually better: ACC or a file server?
If the team is in one office with a stable LAN, a file server usually gives predictable performance and familiar administration. If the team is distributed across cities, has lots of remote work and contractors, ACC often reduces VPN dependence and simplifies project-based access.
What risks typically arise when using a server-hosted central model?
The most typical risk is a disconnect or unstable connection during Synchronize with Central, especially over VPN or Wi‑Fi. That causes sync errors, corrupted local files and time-consuming manual recovery. With ACC, the bottleneck is more often the user’s internet quality and cloud access policies defined by InfoSec.
How is it better to connect contractors: via the server or via ACC?
ACC is usually more convenient when you have many external participants: you can add and revoke users faster, grant precise project- and folder-level rights, and avoid giving contractors access to your internal network. On a server, externals are often given broader permissions or work via copies, making control harder.
Is it feasible to work with a server-hosted central model from another city?
A server setup can work from another city, but it heavily depends on VPN quality and latency between the user and server. If the VPN is unstable, synchronizations become slow and error-prone. A practical workaround is RDP/virtual desktops hosted near the server so Revit runs inside the perimeter rather than over a slow link.
What should be agreed with InfoSec if considering ACC?
At minimum agree: who creates accounts, how rights are granted and revoked, whether MFA is required, whether unmanaged devices are allowed, where backups are stored and the expected recovery times (RPO/RTO). Also check audit logs and who reviews them. Without these answers a pilot can be stopped by a formal ban.
How to run a pilot and compare options without arguments?
For a fair comparison use the same live model and identical actions: open, create a local file, several synchronizations, export views/formats, and work with linked models. Test with at least 3–5 users from different locations (office, VPN, other city) and record times and errors in a table rather than relying on impressions.
Why does Revit show strange access errors even though the folder seems open?
Check permissions at every level: project folder, the central model itself and all links (families, CAD/IFC, point clouds, shared coordinates). On a server, inheritance and overlapping group rights often cause a user to appear ‘in the project’ but be unable to write to a subfolder. Create a simple roles-and-rights matrix and keep it current.
How to organize backups and recovery for the central model?
Focus on a proven recovery procedure, not just the existence of backups. On a file server your IT team is fully responsible: backups, storage and recovery tests. In ACC the platform covers some mechanisms, but you still must rehearse who requests a rollback, who approves it and how long recovery takes — ideally during the pilot.
Which team habits most often break Revit collaboration?
Don’t leave models open all day without syncing, don’t close a laptop with an active session, don’t copy the central file manually “just in case”, and don’t ignore conflicts and warnings. A short working protocol—when to Sync, what to do on disconnect, who owns the model and how to act on conflicts—usually fixes most problems.