You don't migrate a fleet

Most companies that consider changing how they manage devices already own the devices. That sounds obvious, but it shapes the whole decision, because the fleet already on desks tends to get treated as a reason to postpone. This issue is about why that instinct is backwards, what you actually inherit when you take over a fleet, and why the migration project everyone dreads is optional.

You don’t migrate a fleet — it migrates itself, one event in the employee hardware lifecycle at a time. Most companies considering a change in how they manage devices already own them, and treat the fleet on their desks as a reason to wait. But the two most-raised topics across 3,977 customer conversations — where devices sit between users (22.8%) and offboarding and retrieval (22.6%) — are both about devices a company already owns. The practical move is to make the whole fleet visible on day one through IT asset management, then bring each device under management when an offboarding, repair or refresh touches it anyway. No big-bang migration required.

The signal: the fleet is the work, not the obstacle

We analysed 3,977 customer conversations from April 2024 to August 2026, counting only topics the customer raised before we did.

Sort the lifecycle topics by when they happen in a device’s life and a clear pattern emerges. The two most-raised topics in the entire corpus — where devices sit between users (22.8%) and offboarding and retrieval (22.6%) — are both about devices a company already owns. So are certified wipe (12.1%) and buyback and disposal (10.7%). The topics about devices not yet bought — enrollment before shipping (22.0%) and speed and lead time (17.9%) — matter enormously, but they are the minority of the list.

Then there is the objection itself. When we hand-read a random sample of 41 new-business conversations end to end, roughly a quarter of buyers raised the fleet they already had as a reason to hesitate. About a third raised timing — and timing, in this category, rarely means no. It means later. One buyer summarised it better than any analysis could:

“The first call was like two months ago, and then I didn’t do anything about it.”

Put those two findings next to each other and there is a contradiction. The work buyers ask about is overwhelmingly about the devices they already own. And the devices they already own are the reason they give for waiting.

The problem: you inherit the locks

Here is the version of the objection we hear most often, from an IT lead at a software company of around fifty people:

“Our people already have laptops. Lots need replacing, but a dozen are still brand new. Can you take them into your system?”

It is a completely reasonable question, and it contains the whole problem. Notice what the fleet actually is: not a uniform block of devices waiting to be moved, but a mixture — some new, some ageing, some due for replacement within the year. That is what every real fleet looks like. There is never a clean moment when everything is at the same point in its life.

Which is why the instinct to wait for one never pays off.

The instinct comes from imagining the change as a migration project. Export the asset spreadsheet, reconcile it against reality, move every device into the new system at once, pick a quiet week to do it. Put that way, of course it gets postponed — to the next refresh cycle, the next budget year, the moment after the current hiring push. And while it is postponed, every offboarding, every repair and every redeployment in the gap runs the old way.

There is a second reason fleet takeovers feel heavy, and it is more concrete than project fatigue: you inherit the locks.

Every device in an existing fleet carries whatever its last administrator set on it. Some have a PIN that left with the person who chose it. Some are tied to an Apple ID through Activation Lock, which survives a factory reset because that is precisely what it is designed to do. Some remain enrolled in the previous organisation’s device management, which is a different lock again — having the PIN does not help.

And then there is the one almost nobody anticipates. A device is released by its previous owner, wiped successfully, and has its operating system reinstalled. On first boot it enrolls itself straight back into the old management system — because it was still assigned to the previous organisation’s automated enrollment. Zero-touch working exactly as designed, in reverse. The fix is to release it from Apple Business Manager and from the MDM’s enrollment configuration. Both, not one. Windows has its equivalent: a device still registered in a previous organisation’s Autopilot will keep presenting that organisation’s setup screen until it is deregistered.

Only the lock holder can release any of these. Not the warehouse, not the vendor, not the new administrator. And a device that cannot be opened cannot be wiped — which means it usually cannot be resold, and often cannot even be recycled normally. An asset quietly becomes a line item.

None of this makes a fleet takeover impossible. It makes the big-bang version of one miserable. So the question worth asking is whether the big-bang version is necessary at all.

It is not.

A laptop is bought once. Every other event in its life — deployment, repair, swap, storage, offboarding, redeployment, retirement — happens to a device the company already owns. Those events are going to happen on their own schedule regardless of what system you use. The practical move is to let them do the migration for you: make the entire fleet visible on day one, and bring each device under management at the moment something happens to it anyway. Someone resigns; that laptop moves across as part of their offboarding. A screen cracks; that one moves as part of the repair. A refresh comes due; the new device starts life in the new system and the old one retires out of it.

You don’t migrate a fleet. It migrates itself, one event at a time.

The operator takeaway: five moves, in order

1. Separate visibility from management. They are different decisions and they should not wait for each other. Get every device into one view first — serial, model, specification, assigned person, location, condition. Decide what gets actively managed device by device, over time.
2. Let lifecycle events do the moving. The next offboarding is the migration. So is the next repair. Design the process so a device crosses over when it is touched, rather than scheduling a weekend to touch all of them.
3. Inventory the locks before you need them. Which devices sit in which management system? Who holds the administrator credentials? Which machines are tied to personal or former employees’ Apple IDs? Answering this during an offboarding is how devices end up stranded.
4. Release properly — from both places. Removing a device from your MDM console is not the same as releasing it from Apple Business Manager or Autopilot registration. Skip either and the device may go straight back home on its next setup.
5. Stop waiting for a uniform fleet. It does not exist. A mixed fleet — some new, some due for replacement — is the normal state, and it is the easiest kind to transition through events rather than projects.

Before your next planning cycle, five questions worth answering in writing:

• How many devices do we own, and can we see all of them in one place today?
• Which management systems are they enrolled in?
• Who holds the credentials to release a device from each?
• How many offboardings, repairs and refreshes do we expect in the next twelve months?
• Which of those could be the moment a device transitions — instead of waiting for a project?

One GroWrk lens

Modern IT runs on three layers. Identity governs who someone is. Endpoint management governs what a device is allowed to do. The physical layer — procure, deploy, store, retrieve, repair, redeploy, retire — is the one that never got automated.

ITAM records the asset. MDM controls the asset. GroWrk executes the physical lifecycle.

That is why we built GroWrk so a company can bring its entire existing fleet into view without moving anything, and have individual devices come under our management when a qualifying event happens — an offboarding, a repair, a refresh — including automatically when that event is triggered from an HR system. Nothing about the fleet has to be migrated up front.

The locks are the part I would be honest about. We deal with them every week, and no platform makes them disappear: a device locked to someone else’s account can only be released by that account. What a good process can do is find the locks early, give every locked device a clock and a defined outcome, and make sure nobody discovers them for the first time on the day a device needs to move.

One stat

22.8% and 22.6%. The two most-raised topics across 3,977 customer conversations — where devices sit between users, and offboarding and retrieval — are both about devices the company already owns.

(GroWrk Call Intelligence — analysis of 3,977 customer calls, April 2024 – August 2026. Buyer-led mentions only; conversations can raise several topics.)

The laptops already on your desks are not the obstacle to changing how you manage them. They are most of the work — and the work was going to happen anyway.

The only real decision is whether the next event runs the old way, or becomes the first device to move.

If you want to see how an existing fleet comes into view without a migration project, we would be glad to show you.

Book a demo →