Collaboration
Working with consultants on different Revit versions
The architect upgrades, the structural engineer has not, and suddenly nobody can open anybody's links. How to agree a project version, and what to do when one party moves ahead of the rest.
A Revit version mismatch between consultants is one of the most common reasons a coordinated project stalls. Revit opens files from older releases but never from newer ones, so the moment one team upgrades, everyone still on the old release loses access to that team's models.
Why do Revit version mismatches happen on projects?
Autodesk releases a new version of Revit every year, and each practice decides for itself when to move. A Revit subscription includes the current release plus three previous versions, so on any one project the architect, engineers, specialist subcontractors and client can easily be spread across four releases.
Nothing breaks while everyone stays put. The trouble starts when one party upgrades a project model and issues it, because that model can no longer be opened or linked by anyone on an earlier release.
How do you agree a Revit version for a project?
Decide it at the start and write it down, in the appointment, the project brief or the BIM execution plan. Autodesk's own guidance for upgrades is to upgrade all models associated with a project at the same time and to coordinate with the whole extended team, which only works if the version is a shared decision. These are the points worth agreeing:
| Decision | Why it matters |
|---|---|
| The project release | Every model on the project is issued in this release, so every party can open every model. |
| When upgrades may happen | Upgrading at a stage boundary, by agreement, avoids one team moving mid-stage and stranding the others. |
| Who confirms the upgrade | One named person, usually the lead designer or information manager, so nobody upgrades on their own. |
| Release for families and templates | Shared content in the project release, or older, loads for everyone. |
| Release for handover | Some clients need models in a specific release for their own teams or facilities managers. |
What happens when you link a model from another release?
It depends which way the difference runs.
- An older link in a newer host loads, but Revit upgrades it in memory every time the host opens. Autodesk notes that these upgrades are temporary and are not saved with the host, so opening gets slower with every un-upgraded link. Only the owner of the linked model can upgrade it permanently, by opening, upgrading and saving it.
- A newer link in an older host does not load at all. The link fails for the same reason the file will not open on its own.
So a team that stays one release behind can still use your links if you work in their release, but not the other way round.
Common scenarios, and what to do
You are the architect on Revit 2024 and the structural engineer issues a Revit 2026 model.
Ask the engineer to re-issue in the agreed release. If that is not possible in time, convert their model to Revit 2023, open it in your Revit 2024, save it, and link that copy. Record in your issue register that the link is a converted copy of their issue, so you replace it when they re-issue properly.
The client requires models in Revit 2023 at handover, but the team works in Revit 2026.
Plan the handover from the start. Keep working in your release, then convert the final models to Revit 2023 at handover and check them in Revit 2023 before you issue them.
A specialist subcontractor joins mid-project on an older release.
If they only need to review, the free Autodesk Viewer or Navisworks is enough. If they need to model, issue converted copies in Revit 2023, or agree that they move to the project release.
Someone in your own office upgrades the central model by accident.
Stop work on it, restore the central model from the backup taken before the upgrade, and remind the team that double-clicking a file opens it in the newest installed release. Our Revit version compatibility guide covers workshared upgrades step by step.
How do you share models across versions safely?
- Send copies, never the live central model. Issue a detached copy so nobody outside the team synchronises against your central file.
- Name the release in the file. A suffix such as
_R2023on every issued model, and a column in the transmittal, stops guesswork. - Check before you link. Revit's Open dialog shows the release that saved a file when you select it. Our guide to checking a file's Revit version lists other ways, and the free version checker lists the release of every file in an issued folder at once.
- Keep the original. Before upgrading or converting anything, archive the file as issued.
- Upgrade links before hosts. When the whole project does move release, Autodesk recommends upgrading linked models before the central model.
Frequently asked questions
Can I link a Revit 2025 model into a Revit 2024 project?
No. A model from a newer release cannot be loaded into an older host. You need a copy in Revit 2024 or earlier, or a conversion to Revit 2023.
Should everyone upgrade to the newest Revit straight away?
Not mid-project unless everyone agrees. Upgrading at a stage boundary, together, is far less disruptive than one party moving ahead.
Which Revit version should a project use?
The release every party can run. In practice that is usually the oldest release anyone on the team is licensed for, because a file saved there opens for everyone else.
Key takeaways
- Agree the project Revit release in writing at the start, with a named person who controls upgrades.
- Older links load in newer hosts with a temporary upgrade; newer links never load in older hosts.
- Upgrade the whole project together, at a stage boundary, links first.
- When one party moves ahead, ask for a re-issue or convert their model to Revit 2023.