The harder question: does the model still have a purpose after handover?

There is another side to the digital model conversation that I think needs to be said more clearly.

Do we actually need to keep the full authoring model alive after delivery?

Or do we only need part of it?

In many cases, owners already have systems that manage asset information. They may have a CMMS, an asset database, a GIS platform, a document management system, a space management system, a portfolio database, or a combination of all of them. These systems already manage a lot of the information that people often assume the model should manage.

So the question becomes:

What does the model provide that the database does not?

If the answer is only “data,” then the model may not be the right long-term system. Databases are already better suited for structured records, querying, reporting, asset tracking, maintenance history, replacement planning, and portfolio analytics.

A model is not automatically a better database.

That is where I think we need to be careful.

If the purpose is asset management, maybe the CMMS or asset database should remain the source of truth. If the purpose is location intelligence across a campus, city, base, airport, hospital network, or portfolio, maybe GIS is the better environment. If the purpose is document control, the CDE or document management system may be the better place. If the purpose is operations, then the operational platform may need the data, not necessarily the full authoring model.

So why keep the model?

From my perspective, the strongest reason is not simply data storage. The strongest reason is spatial context.

Geometry gives information a place.

It helps people see where an asset is, what it connects to, what is around it, what floor or room it belongs to, how systems relate, and how a physical space may be affected by change. That can be valuable for operations, maintenance, planning, emergency response, renovations, and capital renewal.

But that does not mean the full model must remain alive forever.

Sometimes, the most practical strategy may be to use a simplified geometry layer or shell model. That geometry could support visualization, location context, and navigation, while the actual asset data remains in databases designed for long-term management.

In that case, the model becomes a spatial interface, not the master database.

That is an important distinction.

A GIS platform may be able to manage the broader ecosystem better than the authoring model. GIS can connect buildings, sites, infrastructure, utilities, parcels, addresses, exterior assets, underground networks, campuses, and regional context. For large owners, this may be more useful than trying to keep every building model alive inside its original authoring application.

But GIS also has its own burden.

It needs governance.
It needs data maintenance.
It needs schema control.
It needs integrations.
It needs staff knowledge.
It needs update workflows.
It needs quality checks.
It needs long-term support.

If the GIS ecosystem depends heavily on open-source tools, custom integrations, scripts, viewers, or non-standard workflows, then the cost does not disappear. It moves into technical maintenance. Open source can be powerful, but it still needs ownership, support, documentation, security review, version control, and people who know how to maintain the stack.

So again, the question is not only:

Can we do it?

The better question is:

Who will maintain it, and why?

This is where many model handover conversations become unclear. Some people imagine the model going into a digital twin platform. Some imagine it going into GIS. Some imagine it feeding a database. Some imagine the authoring model staying alive for future renovations. Some imagine a viewer connected to sensor data. Some imagine open-source tools managing everything.

All of those may be valid in the right context.

But they are not the same strategy.

A model loaded into a digital twin platform may support visualization and live data.
A model simplified into GIS may support location and portfolio context.
A database may support asset records and reporting.
A CMMS may support maintenance work orders.
A native authoring model may support future design changes.
An open-source ecosystem may support custom workflows if the organization can maintain it.

The problem starts when we pretend one environment can solve every information need.

Maybe the model does not need to stay alive as a full authoring file. Maybe what needs to survive is the useful geometry, the asset identity, the spatial relationships, and the links to maintained databases.

That means the model may become a source, not the source of truth.

For some owners, that may be the right answer.

The full authoring model may be archived.
A simplified model may support visualization.
GIS may manage the campus or portfolio context.
The CMMS may manage maintenance.
The asset database may manage equipment records.
The document system may manage drawings and manuals.
The digital twin platform may connect selected assets to live data.

That is an ecosystem.

But an ecosystem still needs rules.

Which system owns the asset ID?
Which system owns the location?
Which system owns geometry?
Which system owns maintenance history?
Which system owns sensor mappings?
Which system owns renovation updates?
Which system is trusted when records disagree?

