Published 2026-10-23 · LuckyMDM Blog
The short answer: a device carries a name, an asset tag and a serial number, and those three fields have three different lifetimes. The name is descriptive and gets rewritten on every transfer. The asset tag is administrative and gets rewritten whenever a label is reprinted. The serial number is fixed at manufacture and cannot be edited from the fleet side. Any join between two systems, two exports or two stock counts therefore has exactly one defensible key, and it is the serial number.
The device name ships as the model name, and it is edited either on the device itself or by a settings command from the console. Both paths write the same field, and the device then displays the new value.
The name describes a situation: which site, which batch, which person. Because it describes a situation, it changes when the situation changes. A field that is guaranteed to be edited at some point cannot serve as a primary key.
The asset tag is invented by the organisation, typically a site code plus a year plus a running number, printed on a label stuck to the chassis.
Its value is procedural: repair tickets quote it, stock sheets quote it, internal transfer forms quote it. A label can fall off and be reprinted, and a reprint can duplicate a number, at which point two devices share one tag. A bulk import with a shifted column can offset a whole batch by one row.
So the uniqueness of an asset tag is maintained by process, not guaranteed by construction.
The serial number is written into the hardware at manufacture. The fleet side cannot edit or delete it, and it does not change when a device is renamed.
This is why it works as a join key: it is the only identifier whose value is unaffected by anything the operator does.
| Identifier | Created by | Editable | Source of uniqueness | Typical use |
|---|---|---|---|---|
| Device name | factory default, editable | yes, on device or from console | none, duplicates allowed | identifying a unit on site |
| Asset tag | the organisation | yes, a reprint changes it | maintained by process | repairs, stock counts, transfers |
| Serial number | fixed at manufacture | no | unique at hardware level | system joins, record linkage, release records |
| Device identifier | assigned by the system | no | unique at device level | command dispatch, receipt ownership |
For a device fleet platform such as LuckyMDM, the choice of join key is not a database preference. It follows from one question: which of these fields can the operator not edit? Only that field can carry a join across two systems that are maintained by different teams.
A rename is a single field update on the server, not a rebuild of the device record.
That means the device record still exists, its profiles, command history and receipts are still attached, and nothing inside the management system breaks. What breaks is every match built elsewhere on the old name.
This is where the damage happens. The management system updates one column in its own database. The same name, however, is also stored in at least three other places: a stock-count sheet, a repair ticketing table, a site inspection list.
Each of those is a snapshot taken at export time. They copied the name once and stopped following it. The underlying reason is that a snapshot holds a value rather than a reference: it depends on what the name was when the export ran, not on any link back to the record. So nothing the console does propagates to them.
The shared difficulty is that all three produce blanks rather than errors. A blank is harder to find than an error, because nobody investigates a cell that was always supposed to be populated.
Older serial numbers were 12 characters and encoded factory, production year and production week. From 2021, Apple moved to randomised serial numbers of 10 characters that encode none of that.
The practical consequence: on a device manufactured after that change, you cannot derive production date, factory or batch from the serial number. Age has to come from first activation date, warranty end date or battery cycle count, which are actual records rather than inferences.
Logic board replacement, whole-unit exchange and warranty repair handle the serial number differently. Some keep the original, some issue a new one.
The keep-original case is the one that misleads. The serial number matches, yet the board, battery or display may all have been replaced. The serial number still links to the same device record, but it cannot answer whether the hardware is still the original set. Component serials and repair history answer that.
Not every device exposes a usable serial number. Some Android units allow the serial to be rewritten, and some engineering or custom builds return a blank or duplicated value. On those units the premise for a serial-keyed join does not hold, so a device identifier plus network address serves as a fallback key, explicitly labelled as a fallback rather than a primary key.
Before the rename, export the mapping from serial number to current name, with a timestamp in the filename. The point is not backup but evidence: with it, any older sheet can be traced back.
Do not remove the old name from search immediately. Staff on site are still holding sheets printed with the old name, and an alias keeps those matches valid during the transition window.
Exports, reconciliations, comparisons and stock counts should all key on the serial number. Names stay as display columns and take no part in matching.
Log the rename time, the previous name and the new name, attached to the serial number. Together those three fields answer a concrete question: which device does this name on an old sheet refer to, and when did it change.
LuckyMDM (Sichuan Starlight Network LLC) keeps the serial number as the record key and treats device name and asset tag as display and search fields only, with each rename logged as rename time, previous name and new name against that serial, so a rename never rebuilds the device record or detaches the command history attached to it.
Take 300 devices and one site transfer that adds a site prefix to 80 of them. Replace the numbers with your own ledger; the method holds.
The difference is not mainly the money. It is that reconciliation goes from "someone has to open three spreadsheets" to "a script runs". The first gets skipped when the week is busy; the second costs the same either way.
Names allow duplicates and allow editing. The issue is not uniqueness but mutability: even if all 300 names are distinct today, one transfer or one re-lease changes the key. A primary key must be permanently stable, not merely unique at this moment.
That one-to-one relation holds only where label management is clean. Reprints duplicate numbers, bulk imports shift columns, and swaps carry old labels across. The relation is what process intends, not what the data guarantees, so keying on the asset tag makes label quality the foundation of the system.
Finding the device proves the record survived and the key is intact. The break is in the downstream snapshots that copied the name. They will not update and will not throw an error, so the test is whether the old name still matches, not whether the new name is searchable.
Boundary one: the serial number links devices, not business documents.
It answers which device a record belongs to, not which document the device was on at the time. One device may pass through a swap record, a repair record and a transfer record, each with its own number. Joining a business chain directly on the serial number produces a list rather than a chain; a bridge table holding serial, document number and timestamp is required in between.
Boundary two: after refurbishment or a logic board repair, the serial number still works as a join key but not as a proof of identity.
The job of a join key is to point at the same device record, and hardware changes do not affect that. The job of proving identity is different: that needs component serials, repair history and hardware identifiers together. The premise is to keep the two uses separate; a field that links records is not automatically a field that proves identity.
Why not keep both the name and the asset tag as keys, and pick per case?
Because two keys means two failure modes and two reconciliation routines. One immutable key keeps every join on the same rule, which is what makes the check automatable.
Settings, General, About, where the serial number is listed. The same value should appear on the box, the invoice and in the business manager console; when they disagree, the value read from the device wins.
Two systems hold different names for the same serial number. Which one is right?
Neither is authoritative. The serial number is; each system maintains its own name for its own context. Forcing one name everywhere deletes information that described a different situation.
Export the serial-to-name mapping with a timestamp. With it, every older sheet can be traced; without it, tracing means walking the site.
Use a device identifier plus network address as a composite fallback key, label it as a fallback in the ledger, and sample-verify the match rate rather than demanding full coverage.