Switching Equipment Providers Without Losing the Fleet

TL;DR

• Nothing physical moves in this migration. The laptops stay with the same people in the same countries, which is exactly why teams underestimate it.
• What migrates is the register, the devices in transit, any stock the old vendor holds, open collections and your integrations. Each breaks differently.
• Export the full register with history before you give notice. Afterwards your ability to ask for anything drops sharply.
• Stock sitting in the outgoing vendor's warehouse is the most expensive loose end, and nobody prices it until the contract has already ended.
• Overlap for one full cycle rather than cutting over on a date. A date assumes nothing is in flight, which is never true.
• Reconcile both registers before closing the old account. That step is what finds the devices nobody had noticed were missing.

Eleven Machines Nobody Could Account For

A 240-person company moved equipment providers at the end of a contract term. The decision was sound, the new vendor was better suited, and the migration was handled by somebody competent who treated it as an administrative task because that is what it looked like.

Six months later a finance review asked for a device count. The new platform held 229 machines. Payroll showed 240 current staff and the company had bought 266 laptops over four years. Reconciling the three numbers took a fortnight and ended with eleven machines that could not be accounted for at all.

What had happened was mundane. Four were in transit during the cutover week and were marked shipped in the old system and never created in the new one. Three were collections booked with the old vendor for leavers whose last day fell after the switch, and nobody chased them because the collection existed in a system nobody was logging into any more. Two were spares sitting in the old vendor's warehouse that were disposed of when the storage agreement lapsed. And two were simply never imported, because the export the new vendor received had been filtered to active assignments and those two were marked in repair.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

None of that was a vendor failing. Every one of those eleven devices fell into a gap created by treating a cutover as a date rather than a period.

What Actually Has to Move

The mental model that causes trouble is thinking of this as a data migration. It is partly that, and it is also a handover of several in-progress physical processes.

The second and fourth rows are where real hardware disappears. Both involve a physical object mid-journey and a process that assumes somebody is watching it.

Export Before You Give Notice

This is the single highest-value action in the whole migration and it costs ten minutes.

Get a complete export while the relationship is still normal. Not a dashboard screenshot and not a current-state list. A file containing every device with serial number, model, current holder, location, assignment date, purchase date, cost, condition history and current status including anything marked in repair, in storage or in transit.

The history is the part that does not come back. A list of what you own today is reconstructable from a physical audit, painfully. Knowing that a specific machine has been reassigned three times, repaired once and is therefore a replacement candidate is not reconstructable at all. That information exists in one place and you are about to stop paying for access to it.

The status filter is the trap. Exports frequently default to active assignments, which silently drops machines in repair, in storage or awaiting redeployment. Those are exactly the devices most likely to go missing, because nobody is holding them. Ask explicitly for every record regardless of status, then check the row count against your own expectation.

And do this monthly as a habit whether or not you are switching. A register that exists only inside a vendor's product is a register you rent.

The Stock Question

If the outgoing vendor holds any physical inventory for you, that is the most expensive unresolved item in the exit and the one most often discovered after the contract has ended.

Three categories usually exist. Spares held for fast replacement. Returns awaiting redeployment, which is machines collected from leavers and not yet reissued. And stock bought ahead of a hiring plan that may or may not have happened.

Each has three possible destinations and all three cost money.

Ship it to the new vendor. You pay freight on machines generating no value, and the new vendor has to receive, check and record them, which they may charge for. Appropriate for newer stock you will genuinely reissue.

Ship it to an office. Workable if you have one and creates a cupboard with no owner if you do not. Also moves the storage problem rather than solving it.

Sell or dispose of it. Recovers some value and is frequently the right answer for anything over three years old, where freight plus handling exceeds the residual.

Decide before you give notice, get a storage end date in writing, and agree a rate if it overruns. Vendors are reasonable about this when asked in advance and markedly less so when the contract has ended and your machines are occupying space they want back.

Overlap, Do Not Cut Over