Without those answers, the organization does not have a digital twin. It has disconnected systems with a model viewer attached.

From my experience, this is where the conversation needs to mature.

There is a cost side to this that often gets missed.

If the authored model is not used, updated, or maintained for future work, then much of the money spent developing rich model information dies with the file. It may still have served the construction phase, and that has value. But beyond construction, the long-term value becomes limited if the model becomes only a snapshot in time.

That snapshot may show what was intended, coordinated, or delivered at one point in the project. But buildings change. Equipment changes. Spaces change. Systems change. Software changes. Once the model is no longer maintained, the confidence in that model starts to decay.

After enough time, the issue is not only whether the model is accurate. The issue is whether it can even be used efficiently again.

If the authoring software has moved forward several releases, and the file has not been opened, upgraded, checked, repaired, or validated, the model becomes harder to trust and harder to reuse. After five software versions, the model may still open, but opening is not the same as usefulness. The upgrade may break workflows, expose warnings, change behaviours, disconnect links, affect add-ins, or leave the receiving team with a file they can view but not confidently manage.

At that point, the investment has changed form.

The project paid to create a rich digital model.
The team paid to coordinate it.
The owner may have paid to receive it.
But if no one maintains it, the value starts to expire.

That does not mean the original work had no value. It supported design and construction. It may have reduced coordination issues, improved documentation, and created a better record of the project. But if the expectation was long-term reuse, then the model needs a maintenance strategy. Without that strategy, the model becomes a frozen deliverable, not a living asset.

The cost of creating the information was real.

The cost of not maintaining it is also real.

That cost appears later as rework, re-surveying, re-modelling, file upgrades, lost trust, manual verification, disconnected databases, and future teams having to rebuild what was already paid for once.

If the model is expected to support renovation, additions, or system integration, the question becomes more technical.

Do we only need geometry, or do we also need the authoring system intelligence behind that geometry?

For simple visualization, shell geometry may be enough. A simplified model can show floors, rooms, walls, major equipment, and general location. That may support navigation, communication, and high-level planning.

But renovation and system integration often require more than a visual shell.

If a team needs to modify systems, extend pathways, connect new equipment, check clearances, validate distances, maintain slopes, coordinate routing, or understand existing relationships, then the native authoring model may provide information that a simple geometry export does not. Parameters, constraints, system connectors, levels, hosted relationships, reference planes, family behaviour, worksets, and model organization can all affect whether the model can be edited with confidence.

Distance is a good example.

A viewer may show that equipment is near a wall. A database may say the equipment belongs to a room. But the authoring environment may provide the editable geometry, dimensions, constraints, hosted relationships, and system logic needed to understand whether a new connection, clearance, route, or renovation option can actually work.

So the question should not be:

Do we have the model?

The better question is:

What kind of future work is the model expected to support?

If the future use is visualization, simplified geometry may be enough.
If the future use is asset lookup, the database may be enough.
If the future use is GIS context, the spatial layer may be enough.
If the future use is renovation, addition, or system integration, the editable authoring model may still matter.
If the future use requires distances, clearances, connectors, slopes, routing, hosting, or system logic, then the model needs more than static geometry.

That does not mean every native model must be maintained forever. But it does mean the decision should be intentional. If the authoring model is allowed to die, the organization should understand what future capability may be lost with it.

There is another option.

The model does not have to die if the owner decides it is no longer just a project deliverable. It can become a living owner-controlled model.

In that approach, the model is not handed over once and forgotten. It is placed under the owner’s information environment, usually through the owner’s CDE, model management platform, or controlled data environment. When future renovation, addition, system integration, maintenance, or verification work is needed, the consultant does not start from an old archived copy. They are given controlled access to the current owner-held model.

That changes the model from a project file into a maintained asset.

Instead of this:

