Laptop imaging assumes a bench, a network share and a machine in your hands. For a fleet that ships direct from a supplier to somebody’s home, none of those exist, and most of what imaging used to do has moved somewhere else.
TL;DR
- Traditional imaging is largely obsolete for distributed fleets, and the reason is logistics rather than technology.
- Enrolment replaces it: the device registers to your organisation at purchase and configures itself on first boot, anywhere.
- The one thing still worth doing before a machine ships is capturing the serial and tying it to a person.
- Imaging survives in specific cases: locked-down builds, offline environments, and machines that must not reach the internet first.
- Do not ship a device to your office to image it and then ship it on. That is two international movements for no benefit.
- Test first boot from a home connection. Policies written against an office network are the usual failure.
What imaging was for
Applying a known-good state to every machine: operating system version, applications, settings, security configuration, all identical, all verified before handover. It solved a real problem, which was that machines arrived from manufacturers in unpredictable states full of software nobody wanted.
It depended entirely on physical possession. A technician, a bench, a fast local network and a stack of machines. Every part of that assumption fails when the laptop goes from a supplier’s warehouse to an employee’s flat without passing through any office.
The honest position is that imaging has not been improved so much as routed around.
What replaced it
Enrolment. The device is registered to your organisation at the point of purchase, and on first boot it contacts your management service, identifies itself and applies policy, applications and restrictions without anybody present.
The practical difference is where the work sits. Imaging is per device and happens at the end. Enrolment is configured once and happens automatically for every machine afterwards, which is why the shift is worth making even for companies that could still image.
What you give up is the guarantee of an identical starting state. Machines arrive with whatever the manufacturer shipped, and your policy adjusts it rather than replacing it, which is acceptable for most fleets and genuinely not for some.
Where imaging still makes sense
| Locked-down builds | Where the shipped operating system cannot be the base at all | Image centrally, accept the shipping cost |
| Offline or restricted environments | Machines that will never reach your management service | Image, since enrolment has nothing to contact |
| Must not touch the internet first | Policy requires configuration before any network connection | Image, or use a provisioning package applied offline |
| Reissued machines | Device returning from a leaver, going out again | Wipe and re-enrol rather than image. Simpler and faster |
| Everything else | Standard office and engineering machines | Enrolment. Do not image |
The fourth row catches people out. A returned laptop feels like it needs imaging because it has somebody else’s state on it, and a wipe followed by re-enrolment achieves the same result with less work and no bench.
A worked example
A company kept imaging after going remote, because the build was well-tested and nobody wanted to change it. Machines were shipped from the supplier to the head office, imaged, then shipped on to the employee.
For domestic hires this added two days. For the four international markets it added between nine and fourteen, because each machine crossed a border twice and attracted a customs process in each direction. The imaging itself took forty minutes.
Moving to enrolment and shipping direct removed the double movement entirely. The build was reproduced as policy over about three weeks of configuration work, and the only capability genuinely lost was the ability to hand somebody a machine that had already been switched on and checked.
What to do before a device ships
Checklist:
- Confirm the device is registered to your organisation for automated enrolment, which depends on the purchase channel.
- Capture the serial from the order and record it against the person before despatch.
- Test the complete first-boot flow on one machine from a home connection, not from your office network.
- Time that first boot, so the instruction you send quotes a real figure rather than a guess.
- Send a two-sentence first-boot instruction: connect to wifi, sign in with this address, leave it alone for the stated time.
- Provide a contact route that does not need the new account, meaning a phone number.
The timing detail matters more than it sounds. Enrolment often shows no visible progress for several minutes, and a new starter who has not been told that will restart the machine, which half applies the configuration and turns a clean setup into a support call.
Reproducing a build as policy
Teams moving away from imaging usually find the work is smaller than feared and differently shaped. An image is a single artefact; a policy set is a list of decisions, and most of the effort goes into discovering which decisions the old image encoded without documenting.
Start by listing what the image actually did, in categories: applications installed, settings changed, security configuration applied, accounts created, things removed. The last category is the one people forget, since images frequently stripped manufacturer software that policy now has to remove separately.
Then accept that the first few machines will reveal gaps. Run two or three through the full flow before committing a cohort, and treat the differences from the old build as a list to work down rather than a reason to revert.
Because enrolment depends on the device being registered at purchase, this is partly a procurement question. A machine bought from a general retailer is usually not registered, and bringing it into automated enrolment afterwards ranges from fiddly to impossible.
Global procurement platforms buy through channels that support enrolment, which removes the per-market supplier problem. Workwize, Deel IT, Firstbase, GroWrk and allwhere all do this to varying depth and none publishes a price.
Disclosure: RemoAsset is owned by the same people who publish PeopleOpsHQ. It is relevant here because the serial is captured from the order rather than from the box, which is the one pre-shipment step that still matters. It publishes no price and requires a demo, it is weaker for hardware it did not supply, and it is not a certified disposal vendor. The alternatives are in our laptop procurement platform comparison.
Final thoughts
Imaging is not obsolete because something better arrived. It is obsolete for distributed fleets because it requires the machine to be where you are, and increasingly it is not. The specific cases where it survives are real and narrow.
If you are still routing machines through an office to image them, price that detour in days per market rather than in minutes per machine. That is usually the whole argument, and the configuration work to replace it is a few weeks once rather than a cost paid on every device forever.
Frequently asked questions
Is laptop imaging still necessary?
For most distributed fleets, no. Modern enrolment lets a device register to your organisation at purchase and configure itself on first boot wherever it is, which removes the need for physical possession that imaging depends on. Imaging survives in specific cases: locked-down builds where the shipped operating system cannot be the base, offline or restricted environments where there is no management service to contact, and situations where policy requires configuration before any network connection.
What is the difference between imaging and enrolment?
Imaging applies a complete known-good state to a machine you are holding, replacing whatever the manufacturer shipped. Enrolment leaves the shipped operating system in place and adjusts it with policy, applications and restrictions applied automatically on first boot. The practical difference is where the work sits: imaging is effort per device at the end of the process, while enrolment is configured once and then happens by itself for every machine afterwards.
Should we ship devices to our office to image them first?
Almost never, and for international hires it is the most expensive habit in device deployment. Routing a machine through your office means two border crossings and two customs processes rather than one, which typically adds nine to fourteen days per international device in exchange for perhaps forty minutes of imaging. Price the detour in days per market rather than minutes per machine and the argument usually settles itself.
How do we handle reissued machines?
Wipe and re-enrol rather than image. A returned laptop feels as though it needs a full rebuild because it carries somebody else’s state, and a wipe followed by automated enrolment reaches the same end point with less work and without needing a bench. It also means a device recovered in one country can be reissued domestically in that country rather than travelling back to wherever your imaging capability lives.
What should we do before shipping a device direct?
Confirm it is registered for automated enrolment, which depends on having bought it through the right channel, and capture the serial from the order so the asset record exists before the machine reaches anybody. Then test the full first-boot flow on one device from a home connection rather than your office network, time it, and send the recipient a two-sentence instruction quoting that real figure. Include a phone number, since somebody stuck mid-enrolment cannot email from the account they are activating.
How much work is it to replace an image with policy?
Usually a few weeks of configuration, and the effort is differently shaped than people expect. An image is one artefact, while a policy set is a list of decisions, and most of the time goes into discovering what the old image encoded without anybody documenting it, particularly the manufacturer software it quietly stripped. Run two or three machines through the complete flow before committing a cohort, and treat the differences from the old build as a list to work down.