# Moving a device makes its identity confusing

> Keep the asset's identity traceable while its rack position, hostname, or service assignment changes.

Canonical page: https://datacenterlabeling.com/problems/asset-versus-location

Source review: 2026-09-12. This is a source-review date, not a claim of standards certification.

Rackstamp provides editorial field guidance. IDs, cases, and worksheet entries are fictional examples unless identified otherwise. Distinguish local conventions from adopted standards. Source notes describe the evidence scope; a linked overview is not the full standard or a project approval.

## The practical answer

Keep an asset's identity distinct from its current location and service name. During a move, retain the asset ID unless the governing policy requires otherwise, update the location relationship, and preserve aliases needed to interpret older records. A replaced physical device and a relocated device are different events and need different identity decisions.

## When to use

Use this guide during move closeout or when a label describes an old location. Build a crosswalk connecting the physical asset, its aliases, and its location history.

NetBox provides separate fields for manufacturer serial number, asset tag, name, site, rack, face, and position. Those separate fields support distinguishing identity from location; the retention and history rules below are a proposed local policy. [NetBox device model](https://netbox.readthedocs.io/en/stable/models/dcim/device/)

## What to gather

Collect the visible asset label, manufacturer serial, current inventory record, approved move record, old and new location references, and hostname or service aliases.

## Method

1. Find the record using the physical asset identifier and a second distinguishing reference, such as the serial number. Record disagreements without choosing a match by hostname alone.
2. Separate durable identity fields from attributes expected to change. State which identifier your policy retains through a move, and who may authorize an identity correction.
3. Enter the previous and intended locations in distinct fields. Record rack, face, and U convention consistently; keep a planned destination separate from an observed current location.
4. Reconcile the move's completed state with the permitted field observation. Update the current-location record only when the move evidence supports it, retaining the previous reference in history.
5. Review work orders, monitoring aliases, and connection records that reference the old location. Close the crosswalk with the effective date, evidence, owner, and any unresolved alias.

## Decide whether the object moved, changed, or was replaced

Start with the physical identity question. A hostname at a new rack position can represent a moved device, a replacement device using an old name, or an inaccurate location record. Compare the visible asset tag with another approved distinguishing reference and the relevant change history. Do not treat a familiar hostname as proof that the hardware is the same.

If the physical identity is unchanged and the move evidence supports a new location, retain the identifier according to local policy and update the location relationship. If the physical device was replaced, record the old and new asset identities separately even when service and hostname remain the same. If the evidence is incomplete, keep the current-location question unresolved rather than manufacturing a completed move.

Distinguish an alias change from an identity change. A system name, customer description, or service role may change while the physical asset remains the same. Record who owns each alias and when it became effective. An alias can help people find the object, but it should not silently take over the role of the retained physical identifier.

When the old label includes location text, identify which parts of the label actually changed. A durable asset-ID line may remain correct while a separate location line becomes stale. Prepare the correction from the approved field meanings instead of issuing a new asset merely because some printed text needs updating.

## Build a before, planned, and observed record

Record the previous location, planned destination, and observed current location as distinct facts. The previous location describes an established earlier state. The planned destination comes from the approved work package. The current location needs completed-event evidence or an appropriate permitted observation. Keeping these fields separate prevents a scheduled move from appearing finished before it occurs.

Include full site, hall, rack, face, and position context where the local model uses them. Preserve the position convention so a move between two systems does not also introduce a top-versus-bottom U mismatch. For a multi-unit asset, retain the relevant footprint evidence rather than reducing it to an unexplained single number.

If the asset is in a controlled staging state between locations, use the site's actual supported status and location representation. Do not leave the planned rack marked current simply because the register lacks a convenient transit field. Record the limitation and ask the asset owner how the interim state should be represented.

Write down the event that makes the destination current. A completion record, receiving observation, or other approved evidence may establish that event under local policy. Preserve its date separately from the date someone later reconciled the database. Those dates answer different questions and should not be copied into each other's fields without explanation.

## Keep identity fields and aliases in a usable crosswalk

List the identifiers by type: retained asset ID, manufacturer serial, hostname, customer tag, or other approved reference. Preserve the exact strings and their status. A historical alias should be visibly historical, especially if the same hostname can be reassigned to another device.

Connect each active alias to the current physical identity through its responsible owner. The monitoring team may own the operational name while the asset steward owns location and lifecycle history. A move review should record both outcomes instead of assuming that an update in one system changes the other.

When a hostname is reused, create an event boundary in the history. A lookup for an old incident should resolve to the asset that used the name at that time, while a current lookup should identify the present asset. The precise representation depends on the system, but the evidence must not imply that both devices simultaneously own one current physical identity.

If one system has only a single name field, document the agreed meaning and link the richer crosswalk where appropriate. Do not concatenate unrelated values into an improvised identity that nobody can maintain. Escalate an actual field limitation to the record owner and state how users should resolve the object during the transition.

## Follow the move through dependent records

Identify records that use the old location as a way to select equipment. Typical candidates in this workflow include open work orders, rack elevations, connection schedules, inventory exports, and operational aliases. Review the actual dependencies for the work package rather than copying a generic list and assuming it is complete.

For each dependency, record whether it follows the durable asset identity automatically, requires an owner update, remains valid as historical evidence, or is unresolved. A connection schedule may need new equipment-location context even when the cable's own identity has not changed. A historical maintenance record should normally remain attached to the asset event it describes.

Separate completed changes from requests sent to other teams. If the monitoring owner has not confirmed an alias update, record it as pending with the relevant change reference. The asset steward can close the physical-location verification while still exposing that unresolved operational dependency.

Review any exported or printed material still being used in the work area. If it shows an old location, determine whether it should be superseded, annotated under the local process, or retained solely as history. An accurate central record does not make a stale active work pack harmless.

## Scenario: a moved device also receives a new hostname

In a separate fictional case, asset AST-G05-301 with serial DEMO-G05-S301 moves from DC01/H1/R301/front/U08 to DC01/H1/R302/front/U20. The approved change MOV-G05-301 also replaces the operational alias compute-g05-old with compute-g05-new. The installation record is marked complete, but a field lookup by the old hostname still shows the previous rack.

The reviewer confirms the physical asset and serial at the destination through permitted evidence. The diagnosis is a completed move with an unreconciled alias and location dependency, not a second device. The crosswalk retains AST-G05-301 and records the earlier location as history, the verified destination as current, and the completed move event as the effective boundary.

The asset steward updates the current-location record. The monitoring owner confirms the new alias and identifies the old alias as historical under the same change. The rack-elevation owner closes the departure and arrival references so the asset does not appear actively installed in both places. Each team supplies its own completion evidence.

A second reviewer searches by the retained asset ID and both alias contexts. The current lookup identifies the destination, while the historical alias remains tied to the prior event without creating another active asset. The old rack's next occupant receives its own identity. Closure retains the serial comparison, departure and arrival evidence, effective event, and any remaining external-system exception.

## Handle replacement and partial moves without losing history

A replacement can occupy the same position and inherit the same service name while remaining a different physical asset. Record a retirement or removal event for the former object and a separate introduction event for the replacement under local policy. Link the service continuity if needed, but do not transfer the old physical asset tag simply to make the service history appear uninterrupted.

For a partial move, state exactly what was completed. The asset may have left the old rack but not reached its released destination, or the physical relocation may be complete while related record updates are pending. Use distinct evidence and statuses for those facts. A single broad “done” field can conceal which reference remains unreliable.

If the move was canceled, retain the cancellation event and restore or confirm the correct current state through evidence. Do not delete the planned destination without keeping the reason it never became current. Someone investigating a printed work order later should be able to understand why it names a location the asset never occupied.

For equipment with separately managed components, confirm which identities move together and which records remain independent. The owner should define the relevant asset model. This guide does not assume that a chassis, module, and service name always represent one indivisible inventory object.

## Work with incomplete legacy evidence

In an older facility, the asset label or manufacturer reference may be damaged, missing, or inconsistent with the database. Record the limitation explicitly and seek other approved identifying evidence through the asset owner. Do not create a plausible serial or select a neighboring record because its hostname resembles the label.

Preserve an unresolved identity separate from an unresolved location. You may know where a device sits but not which historical asset record it belongs to. Conversely, a receiving record may establish the asset identity while its current physical location still requires a permitted check. Those cases need different follow-up work.

When historical aliases have been reused repeatedly, work from dated events and original records where available. Avoid applying today's alias mapping backward to every historical incident. Record the boundary of what can actually be established; an honest incomplete history is more useful than a tidy crosswalk built from assumptions.

In a new deployment, define the retained asset identifier and the move-event fields before the first relocation. Include that model in handoff so operations can distinguish a planned destination, completed move, replacement, and alias change without inventing new rules each time.

## Review the completed history from both directions

Give the reviewer the physical asset ID and ask them to find its current location and previous move reference. Then give them the old location or alias and ask which asset occupied that context at the relevant event. Both directions should be understandable from the retained records.

Check that the effective date describes the established event and the verification date describes the actual review. Confirm that the current-location entry is singular where the local asset model expects one active installation, and that past locations remain clearly historical.

Keep any unresolved dependency attached to its owner and change reference. Closeout should show what is known now, how it became current, and which historical references remain useful. It should not erase the path that explains why an old sticker or work order says something different.

## Worked example

Fictional asset AST-008421 retains its local asset identity through a recorded move.

```text
Identity: AST-008421 / serial DEMO-SN-8421
Before:   DC01/H1/R006/front/U18
After:    DC01/H1/R014/front/U23
Alias:    compute-17
Change:   DEMO-MOVE-005
History links both locations to the same physical asset.
```

A different device occupying the old position keeps its own identity; location reuse does not transfer this asset ID.

## Common mistakes

- Creating a new asset merely because its rack changed.
- Using a reused hostname as the only physical identity evidence.
- Overwriting the old location without keeping the move reference.

## Verification

- [ ] The asset and serial references identify the same device.
- [ ] Planned and observed locations are distinguished.
- [ ] The retained identifier follows the local policy.
- [ ] Old-location dependencies have an outcome.
- [ ] Effective date and evidence support the completed record.

## Worksheet: Asset-to-location crosswalk

Fields define one row; sample values are fictional. Leave working-sheet dates blank until their recorded event occurs. Sample status: **Example only**.

| Field | Definition | Filled example |
| --- | --- | --- |
| Asset ID | Durable identity under the local policy. | AST-008421 |
| Serial | Manufacturer identifier observed on the asset. | DEMO-SN-8421 |
| Hostname | Current operational name or alias. | compute-17 |
| Previous location | Location before the recorded move. | DC01/H1/R006/front/U18 |
| Current location | Observed location after the move. | DC01/H1/R014/front/U23 |
| Effective date | Date the new location became current. | 2026-09-11 |
| Change reference | Record authorizing and documenting the move. | DEMO-MOVE-005 |
| Owner | Role responsible for the asset record. | Compute asset steward |
| Evidence | Observations supporting identity and location. | DEMO-MOVE-PROOF-005 |
| Verifier | Person checking the crosswalk. | Example reviewer |
| Verification date | Date identity and location were reconciled. | 2026-09-12 |
| Status | Review state. | Example only |

## Frequently asked questions

### What if the manufacturer's serial label is unreadable?
Record that limitation and use other approved identifying evidence. Do not manufacture a serial number to complete the row.

### Should an asset label include a hostname?
It may show a useful alias if your policy allows it, but distinguish that alias from the retained physical asset identifier.

### Does a replacement device inherit the previous asset ID?
Follow the local asset policy, but do not assume that service continuity means physical identity continuity. Establish whether the policy treats the replacement as a new asset and record the old and new physical references accordingly. Keep any shared hostname as an alias relationship.

### Which date should become the effective date?
Use the event evidence accepted by the asset owner for the completed location change. Keep a scheduled date and the later reconciliation date separate. If the completion time is uncertain, record that uncertainty instead of choosing a convenient date.

### Can we close the move before every external system is updated?
Record the verified physical outcome and each pending dependency separately. Whether the overall change may close is the responsible owner's decision under the site's process. The worksheet should make the remaining alias, elevation, or work-order issue visible rather than implying it has been completed.

## More worked label examples

### Move an asset while retaining its durable identity

The asset label remains stable while a separate location line and the current-location record change together.

```text
SCOPE: DC01 / H1; move record MOV-G05-101
BEFORE LABEL FACE             AFTER LABEL FACE
+------------------------+  +------------------------+
| AST-G05-101            |  | AST-G05-101            |
| LOC R101 / U08-U09     |  | LOC R102 / U20-U21     |
+------------------------+  +------------------------+

ASSET RECORD
Serial: DEMO-G05-S101             unchanged
Previous location: DC01-H1-R101 / FRONT / U08-U09
Current location:  DC01-H1-R102 / FRONT / U20-U21
Effective event: recorded completion of MOV-G05-101
Evidence: EV-G05-101 departure; EV-G05-102 arrival
History retains both locations and the approved change
```

- If your asset sticker contains only the durable ID, retain it and update the separate rack-position label or record. Replace only the information that actually changed.
- Use the verified move completion as the effective event; a scheduled move date is not evidence that the destination is now current. Keep an explicit in-progress state if the move is unfinished.

### Change the hostname without losing the asset crosswalk

The equipment ID anchors the relationship when both location and the name used by an application team change.

```text
SCOPE: DC01 / H1; change MOV-G05-201
PHYSICAL ASSET FACE
+----------------------+
| AST-G05-201          |
| SERIAL DEMO-G05-S201 |
+----------------------+

FIELD          BEFORE                 VERIFIED AFTER
Asset ID       AST-G05-201            AST-G05-201
Hostname       gpu-old-g05            gpu-new-g05
Location       R201 / U04             R202 / U16
Role           Test worker            Batch worker

AST-G05-201 -> current hostname gpu-new-g05
gpu-old-g05 -> historical alias under MOV-G05-201
Old location -> history; not a second active installation
```

- Determine which team owns hostname changes and which owns asset location. Record both approvals or evidence references instead of assuming that one system updates the other.
- Retain historical aliases only in fields that clearly indicate their status. If the former hostname is reassigned, identify its new asset independently so searches cannot silently resolve to the moved device.

## Sources and applicability

- [NetBox: Device model](https://netbox.readthedocs.io/en/stable/models/dcim/device/): Separate identity and location fields; asset retention across moves is an explicit editorial policy example. The expanded triage, decision comparisons, scenarios, and closeout procedures are original editorial guidance.

## Related guidance

- https://datacenterlabeling.com/problems/naming-convention
- https://datacenterlabeling.com/problems/label-record-reconciliation
- https://datacenterlabeling.com/problems/moves-and-retirement-closeout