Project team creates model.
Model is handed over.
Owner stores model.
Future consultant receives old model.
Future consultant updates separate copy.
Information fragments over time.

The better approach may be this:

Project team creates model.
Owner accepts model into a controlled environment.
Model becomes the maintained record.
Future consultants access the current model.
Updates are made against the owner’s source model.
Changes are reviewed, accepted, and recorded.
The model continues forward.

In that case, the model does not die. It is handed forward.

But this only works if the owner is prepared to manage it.

A living model needs governance.
It needs access control.
It needs version control.
It needs model stewardship.
It needs clear edit permissions.
It needs a process for accepting changes.
It needs defined responsibility after each project.
It needs a budget for upkeep.
It needs rules for when geometry is updated.
It needs rules for when data is updated.
It needs rules for when the model becomes the source of truth and when another system does.

There is also a liability side, but I see that as part of the governance conversation. ISO 19650 can help frame information responsibilities and exchange processes, but reliance, permitted use, future edits, and professional responsibility still need to be defined through appointments, contracts, protocols, and owner rules.

Otherwise, a living model can become a living liability problem.

This is different from traditional handover.

Traditional handover often treats the model as a final deliverable. A living model treats the model as an owner-controlled information asset. The consultant may still create, update, or modify the model, but the owner controls the environment, the current record, the access rights, and the acceptance process.

That may be the better future state for some owners.

Instead of asking every new project team to rebuild, reinterpret, re-survey, or revalidate old information, the owner maintains a continuous model environment. Consultants work from the current model, make approved updates, and return the model back into the controlled record.

This could reduce waste.

It could reduce duplicated modelling.
It could reduce disconnected project files.
It could reduce repeated surveys.
It could reduce confusion around old versions.
It could give future teams a better starting point.
It could preserve more of the money already spent creating the model.

But it also changes the responsibility model.

If the owner wants a living model, then the owner needs to act like the model has operational value. It cannot be treated as an unmanaged file. It needs a steward, a process, and a reason to stay current.

The living model approach also needs boundaries.

Not every wall, pipe, fitting, chair, annotation, view, or temporary project object may need to be maintained forever. The owner still needs to define what parts of the model remain live. For example, the owner may maintain the building shell, rooms, levels, grids, major equipment, primary systems, critical pathways, and high-value assets, while allowing low-value or project-specific modelling content to remain archived.

That is where the strategy matters.

A living model does not mean everything lives forever.

It means the useful parts of the model are deliberately maintained because they support future work.

The goal should not be to keep every model alive forever just because it was delivered. The goal should be to decide what part of the model has continuing value.

Maybe the shell geometry is enough.
Maybe the room and floor structure is enough.
Maybe only major maintainable assets matter.
Maybe only future renovation areas need model upkeep.
Maybe GIS is the right long-term environment.
Maybe the authoring model should be maintained only for high-value facilities.
Maybe the database is the real operational system, and the model is only a visual layer.

Those are valid decisions if they are intentional.

The risk is making no decision at all.

That is when the model dies slowly.
That is when the database drifts away from the building.
That is when GIS becomes disconnected from the asset records.
That is when sensor data is mapped to outdated equipment.
That is when the digital twin becomes a dashboard without trusted information behind it.

So maybe the real question is not:

Should the model live forever?

Maybe the better question is:

Which part of the model is worth keeping alive, and which system is responsible for it?

If the answer is geometry, then maintain the geometry.
If the answer is asset data, then govern the database.
If the answer is location, then connect it to GIS.
If the answer is maintenance, then align it with the CMMS.
If the answer is operations, then define the operational use case.
If the answer is future renovation, then keep the authoring model current.

But if there is no use case, no owner, no budget, and no process, then maybe the model should be treated honestly as an archive.

A model does not stay useful because it was delivered.

It stays useful because someone gives it a job after delivery.

Steven Spry
BIM Specialist | Founder, BIMxcel Inc.

AI-assisted editing was used. The ideas, final content, and responsibility are my own..