Most upgrade failures don’t happen during the upgrade. They happen six months earlier when everyone was “just trying to get drawings out the door”. By the time you hit Upgrade, the Revit upgrade process is simply showing you the consequences.
This is the checklist I run before pushing a single model through the ACC Project Upgrader. It’s boring work, but so is brushing your teeth, and skipping either eventually hurts.
1. Open the model and run Audit
Open the model in the version it currently lives in and tick Audit on open. Let Revit complain. Write down anything with element IDs or family names. Those become your blockers.
Why? Audit catches the low-level corruption that cloud upgrades absolutely choke on.
2. Purge like you actually want the upgrade to succeed
Run Purge Unused until there is nothing left to purge. Don’t just run it once. Don’t forget materials either. They’re not purged through the Revit Purge interface, so grab my materials purge macro to get the job done.
Also purge unused parameters if you have a Dynamo or Python workflow for that. If not, clear what you can through the UI.
Why? Purging strips out years of accumulated junk that Revit would otherwise try to migrate, reconcile, or regenerate, all of which slows or breaks upgrades.
3. Unload links
This one could be considered optional, and you need to be smart about it if you’re hosting your elements to elements in linked models, but if you’re not going to be caught out with that one, it’s always a good one to speed up your upgrade. Unload:
- Revit links
- CAD links
- IFCs
- point clouds
- anything else that drags half the internet into your model
If something is linked from a drive path (C:\, network share, USB stick someone plugged in during a site visit), fix it now. On ACC, links should resolve via Desktop Connector or a cloud collaborated model, not your local machine.
Why? The fewer things Revit needs to touch during the upgrade, the less chance it will fall over.
4. Resolve the serious warnings
Don’t waste hours clearing “line slightly off axis”. Focus on the stuff that behaves like errors:
- constraints not satisfied
- elements missing hosts
- geometry failures
- rooms/spaces not enclosing
- duplicate marks if they affect schedules
If a warning refuses to die, isolate the element(s), clean the view/family, reload, and move on.
Why? Revit regenerates everything during an upgrade. If the model is held together by rubber bands and string, this is where it snaps.
5. Fix the families you already know are cursed
Every project has that one 2015‑era family everyone keeps copying from an old job because “it works”.
Except it doesn’t.
Open those families. Audit them. Clean up sketches, tiny geometry fragments, multiple planes, and any CAD imports someone exploded back when people could still afford to buy houses.
Why? One bad family can block an entire ACC upgrade batch.
6. Compact + Save before the upgrade
Cloud models don’t behave like old server shares, and that’s good. You’re not detaching. You’re not overwriting a central. You’re simply compacting the model, and then letting the cloud upgrade process do it’s thing.
Make sure the production model in ACC stays untouched until the actual upgrade run.
Why? You’re giving ACC the cleanest possible input.
7. Communicate the blast radius
Tell people:
- when the upgrade will run
- that they cannot open the models during that window
- when the new version will be available
- what they must check once the upgrade is done
This isn’t “IT maintenance”. This is a coordinated BIM event. Teams need to know what’s happening so they don’t open the old version halfway through and break things.
Why? Half of all upgrade pain is cultural, not technical.
8. Get everyone out of the model
Once you’ve made all the changes you need to, sync, relinquish, close. Don’t leave ghost sessions open on machines that haven’t rebooted in 19 days.
On ACC, publish before doing anything else. Publishing gives you a clean, time‑stamped RVT snapshot sitting in Docs. You can’t “roll back” an ACC upgrade, but you can always download that published version and re‑initiate it if the upgrade goes sideways.
Why? You want a definitive, closed, conflict‑free state before touching anything.
What Happens Next Isn’t Guesswork
The upgrade isn’t the hard part. The hard part is accepting that an upgrade is basically a health check on every decision the team made since the project started, the shortcuts, the late nights, the “we’ll fix it later” workarounds.
Do this prep and the ACC upgrader is boring. Skip it and you’ll spend the next week digging through logs trying to work out which family finally gave up.
But prep only gets you so far. At some point you need to stop guessing and look at what the model actually says when nobody’s watching. That’s the Test Upgrade Report, the line between “we think it’s fine” and “here’s what’s about to break”.
If you’ve done the work, the report isn’t a horror story. It forms the basis of your plan of attack. And understanding that plan is where we go next.
No Comments