A date-based cutover assumes that on the chosen morning nothing is in transit, no collection is booked, and no machine is in repair. That is never true at any company that is actually operating.

Running both contracts for a month costs one month of double subscription. That is the entire price of eliminating the only failure mode that loses physical hardware.

Stop new orders with the outgoing vendor two weeks before the switch. Nothing new goes into flight, so the in-transit population drains naturally rather than being frozen mid-journey.

Let everything already in flight complete under the old vendor. Do not attempt to transfer a live shipment or an open collection. Transferring an in-progress physical process between two logistics providers is where things get lost, and the cost of simply letting it finish is nil.

Route all new activity to the incoming vendor from an agreed date, with both contracts still live.

Then reconcile, and only then close the old account. The reconciliation is the step that catches the eleven machines.

Five Questions Before You Commit to the Switch

Why are you actually leaving? Write it in one sentence. If the answer is price, check whether a reduced inclusion list with the current vendor gets you there, because switching costs frequently exceed the saving. If the answer is coverage or capability, a switch is justified and the specification for the replacement should name that gap explicitly.

What does your contract say about exit? Notice period, data export, what happens to stock, and whether there is a termination charge. Read it before you start conversations with anybody else, because the answers change the timeline.

Who owns the migration, by name? This is a project with physical consequences and no deadline pressure, which is the combination most likely to drift. Somebody needs it on their list with time against it.

What is your real device count? Not headcount. Devices, including spares, machines in repair, and anything with a leaver. If you cannot produce that number today, produce it before you move, because you cannot reconcile against a figure you do not have.

When is your quietest month? Migrate then. Doing this during a hiring push or a quarter-end means the in-flight population is at its largest exactly when you need it smallest. For most companies that means avoiding January and September, and for anybody with a seasonal business it means asking the question rather than assuming.

The Options

RemoAsset, named below, is owned by the same people who publish HROpsLab. Its limitations are stated as plainly as everybody else's, and one of them is directly relevant to a migration.

RemoAsset

Procurement, deployment, tracking and retrieval for distributed teams, with devices enrolled into your management system before dispatch.

Directly relevant to switching: it is noticeably weaker for hardware it did not supply, and in a migration your entire existing fleet arrives as hardware it did not supply. That is the specific thing to test before committing, by handing over a real export and asking which fields survive. Its other limits stand: it publishes no price and requires a demo, and it is not a device management system.

Workwize

Hardware lifecycle with its own warehouse network. Its domain is now goworkwize.com and the older address no longer resolves, verified 14 October 2026.

For a migration: owned warehousing makes the incoming stock question easier, because receiving and holding your existing spares is a native capability rather than a favour. The same property makes leaving Workwize harder later, since more of your inventory sits with them.

Firstbase

Equipment on a subscription basis with retrieval and replacement included by design.

For a migration: moving an owned fleet into a subscription model is awkward, because the commercial shape assumes the vendor provides the hardware. Ask directly how existing owned machines are handled, since the answer varies and determines whether this is even a viable destination.

GroWrk

Procurement, deployment and retrieval across a wide country list, scoped per customer.

For a migration: a scoped arrangement can be written to include the import work, which is an advantage. It also takes longer to agree, so start the conversation earlier than you think you need to.

allwhere

Consultative, closer to a managed service than a platform.

For a migration: a managed service will often do more of the migration work for you, which is worth real money when nobody internally owns it. Confirm whether that is included or chargeable.

Deel IT

Devices attached to an employment platform.

For a migration: only coherent if your device population and your employed population are the same. If some staff are employed directly, the migration leaves you with two arrangements rather than one.

The Comparison

The first column is the one that matters on a migration and it is the column no vendor leads with, because inbound fleets are a cost to them rather than a selling point.

The Decision Table

The Integrations Nobody Lists

Integrations get one row in the table above and they deserve their own section, because they fail silently and they fail at the worst moment: when a new person starts.

