The Vendor Upload That Shattered the CMMS Hierarchy
Why multi-vendor projects quietly create the biggest data risk in any CMMS implementation
You rarely notice the problem at the start.
You are partway through a CMMS implementation and the consultants have been building your asset structure for months. The design makes sense, the hierarchy looks stable, and the project finally feels like it is moving in the right direction.
Then the vendor data arrives.
One zip file. Several spreadsheets. All using different layouts, different assumptions and different naming conventions.
Inside are thousands of assets, locations, tags and equipment lists collected by separate teams who were never aligned on how your hierarchy should work. None of them were wrong. They were simply working in isolation.
Now all of it needs to be merged into your CMMS build.
This is the point where the hierarchy starts to fall apart.
Why Vendor Data Creates So Many Issues
Vendors deliver the information they were asked for, but they each deliver it in their own format. Across every industry the same patterns keep appearing.
1. Different hierarchy structures
One vendor supplies data using Site > Area > System > Asset. Another uses Location > Sub-location > Equipment. Another just provides a flat asset list.
When these structures are combined in Excel, parent and child relationships clash immediately.
2. Different naming conventions
Common examples include:
- PUMP-001
- P-1
- Pump01
- CentrifugalPump01
These are four interpretations of the same type of equipment. Excel will happily accept them all, but your CMMS cannot.
3. Different ideas about what counts as an asset
Some vendors include instrumentation. Some treat major skids as a single asset. Some break them into dozens of components. Some mix spares and installed equipment in the same list.
No approach is inherently wrong, but they are not compatible.
4. Spreadsheet "cleanup" that removes context
Typical scenarios:
- Columns moved to make the sheet easier to read
- Formulas replaced with hard values
- Filters left active and hiding rows
- Hidden columns containing essential mapping rules
- Tab names renamed without documentation
None of this is intentional damage. It is simply what happens when several people use spreadsheets with no shared structure or version control.
What Happens When This Data Is Loaded into Your CMMS Build
When the consultant receives conflicting vendor files, they must choose how to interpret them. They are forced to decide the following without clear rules:
- Which hierarchy shape is the correct one
- How to resolve different parent codes for the same asset
- Which vendor's description or naming format should be used
- Whether duplicate assets are truly duplicates
- How to handle assets that appear in multiple versions with small differences
Even very experienced teams end up creating:
- orphaned assets
- duplicated equipment
- invalid parent or child relationships
- PMs pointing to the wrong assets
- mismatched functional locations
- inconsistent naming
- unreliable classifications
These problems rarely appear immediately. They show up during UAT or after go-live, when the cost and difficulty of fixing everything increases sharply.
The Core Problem: No Shared Validation Rules
Each vendor is working with their own assumptions. Your CMMS requires one set of assumptions. Excel does not enforce either.
There is no shared model, no standard dictionary, no relationship engine, no required values, no change tracking and no reliable history of who changed what.
When everything lands in a master workbook, the consultant is left interpreting intent instead of applying rules.
That is not a reliable data process. It is guesswork.
What Good Looks Like
A controlled CMMS data process should allow you to:
- load vendor data into a single structured environment
- validate it against your hierarchy rules
- identify broken parent-child relationships immediately
- enforce approved naming conventions
- flag conflicting assets across sources
- keep a full history of changes
- produce transparent validation reports
- prevent invalid imports
Vendors should not be deciding hierarchy structure or naming logic. They should be supplying raw data that is validated against your defined standards.
When this happens, inconsistencies become visible early and can be resolved long before any migration scripts are built.
The Uncomfortable Truth
Vendor data is not a problem because vendors do poor work. They do what they were asked to do using the tools they were given.
It becomes a problem because every vendor follows their own internal standards and your CMMS can only support one.
A CMMS is a unified hierarchy, not a set of separate spreadsheets. If you are merging vendor files manually in Excel, you are accepting a level of risk that becomes visible only after import.
Many teams do not realise this until late in the project.
If You Want to Reduce That Risk
Before your next vendor upload, make sure you can answer:
- What hierarchy rules are we enforcing
- How we will validate naming conventions
- How we will detect duplicate assets
- How we will confirm parent locations actually exist
- How we will track changes between versions
- What happens when two vendors define the same asset differently
If the answer relies on Excel, you are already working at the edge of what spreadsheets can reliably support.
AssetStage provides hierarchy validation, naming enforcement and controlled staging for multi-vendor data long before it reaches your CMMS. Request a demo to see how it works.