Key Takeaways
- IT support for architecture firms has to account for how design software actually behaves, not just email and web browsing.
- Slow model performance is usually a network and storage problem rather than a workstation problem, and replacing computers often changes nothing.
- Failed Revit synchronizations are almost always an infrastructure condition, not user error.
- Autodesk’s own documentation notes that server-based workshared central models cannot be rolled back, which puts the weight on your backups.
- Consultant file exchange through ad hoc links and personal cloud accounts leaves project access nobody is tracking.
- A local provider matters here, because evacuation season is a continuity plan rather than a hypothetical.
Most architecture firms do not go looking for a new IT provider because something dramatic happened. They go looking because of a slow accumulation of small frustrations. A model that takes four minutes to open. A sync that fails at five o’clock on a deadline day. A consultant who emails a revised structural model that nobody is quite sure how to fold in. A help desk that keeps asking whether the software has been reinstalled.
None of those are catastrophes. Together they describe a firm whose technology was set up by someone who did not really understand how architects work. That gap is the biggest difference between general business IT and genuine IT support for architecture firms, and it shows up in places a standard support contract never looks.
If you run or help run a practice in Greater New Orleans, here is what that difference actually consists of.
Your Files Are Not Like Other Businesses’ Files
An accounting firm’s largest file might be a few megabytes. A design practice routinely works with models measured in hundreds of megabytes, and several people need to be in the same model at the same time.
Autodesk’s own documentation describes how this works. In a workshared Revit project, the central model is the master project file that stores ownership information for every element, and each team member works from a local copy, using Synchronize with Central to push edits back. That design is what makes collaborative modeling possible. It also means your firm’s productivity depends almost entirely on how quickly that central file can be reached and how reliably it can be written to.
Sync Failures Are an Infrastructure Problem, Not User Error
Ask a group of architects about their worst technology day and a surprising number will describe a failed synchronization. Work that existed at four in the afternoon does not exist at six.
These failures usually trace back to infrastructure. An unstable network path. A server under memory pressure. A backup job running in the middle of the working day. Antivirus scanning model files while Revit is trying to write to them. A workstation dropping off wireless mid-sync. Every one of those is a fixable condition, and none of them is the fault of the person who lost the afternoon.
Backups Have to Match How the Software Behaves
Every IT provider will tell you they back up your data. Far fewer can tell you what recovering a Revit project actually involves.
There is a specific trap worth knowing about. Autodesk’s documentation notes that with server-based worksharing you cannot roll back the central models of server-based workshared projects, unlike file-based worksharing. In plain terms, depending on how your firm is set up, the ability to step a project back to yesterday morning may not exist inside the software at all. Your backup system is the only route back.
That raises questions most firms have never been asked. How often is the central model captured, and is it captured in a state Revit can reopen rather than mid-write? When somebody asks for a drawing from a project that closed out four years ago, where does it live, and can anyone still open it? Has anybody tested a restore, or is the green tick on the dashboard the whole of the evidence?
Consultant File Exchange Is a Security Problem in Disguise
Architecture is collaborative by nature. Structural, MEP, civil, landscape and the client all need to send and receive files, and your firm sits in the middle of that traffic.
In most practices this happens through whatever was easiest at the time. Email attachments until the file is too large. A free transfer service. A personal cloud account somebody set up years ago. A client portal that one project uses and no others do. Each was a sensible decision in the moment. Collectively they mean project information is scattered across services your firm does not control, shared through links that may never expire, with no record of who can reach what.
There is a financial angle too. Construction projects involve large payments between parties who mostly communicate by email, which makes them a natural target for payment redirection fraud. A convincing message asking for updated banking details, arriving at the right moment in a project, is a far more realistic threat to a design practice than anything cinematic. Our cybersecurity services in New Orleans treat that as a process problem as much as a technical one: verification steps for payment changes, a second channel for unusual requests, and a team that knows it is allowed to slow down and check.
Software Versions and the Machines Themselves
Design software is expensive, version-sensitive and unforgiving about mismatches. A firm running three different Revit versions across its workstations will eventually hit a project where that matters, usually at the worst moment, because a model upgraded to a newer version cannot simply be opened in an older one.
Workstations have their own rhythm. Design machines get pushed harder than general office computers and reach the end of their useful life sooner, and firms tend to notice this one machine at a time rather than as a pattern. One gets replaced when it becomes unbearable, then another, and the fleet drifts into a state where no two are quite the same. A provider who understands practices like yours tracks which version is deployed where, when licences renew, and which machines are approaching replacement, before a project forces the decision.
Design-aware: Measures the path to the central model first, because the constraint is usually storage, network or VPN rather than the desk.
Design-aware: Treated as an infrastructure symptom and traced to the scan, backup window or network path causing it.
Design-aware: Captures central models in a reopenable state and tests restores, knowing server-based projects cannot be rolled back in software.
Design-aware: One controlled exchange route, with access granted per project and revoked at closeout.
Design-aware: Tracks versions and licences across the firm so project teams are never mismatched.
Why Local Matters Here
There is a practical argument for working with a provider in your own market. They know the building stock, the seasonal rhythm of the region, and what an evacuation week does to a project schedule. They can be in your office when a problem needs hands on it. And they understand that a New Orleans practice plans its continuity around hurricane season the way firms elsewhere plan around nothing in particular.
How We Can Help
Courant has supported small and mid-sized businesses across Greater New Orleans since 1997, and architecture practices are among them. Our IT services for architecture firms look at the whole picture rather than the ticket in front of us: how your models are stored and reached, how files move to consultants, how your archives are protected, and what happens to all of it when the city is told to leave.
Underneath that sit the same foundations every client gets. Our managed IT services in New Orleans cover monitoring, patching, backups and hardware lifecycle, and our cybersecurity services in New Orleans handle the access controls and payment verification processes that matter when project money is moving between parties by email.
If any of this sounded familiar, the useful next step is not a proposal. It is an honest look at how your current setup handles the specific demands of design work: where your central models live, how quickly they can be reached, whether your backups could actually bring a project back, and how files are reaching the rest of your project team today. Schedule a 15-minute consultation and we will walk through it with you, or contact our New Orleans team if you would rather start with a question. Either way you will come away knowing which of these apply to your practice and which do not, which is worth something whether or not you ever work with us.
Frequently Asked Questions
What makes IT support for architecture firms different from general business IT?
The files and the software. Design practices work with very large models that several people edit at once, which puts demands on storage, network and backup design that ordinary office IT never encounters. A provider who has not supported a design practice tends to treat slow performance as a workstation issue and sync failures as user error, and both diagnoses are usually wrong.
Why is our Revit model slow even though we bought new computers?
Because the limiting factor is often not the computer. In a workshared project each person works from a local copy and synchronizes back to a central model, so performance depends on how fast that central file can be reached and written to. If the server, the disks, the network path or the VPN is the constraint, faster workstations change very little.
Can a Revit project be rolled back if something goes wrong?
It depends how worksharing is set up. Autodesk’s documentation notes that central models in server-based workshared projects cannot be rolled back, unlike file-based worksharing. Where rollback is not available in the software, your backup system is the only route back, which is why testing restores matters more than most firms assume.
What is the safest way to exchange files with consultants?
One controlled route that the whole firm uses, with access granted per project and removed at closeout. The risk is rarely a single sharing link. It is the accumulation of them across years of projects, held in services the firm does not control, with nobody tracking who still has access.
How should a New Orleans practice plan for hurricane season?
Work backwards from a specific question: if the office is unreachable for two weeks, what still works? That covers where project files live, whether they survive the loss of the building, whether the firm can still invoice and communicate, and whether anyone has tested bringing a project back rather than trusting a dashboard.