The onboarding trigger is the important one. At most companies something in the HR system or the onboarding checklist causes a device to be ordered. That something points at a specific vendor, through an API connection, an email address, a form or a person's habit. After a migration it still points at the old one, and the failure is invisible until a new starter has no laptop on day one.

Find out what the trigger actually is before you switch, which is harder than it sounds. Ask the person who processes new starters to walk you through what they do, step by step, rather than reading the documented process. The documented process and the real one diverge, and the real one is what breaks.

The directory connection is the second. Several platforms sync employee lists so that assignments map to people automatically. When that connection moves, check what happens to people who joined during the overlap, because they may exist in one system and not the other.

Then the quiet ones. A shared mailbox rule that files vendor notifications. A dashboard somebody built that reads from the old platform. A monthly export feeding a finance spreadsheet. None of these is load-bearing and all of them stop working without announcing it, and the person who notices is usually the one who built it, three months later.

Write the list before you migrate. Walk the new-starter process end to end, ask whoever owns finance reporting what they pull and from where, and check whether anybody has built anything on top of the old platform. Half an hour of asking prevents the day-one failure that makes a migration visible to people who should never have known it happened.

What the Incoming Vendor Needs From You

Migrations go badly in both directions, and the half within your control is what you hand over. A new vendor given a partial picture builds a partial register, and the gaps compound from day one.

The full export, including non-active statuses. Covered above and worth repeating because it is the single most common omission. Say explicitly that you want machines in repair, in storage, awaiting collection and assigned to leavers, because a default export drops all four.

Your device standard, as a specification. Processor class, memory, storage, screen size, operating system, rather than a model name. Models go out of stock and a standard anchored on one specific machine expires within months.

The country list with headcount, including single-person countries, because those are where an incoming vendor most often discovers they cannot serve you and it is much better to find that out during onboarding than during a hire.

Your real joiner and leaver numbers from last year. This drives their capacity planning and their quote, and an optimistic figure produces an arrangement sized for a company you are not.

The stock you are sending them, listed in advance with condition and age, so they can tell you what is worth receiving. A vendor who sees the list will often advise disposing of part of it, which is advice against their own interest and worth listening to.

And the date your overlap starts and ends. Vendors handle migrations regularly and will plan around a stated window. Without one they assume a date, which puts you back in the cutover failure mode through a different door.

Warranties, Which Follow the Device

Warranty handling is the detail most likely to produce an unpleasant surprise in month three, and the mechanics are simple enough to settle in one conversation.

The warranty itself follows the hardware, not the vendor. A machine with two years of manufacturer cover retains it regardless of who manages your fleet. That is the good news and it is why this rarely becomes a crisis.

The paperwork frequently does not follow. Proof of purchase, the registration against your organisation, and any extended cover bought through the old vendor may all sit with them. A claim without those is slower and occasionally refused.

Extended or third-party cover is the exception. Where the old vendor sold you additional cover as part of their service, that may genuinely terminate with the contract. Ask specifically whether any cover you hold is manufacturer-backed or vendor-provided, because the two behave completely differently on exit.

So ask for warranty records as part of the export rather than assuming they travel with the machines, and ask the incoming vendor whether they will register your existing fleet for support purposes. Some will and some will only support what they supplied, which is another facet of the existing-hardware question and worth testing with the same export.

The Reconciliation That Finds the Gaps

This is the step teams skip because it happens after the interesting part is over, and it is the only step that proves the migration worked.

Count four things independently. The old vendor's final export. The new vendor's register. Your own purchase history. And your current headcount. Those four numbers will not agree, and every difference is information.

Investigate each discrepancy as a physical object. A device present in the old export and absent from the new register is sitting somewhere real. Possibly with a leaver, possibly in a warehouse, possibly in a repair queue. Treat it as a location question rather than a data question, because that is what it is.

Pay particular attention to non-active statuses. Machines in repair, in storage and in transit are the three categories most likely to be dropped by an export filter, and the three least likely to be noticed by anybody, because nobody is currently using them.

