Updating the Revit project

There are many methods and workflows for updating Revit models. The easiest way is to just open the models with the new version of the software and to save them. This may work for smaller projects and smaller organi-sations, but for larger projects we need a more sophisticated way of working. Alternatively, you can use the Revit eTransmit add-on or the built-in functions of Autodesk Construction Cloud (formerly BIM 360), which offer better solutions but are still not perfect. For us, the main goal of a software migration is to avoid data loss and to reduce the resulting risks. Seven years ago, we developed a working methodology on how to achieve the highest possible level of security when mi-grating Revit projects, and since then we have re-thought, fine-tuned, updated, and automated this workflow many times. What is the point of all this?

In our experience, the main points to keep in mind when updating Revit are:

• testing

doing partial or full tests before the update to see as accurately as possible what bugs might occur that need to be addressed. For example, sometimes we see critical bugs in a version that cause it to be skipped completely until they are fixed (e.g., current Revit 2023 version)

• stepping up the versions one by one

if you need to step up multiple versions, do this one version at a time to reduce the number of er-rors (e.g., disintegrating elements, deleted dimensions, damaged models). Sometimes, when you step up several versions at a time, a lot of elements fall apart, while if you step up version by ver-sion, the error does not occur.

• Unloading the Revit Links first

Revit Links need to be unloaded before changing the version. This is necessary because, if the Links are in Open state, the process is slower, because the software updates the version of the linked models together with the given model, but in this case it does not save it, so it does it every time the given model is linked. On the other hand, if we do not unload, we increase the risk of lost Hosts and captions (if the Host of our item or caption is not in our own model but in a Link).

• doing the administration

all problems, error messages, log files that arise need to be administered This is important because after the update, it’s worth reviewing in order to see the differences between the old and the new files and these will help you identify what to check. When Revit detects errors, it will almost always tell us so we can check them to get a good overview of the problems.

• archiving and verifying

You need to archive before and to check after. If critical bugs are found, it is often easier to fix them in the old version and to update again. Sometimes there is an error message in an item that is not critical, but the item falls apart during the update. If you simply accept the message and save it in the element’s Edit mode, the element does not necessarily fall apart (Fun fact: when editing a Family, even if you open the Edit window, accept the error message, and load the Family back into the project, it will not actually be loaded by Revit, because the element is unchanged from Revit’s perspective. If we make a change, it will be overwritten. A simple way to do this is to draw a line, which you can delete later, and to reload the item, which is now detected as a modification by the software.)

• scheduling the transition

other partner companies or subcontractors may also use Revit on a project. In such cases it is prac-tical to exchange data with native files. If we migrate to a newer version and our partner does not, our model cannot be linked for them, and we will have to update their models for each data ex-change. The migration must also be agreed upon with the Client, as it is possible that the version has been fixed in the BEP, in the contract, or that the customer also uses our native files. If we are talking about a large project and a lot of files, this migration can take days for a whole team. During this time, the designers will not be able to work, as the models are linked to each other, and the files can only be used again after a full migration. For these reasons, it is advisable to schedule the transition for the evening, or at the weekend for large projects. This also shows that such a transi-tion involves considerable management work.

• using identical versions

also the exact version number (meaning the sub-version, not only the major version like Revit 2022) should be agreed between the project members. It is advisable to handle this in a uniform way, be-cause even differences between the sub-version numbers can cause file instability, or in the worst case, corruption (it may be enough if we do not have the version difference, but only between users of a linked model). Repairing corrupted models takes a lot of time, it is usually difficult to find out which elements are causing it, so it is advisable to avoid them. In practice, this means that when we switch to a new Revit major version and a new Revit minor version, we check with all our partners, and they switch to it. This actually sets off a chain reaction, because if they are working on another project with this main version, where there is another sub-version, it is advisable for them to nego-tiate the migration of the other project to keep the same version number (or not to switch but to take the risks).

• planning our communication

Typically, it is not enough to notify everyone, it is also worth considering the order in which the consultation takes place. Sometimes, we agreed a date with the co-designers and the Client – who was not using the native model at the time – did not allow it, so the migration could not go ahead. However, it is also possible that a co-designer may be preventing the migration whose workload is very small compared to the overall project, but who may be part of a larger company where version numbers cannot be changed.

Workflow

Our proposed workflow is roughly illustrated in the picture below:

This is an earlier version of our current process, and since then we’ve managed to automate almost the entire workflow. In October 2022. we completed the migration of one of our biggest projects. Some details about the transition:

• 230 native Revit models have been updated
• 100 other, non-native Revit files (typically native files generated from ifc) have been updated
• 8 different companies were affected by the transition
• the transition was preceded by 6 weeks of planning and testing
• 70 man-hours for updating and 30 man-hours for fixing.

Writer: Zsolt Oláh, BIM Studioleader