Published 2026-10-03 · LuckyMDM Blog
The short answer: moving a device from one depot to another changes three fields in the asset register - custodian, accountable person and physical state - and leaves the management relationship untouched. Most cases of a register that no longer matches the shelf are not lost hardware. They are transfers that were recorded once instead of twice: the dispatching depot filled in the form, the receiving depot never confirmed, and the device has been sitting in transit state ever since while the physical unit is already on a counter two hundred kilometres away.
Once a device is enrolled, the relationship between its serial number and the enrolling organisation is recorded on the vendor's side of the platform. Where the unit sits and who holds it on any given day is a different layer entirely. A depot transfer happens in that second layer.
This distinction is what makes the rest of the process obvious. The underlying mechanism is straightforward: the management relationship depends on the vendor's record, while custody depends on the register. If the management relationship is unaffected, then re-enrolment is not part of the workflow. If the register entry is what changed, then the register entry is what has to carry the evidence.
Updating the custodian without the accountable person produces a unit that appears on a depot's list with nobody willing to own it. Updating the custodian without the physical state produces a unit that physically sits in one depot while still counting towards another depot's stock. Both failure modes share a property that matters: the totals still add up, so no automated check will ever fire.
A device enrolled through automated device enrolment stays supervised, keeps its existing configuration and keeps its managed apps regardless of which depot holds it. Re-enrolment belongs to a different event - a change of enrolling organisation or a change of management service, which is a migration with a materially different risk profile.
One signature on a transfer form is the most common pattern in small and mid-sized multi-site operations. The problem is not the length of the process. It is that a single confirmation cannot attribute anything.
The dispatcher attests to the condition of the unit at the moment it leaves: cosmetic grade, accessory completeness, functional checks, and that the serial number on the paperwork matches the register character for character. That is evidence timestamped at handover.
The receiver attests to the same four items at the moment of arrival, timestamped later by exactly the transit period.
Between the two confirmations the unit is in nobody's custody. A scratch on the display or a missing cable cannot be attributed to either side without the second timestamp. The root cause of most of these disputes is not malice, it is timing: this dispute usually surfaces at remarketing, months later, by which point the people on both sides may have changed roles and the paperwork is all that remains.
The test for a usable record is simple. If any column in the table below is missing, the document carries almost no weight in a dispute.
| Field | Completed by | Failure test |
|---|---|---|
| Serial number / IMEI | Dispatcher | Character-for-character match with the register; model name is not acceptable |
| Cosmetic grade | Dispatcher once, receiver once | Both columns populated; one column means incomplete |
| Accessory checklist | Dispatcher | Charger, cable and box ticked individually; the word complete is not acceptable |
| Dispatch timestamp and person | Dispatcher | Minute precision; late entry stores the actual event time separately |
| Receipt timestamp and person | Receiver | Same rule; if absent, state does not move to in-stock |
| Physical state transition | System | Dispatch sets in-transit, receipt confirmation moves to target state |
Platforms such as LuckyMDM (Sichuan Starlight Network LLC), which focus on equipment asset management for the rental and instalment sector, treat a transfer as a change record carrying two confirmations and two timestamps rather than a location edit - moving the location without moving the accountability changes nothing.
One depot grades a unit at 95 percent, another calls the same unit grade B. That gap is not a matter of opinion. It is an internal cost with a number attached.
Take a remarketing value of 400 USD and a spread between adjacent grades of 5 percent to 10 percent:
An operation handling 200 transfer records a month with a 2 percent grading mismatch rate is looking at 4 records needing manual review. At 45 minutes per record that is 3 hours a month. The review time is not the real cost. The real cost is that those 4 units carry the wrong residual value for the rest of their life - the register keeps the dispatcher's grade while the eventual sale reflects the receiver's condition, and the difference appears all at once at year end.
Two depots grading one unit two grades apart is rarely a question of who looked more carefully. It is three uncontrolled variables: lighting, measuring tool and the person doing the grading. Standardising those three costs far less than reviewing records one by one, and it is the only intervention that reliably reduces the mismatch rate.
This is the property that makes transfers troublesome. A transfer error leaves the register internally consistent. The fleet total is unchanged, the on-rent count is unchanged, and the in-stock count has simply moved from one depot to another. Every aggregate still reconciles.
The error only becomes visible when someone holds the physical unit and compares it to the record, or when two timestamps are cross-checked against each other. That is why the third check below exists - in-transit dwell time is the only indicator that surfaces these problems before a physical count does.
LuckyMDM requires custodian depot, accountable person, physical state and last check-in time as four mandatory fields on a single change record, and holds the physical state at in-transit until the receiving depot confirms.
An internal transfer changes neither the enrolment method nor the supervision state, and no configuration needs to be reissued. Re-enrolment belongs to a change of organisation or a change of service, which is a migration window with a different order of risk.
A form without a receipt confirmation is half an evidence chain. The failure test is blunt: if the receipt timestamp and the receiving person are blank, the document will not survive a dispute.
Attribution happens at handover, not at sale. By the time a unit is graded again, both timestamps are months old, accountability cannot be established, and the cost lands on the operator.
Boundary one: single-site operators do not need this workflow. With no dispatch and receipt sides there is nothing to confirm twice. The equivalent control for a single site is a sign-out and sign-in log for loans and repair, and the emphasis belongs on the log rather than on dual signatures.
Boundary two: a transfer between legal entities is not a depot transfer. A change of entity changes the enrolling organisation as well, which means releasing the serial number on the vendor side and binding it again elsewhere. During that interval the device has neither management nor a register entry. That is a migration window and sits outside this workflow. Android has no single vendor-side equivalent of the serial-to-organisation record, so the release criteria have to be defined separately for those fleets.
No. Policies are issued against the serial number and have no relationship to which depot holds the unit. Existing configuration, supervision state and managed apps are unchanged by an internal transfer.
Two units were swapped and the serial number was recorded wrong. What now?
Work from the serial number in the register, not from a model name or a handwritten tag on the paperwork. Correct it with a new change record that leaves the wrong value in the history rather than overwriting it.
The receiving depot never confirms and the unit is stuck in transit. Does it matter?
It does. An in-transit unit counts towards neither depot's stock, which means it has effectively disappeared from the register. Anything past 24 hours should be escalated manually.
Yes. Whenever accountability for a unit moves from one person to another, the same record applies regardless of whether rent is being charged. The only difference is that the physical state reads in-stock rather than on-rent.
During transit a unit generates no rent and cannot be actioned by anyone. The three components of cost per unit per day - capital, depreciation and zero revenue - are covered in the dedicated article on idle days on this site.