Write down what you could not resolve. Some devices will remain unaccounted for and the honest move is to record them as such with their last known holder and date, rather than quietly removing them from the register. An eleven-device write-off that somebody decided is a different thing from eleven devices that silently vanished.

Then close the old account, and not before.

One practical note on how to run it. Do the reconciliation with both vendor portals open and your own export in a third window, rather than exporting everything into a spreadsheet and comparing offline. Most discrepancies resolve in seconds when you can see the status field in the source system, and the ones that do not resolve that way are the genuine gaps worth chasing. Done offline, every difference looks equally serious and the exercise takes three times as long.

And keep the reconciliation file. It is the only record of what the fleet looked like at the moment of transition, which is exactly the question somebody will ask in a year when a device turns up that nobody can place.

The Devices With Leavers Right Now

Open collections deserve their own treatment because they are the single largest source of permanently lost hardware in a migration, and the reason is structural rather than careless.

A collection in progress involves a person who no longer works for you, a courier booking, a packaging delivery and a chase sequence. It is the only process in this whole area where the counterparty has no obligation to you and no reason to prioritise it. Add a vendor change in the middle and the already-weak chain loses its only owner.

Freeze the population at the point of notice. Produce the list of every device currently with somebody who has left or is leaving, with their last working day and the collection status. That list is finite, usually small, and it is the thing to hold onto through the whole migration.

Assign every one to the outgoing vendor. Not because they are better at it but because they already have the booking, the address and the history. Transferring a half-complete collection to a new vendor means re-contacting a former employee and starting over, which materially reduces the chance of the machine coming back.

Set a date by which they are closed or written off. Collections that have already run for several weeks before the migration rarely improve afterwards. Decide the cut-off, chase hard until then, and record the remainder as a write-off with the last known holder rather than carrying them forward as phantom assets in the new register.

And handle leavers during the overlap deliberately. Somebody whose last day falls in the window should be assigned to one vendor explicitly, not left to whichever system happens to catch it. Both vendors contacting the same former employee is worse than neither, because it makes the company look disorganised to somebody who has just left it.

What to Tell Your People

A migration touches employees in exactly two ways and both are easy to handle badly.

Where device requests go changes. Say so once, plainly, with a date. Employees who email the old address get silence rather than a bounce, and silence from IT is how somebody ends up buying a laptop on a personal card and claiming it back.

Leavers mid-migration need clear instructions. Somebody whose last day falls in the overlap window may receive packaging from one vendor and chasing emails from another. Decide which vendor handles leavers in that window and make it one of them, not both.

Neither message needs to explain the migration. People do not need to know you changed suppliers; they need to know where to send a request and what to do with a laptop they are returning. Two sentences each.

Timing and Notice

Notice periods in this category are frequently thirty days, and thirty days is not enough.

Work backwards. You need two weeks of no new orders before the switch, a month of overlap after it, and then a reconciliation that takes a week if the numbers are close and a fortnight if they are not. That is roughly two months of actual work either side of the formal date.

So if your notice period is thirty days, start the practical work sixty days before you intend to give notice, not after. The export, the stock decision and the replacement selection can all happen while the current contract is running normally, which is also when the outgoing vendor is most cooperative.

The one thing to do early and formally is read the termination clause. Some agreements carry a charge for early exit, some require notice at a specific point in the term, and some say nothing about stock at all, which is itself the answer to the question of whether you need to raise it.

A Worked Timeline

Abstract advice about overlapping is easy to agree with and hard to act on, so here is the shape as a calendar. Adjust the lengths, keep the order.

Week minus eight: decide and export. Write the one sentence about why you are leaving. Pull the full register with history and every status. Check the row count against what you expect. Read the termination clause.

Week minus seven: the stock decision. List what the outgoing vendor holds, with age and condition. Decide per item whether it ships onward, comes to an office or gets disposed of. This is a decision you can make before anybody else is involved.

Weeks minus six to minus four: select the replacement. Send the identical specification to three or four vendors. Hand each of them a real export during evaluation and ask what survives an import, because that is the test that matters most here and the one nobody volunteers.

