Building an Asset Register From What You Already Have

Utility staff often describe their asset records the same way: some of it is in GIS, some of it is in a spreadsheet someone built years ago, some of it lives in paper inspection binders, and some of it exists only because a long-tenured operator remembers where the old cast-iron section is. That's not a broken starting point. It's the normal one.

Why "we don't have an asset register" is usually wrong

Most utilities in this situation already have most of the raw material a register needs. What they're missing isn't the data, it's a structure that pulls the data together into one place with a consistent identity for each asset. The GIS layer knows where the valve is. The maintenance log knows it's been repaired twice. The engineering as-built knows what year it was installed. None of those sources knows about the other two, and that disconnect, not a lack of data, is usually the actual problem.

What a usable asset register needs, at minimum

A register doesn't need to be exhaustive to be useful. At minimum, it needs to give every asset a stable, unique identifier, and attach a consistent set of attributes to that identifier:

A unique ID that doesn't change even if the asset is relocated in GIS, renamed by a new operator, or referenced differently across departments.
Location, tied to your GIS if you have one, or at minimum a consistent address or reference point if you don't.
Asset type and basic specifications, material, size, and manufacturer where relevant, at the level of detail you can realistically maintain.
Install date or estimated age, even when the real answer is "installed sometime in the 1970s based on the neighborhood's development history." An estimate that's labeled as an estimate is far more useful than a blank field.
Condition, however approximate. A three-tier scale (good, fair, poor) applied consistently is more useful than a detailed scale applied to only 10% of your assets.
A link back to history, repairs, inspections, and any capital work performed, even if that history currently lives in a separate system.

Starting from what you already have

The practical path is almost never "start from scratch." It's usually: pick one asset class to start with (hydrants and water mains are common first choices because break and inspection history already exists for them), pull together every source that has information about that asset class, and reconcile them into one structure with the attributes above. Duplicate or conflicting records get resolved as you go, not before you start, waiting for perfect reconciliation before beginning is one of the most common ways an asset register project stalls before it produces anything usable.

Where GIS fits, and where it doesn't have to

A map-based GIS layer is a natural home for an asset register because location is one of the most useful ways to organize infrastructure data, and because it lets field crews, engineers, and finance staff all look at the same information from their own angle. But GIS is not a requirement to start. A well-structured spreadsheet with consistent unique IDs can serve as a real asset register while a GIS layer catches up, and migrating a clean spreadsheet into GIS later is far easier than trying to clean up GIS data that was never structured consistently in the first place.

Keeping it current