I thought I was done with the ACC model upgrade series. Five posts in, it really felt like I’d covered it all — how the updater works, what breaks, how to check models before upgrading, how to get usable reports out the other side. I’d written about every technical failure point that had ever bitten us, and I was ready to move on.
But I missed one. A big one. Communication.
It didn’t even come from a live project. I’d been mocking up data for a digital twin demo using a copy of a model that sat in a project that had been wrapped up for a while. I left the model in the same ACC project it had originally lived in because the project administrator told me that nobody was working in there anymore and it would be harmless.
Then Friday morning I opened Revit and got: “The model cannot be opened due to internet connection. Please check your internet connection or your firewall settings”
My internet was fine. I tried another machine, and it started opening but failed partway through with a similar message. I clicked through Autodesk’s troubleshooting steps — firewall, DNS, licensing — but none of that applied because I hadn’t changed a thing at my end. I tried a different project and it opened without issue, so the problem was project-specific. I checked the journal and spotted error 409: “mismatch.” I’d never seen that one before.
I downloaded the model from the web interface, opened it locally without a hitch, and figured it was just a cloud gremlin. I re-initiated the model into the same ACC project with a new name and got on with it. I lost two hours chasing ghosts, but from 10am onward I worked solidly, syncing and saving without a drama.
Monday morning, same error. Check your internet connection. Really?
This time when I tried another PC, the project didn’t even show up. I logged into the web interface and checked the project members. I was gone. No longer a member on the project. I was still hub admin so I could poke around. No record of anyone removing me in the log, which was odd. That’s when I saw it:
A model upgrade had been run against the project Friday morning. The log had an entry for an uploaded zip file in the Revit Upgrade Report folder, and the attached report confirmed the entire project had been upgraded from Revit 2025 to Revit 2026 while I was still working in it with Revit 2025.
Oh no.
When I opened Revit 2026, even though I was clearly no longer on the project in the web interface (a strange consequence maybe?) the project was there. I opened it, and I saw the familiar “your central file is being upgraded” notification.
My model went through the upgrade process without issue, opening fine, but when I tried to sync I got a GUID conflict. The version I’d been working on and the newly upgraded project state couldn’t coexist. There’s no clean recovery from that.
And then the real sting. While I was staring at the conflict, I realised that all the syncing I’d done on Friday, the saves in ACC clearly showing at 4:30pm as the last save, had actually saved nothing. A whole day’s work, gone, without a single error message to suggest it wasn’t being kept.
In the end I took a copy of the work I’d done and stood it up in a different project that I had set aside for testing various data management processes. Maybe I should have done that from the beginning, but I’d been told it was safe. What really threw me was the idea that a project everyone considered closed would get upgraded at all, but there was one person working away in there (me). The technical side of the upgrade worked exactly as designed. The problem was the gap between the decision to upgrade and the people who were still inside the project. People who had no idea anything was about to change.
We spend a lot of energy on the technical guardrails: pre-upgrade checklists, test upgrades, structured reports. All of that matters, but it doesn’t help when someone is quietly working away, blissfully unaware, and suddenly models won’t open, access vanishes, and syncs fail for reasons that look like network errors. From the user’s side, nothing has changed. There’s no warning, no heads-up, just a half-day lost trying to debug something that was never on their machine in the first place.
So that’s the part I’d missed. Not a tooling gap, a people gap. The question that has to sit alongside every technical check is simply: who is still in this project, and do they know what we’re about to do?
No Comments