Week minus three: give notice. With the export already in hand, the stock destination decided and the replacement chosen. Notice given in this position is administrative rather than a negotiation.

Week minus two: stop new orders. Nothing further goes into flight with the outgoing vendor. The in-transit population begins draining on its own.

Week zero: new activity routes to the incoming vendor. Both contracts live. Employees told where requests go now. Leaver handling assigned to one vendor for the window.

Weeks one to four: overlap. Everything in flight at week zero completes under the old vendor. Nothing is transferred mid-journey. Integrations moved and tested with a real new starter if you have one.

Week five: reconcile. Four counts, every discrepancy investigated as a physical object, unresolved items written down rather than deleted.

Week six: close the old account, once and not before.

The whole shape is about three months, of which the demanding parts are weeks minus six to minus four and week five. Everything else is waiting while processes drain, which is exactly what makes it safe.

What Getting This Wrong Costs

The direct cost is the devices. Eleven machines at a few hundred each is a real number and it arrives as a write-off nobody budgeted for.

The larger cost is the register, and it is permanent. A migration that loses assignment history leaves you unable to answer when a given machine was issued, how many times it has moved, and whether it is due for replacement. That information does not come back, and its absence shows up for years afterwards as refresh planning done on guesswork.

And there is the credibility cost of a second migration. A switch that goes badly makes the next one much harder to propose, which means a company that ends up with a poor fit after a difficult move tends to stay there for a long time. That is the real reason to spend a month overlapping rather than cutting over on a Friday: not because the month is cheap, but because getting this wrong closes off the option of fixing it later.

Ask it this way before you set a date. On the morning of the switch, how many devices will be in transit, in repair or awaiting collection, and who owns each one?

The Case for Not Switching

Half the value of a migration plan is that it tells you when not to run one. Switching costs in this category are high enough that a decision to stay is frequently correct, and it is worth testing properly rather than defaulting to a move because the renewal is coming.

If the complaint is price, re-scope instead. Dropping storage and redeployment, or limiting retrieval to your top three countries, changes the figure more than any negotiation will and carries no migration risk at all. You are deciding to do more yourself, which is an honest trade and reversible.

If the complaint is one country, solve that country. A specialist arrangement for a hard market alongside your existing platform is a legitimate structure. It costs a second relationship and avoids moving an entire fleet to fix a fraction of it.

If the complaint is service quality, escalate properly first. Ask for a different account contact, in writing, with the specific failures listed and dates attached. Vendors frequently fix this when it is raised as a formal concern rather than as grumbling, and a fixed relationship is much cheaper than a new one.

If the complaint is that nobody internally owns device logistics, a new vendor will not fix it. That failure travels with you, and the second arrangement will deteriorate the same way the first one did, on the same timeline.

But if the gap is capability or coverage, switch, and name the gap explicitly in the specification for the replacement. The commonest way a migration disappoints is repeating the original mismatch because nobody wrote down what was actually wrong.

The test that settles it: if the incumbent fixed the one thing you are unhappy about, would you still move? A no means re-scope or escalate. A yes means the relationship has run its course and the plan above is how to end it without losing hardware.

When You're Ready to Make the Move

Two things to have in place before you give notice, and neither depends on the incoming vendor.

A register you control, exported and checked. Full status, full history, row count verified against your own expectation. This is the artefact that makes the migration possible and it is yours regardless of what either vendor does.

A named owner with a timeline. Not a function. One person, with the two-month shape described above on their calendar, and the authority to decide what happens to the warehouse stock without convening anybody.

With those two, the migration is a month of administration. Without them it is how a company discovers, half a year later, that eleven machines are somewhere and nobody knows where.

A last suggestion worth more than it sounds. Write a short note at the end recording what happened: the dates, what you moved, what you wrote off, which integrations broke and what the reconciliation found. Half a page. Nobody will read it for two years, and then somebody will be planning the next migration and that half page will be the only account of how this one actually went, which is considerably more useful than anybody's memory of it.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements.