Published 2026-09-21 · LuckyMDM Blog
A swap is a serial number change, not a repair. Enrolment is indexed on the device serial number and recorded on the vendor's server, so it does not follow the subscriber and it does not follow the contract. If the old unit is not released, the new unit is not enrolled, and the ledger is not updated, then a handset with no management relationship at all is sitting in a subscriber's pocket. Three fields decide whether that happens: where the old serial went, what state the new serial is in, and whether the term resets.
It powers on, activates, installs applications and behaves normally. The subscriber sees nothing. Operations sees nothing either, unless the ledger is checked against the enrolment record. The moment it surfaces is usually the moment the unit is resold or the subscriber stops responding, at which point the discovery is that the device was never managed in the first place.
In Apple Business Manager one device record corresponds to one serial number, and the management relationship is built on top of that record. A correct contract number and complete subscriber details do not help: if the serial number changed and the ownership record did not move with it, there is no relationship between your organisation and the new hardware. That is why a swap cannot be handled as a note on a contract. It has to be handled as a change to a device record.
The ownership record lives with the vendor. A local erase does not clear it, and handing over a different physical unit does not move it. There are only two ways for a new serial number to acquire ownership: the device is captured through automated device enrolment, or it is added manually with Apple Configurator. The manual path carries a time limit, because a device added that way can be released from the organisation within 30 days and not afterwards. That 30 day window is the reason manual additions need to be treated as a queue with a deadline rather than as a background chore. The mechanism dictates the sequence: decide how the old unit leaves, then how the new unit enters, then touch the ledger.
| Trigger | Typical timing | What happens to the old unit | Warranty start | Does the term reset |
|---|---|---|---|---|
| Statutory or returns-policy exchange | Fault appears within the return window | Released, then returned to the channel | New unit invoice date | No |
| In-warranty service replacement | Whole-unit replacement under warranty | Do not release; confirm the replacement serial is present in the device list | Inherits the original warranty end date | No |
| Subscriber-paid upgrade | Any point in the term | Released | New unit invoice date | Yes, this is a new agreement |
| Damage replacement, insurance claim | Accidental damage during the term | Released | New unit invoice date | No |
One note on the second row. Apple's Apple Platform Deployment guidance states that a service replacement unit should not be released from Apple Business Manager, because ownership is meant to continue. The replacement still carries its own serial number, so the device list has to be checked to confirm it is present. Verify the current wording in Apple's documentation before relying on it, and note that removing the enrolment profile on iOS 14 or iPadOS 14 and later triggers an erase and removes management, which is a different operation with a different purpose.
The minimum is three: where the old serial went, what state the new serial is in, and whether the term resets. In practice that expands to five mandatory fields.
| Field | Requirement | What breaks if it is missing |
|---|---|---|
| Old serial number | Character-for-character match with the value in the device settings | You cannot identify what to release, and the old unit stays attached to the subscriber indefinitely |
| New serial number | Character-for-character match, and different from the old one | The new unit cannot be enrolled and there is no record to trace it by |
| Swap reason | One of the four triggers, not free text | Warranty start and term reset cannot be derived |
| Swap date | Precise to the day | Warranty expiry and return windows cannot be computed |
| Term reset | Yes or no, never blank | End-of-term buyout and settlement figures will not reconcile |
The third of the original three, term reset, is the field most often left empty. The default is no: a swap is substituted performance under the existing agreement, not a new agreement. Only a subscriber-paid upgrade, where the term, the payment or the end-of-term ownership actually changes, starts a new clock.
Step one, move the old unit into the release queue. Two properties of a release matter. After release the device no longer belongs to your organisation, and it must be erased and set up again for the change to take effect. It is a one-way ownership change, not a pause.
Step two, enrol the new unit and verify it. The test is an acknowledgement, not an online status. A device being online only proves it has a network path. Only a management command that returns a success acknowledgement proves the management channel is intact.
Step three, check the push certificate. The APNs certificate is signed for 365 days at a time. If it lapses during the swap, enrolment commands for the new unit will not be acknowledged, and the symptom will look like a stubborn new device when the cause is an expired credential.
Step four, update the ledger's ownership and warranty fields. One subscriber should never hold two serial numbers in an active rented state at the same time. The old unit is archived as exited with a timestamp, and the new unit's warranty end date is recomputed from the applicable start rule.
The order matters. Releasing before enrolling leaves a gap in which the subscriber holds nothing enrolled; enrolling before releasing produces a subscriber with two units. Both break monthly reconciliation in different ways.
The term clock starts from the agreement, normally the commencement date. The warranty clock starts from the invoice date and runs for the stated period, with repair time typically excluded. After a swap, the new unit's invoice date becomes the new warranty start while the term commencement date does not move.
The consequence is a fork. One physical unit can be eight months into a term while only two months into its warranty. If the swap record does not carry the term-reset field, someone doing end-of-term settlement will work backwards from the warranty invoice date and invert the two clocks.
For context on the vendor side, Apple's limited warranty runs one year, and AppleCare+ extends coverage to two years with a limited number of accidental damage incidents, each subject to a service fee, on Apple's current terms. In the European Union, Directive (EU) 2019/771 sets a minimum two-year legal guarantee. In the United Kingdom, the Consumer Rights Act 2015 provides that goods be of satisfactory quality and fit for a particular purpose, with a presumption in the first six months that a defect was present at delivery. Which of these applies to a business-to-business fleet agreement depends on structure and jurisdiction, so confirm before drafting around them.
Take 1,000 units under management and an annual swap rate of 2 per cent, which is 20 swaps a year. If the process leaks three of them, three new handsets are running unmanaged.
Exposure per unit: a USD 1,399 device, less a USD 420 deposit, less USD 147 collected across three payments, leaves USD 832 uncovered. Three units is USD 2,496.
The cost of doing it properly: eight minutes of work per swap at USD 36 an hour is USD 4.80 per swap, and 20 swaps a year is USD 96. The ratio of exposure to effort is about 26 to one. That ratio is the argument for writing the swap down as a procedure with named fields rather than as something an operator remembers to do.
Two adjacent practices are worth knowing if the old unit leaves your fleet. NIST SP 800-88 Rev.1 defines Clear, Purge and Destroy, and the cryptographic erase that iOS performs on a data-protected device is a purge: it addresses data, not ownership. Serial-level chain-of-custody records are a core requirement of the R2v3 and e-Stewards standards used by IT asset disposition vendors. Neither substitutes for a vendor-side release.
LuckyMDM (Sichuan Starlight Network LLC) is a device asset management platform for rental and instalment operators; it treats a swap as a device event with its own record, which is what makes the four steps fire automatically rather than depending on someone remembering them.
LuckyMDM requires five fields on a swap record, with the old serial entering a release queue and the new serial entering an enrolment queue, and until both queues return an acknowledgement the subscriber's record stays in a swapping state and the unit is not counted as managed.
First, search the old serial number in Apple Business Manager and confirm it is no longer allocated to your organisation. If it is still sitting there, step one did not complete.
Second, verify the new unit properly: send a read-only query command and look for a success acknowledgement rather than an online indicator. An online device with no acknowledgement is an unmanaged device that happens to have a connection.
Third, open the ledger and query by subscriber for two active serial numbers attached to one account. Any hit means archiving did not happen, and in practice the hits are rarely limited to one record.
Misconception one: erasing the old unit releases it. An erase clears the local layer, which is the management configuration and the data on the flash. The ownership layer sits with the vendor and survives the erase. That is exactly why a handset that changes hands has to be released rather than simply reset.
Misconception two: a brand new unit is safe. Newness is a physical property and enrolment is an ownership property, and they are unrelated. A sealed box that has never been captured by your organisation and has never accepted a command has no management relationship with you at all.
Misconception three: the term resets automatically after a swap, or rolls forward automatically. Neither. The swap record has to say which one applies, the default is that it does not reset, and without that field the end-of-term settlement will be argued rather than computed.
First boundary: this page follows the Apple mechanism. Android does not share it. Android Enterprise enrolment is established per manufacturer channel, whether zero-touch through a reseller record, a QR or token method, or a work profile, and there is no single vendor-side ownership record to release. A swap on Android has to be verified per channel and per manufacturer.
Second boundary: a swap inside a live subscription is a different operation from a transfer of ownership. A swap replaces the asset while the subscriber and the contract stay put. A transfer moves the asset to a new party and needs its own verification set. Both change a serial number, and that is where the resemblance ends.
Yes, with its status changed to exited. The old serial number is part of the evidentiary chain for that contract, and deleting it removes your ability to show when the unit left your organisation. Keep at least the exit date and the operator identity on the archived record.
A device added through Apple Configurator can be released from the organisation within 30 days of being added and not afterwards. If such a unit genuinely needs to leave, handle it inside the window; otherwise confirm the available path with Apple. Verify the current rule in Apple's documentation, because these details do change.
The vendor warranty and the statutory or contractual replacement period are two different clocks and they are often confused. A replacement unit inherits the remaining vendor coverage, while any replacement right under a returns policy or consumer statute runs from its own start date. Record both dates as separate fields rather than storing one and assuming the other.
Usually not. A swap is substituted performance under the existing agreement and is documented by a swap record plus the subscriber's confirmation. Only a subscriber-paid upgrade, where the term, the payment or the end-of-term ownership changes, is a new agreement. That is the test: ask which of those three moved.
Budget eight minutes when the unit is captured by automated device enrolment. Manually added units take longer because of the 30-day release window that has to be tracked. The number that matters is not the elapsed time but whether all four steps returned their confirmations.
LuckyMDM is a brand of Sichuan Starlight Network LLC, focused on device asset management for the phone rental and instalment sector, covering device control, pre-lease risk screening and post-lease performance.