It’s a data problem. Switching equipment platforms simply wears a procurement costume while it happens. The new vendor will onboard you happily. The question nobody asks early enough is what the old one will actually hand back, and in what shape.

TL;DR

  • Ask what you get on exit before you sign with anybody, not when you’re leaving.
  • A device list is not an asset history. The second is what you actually need.
  • Serial numbers, holders and dates are the three fields that must survive the move.
  • Run both platforms in parallel for a period rather than cutting over on a date.
  • Devices in transit during the switch are where records get lost.
  • Expect to lose some history. Decide in advance what you can live without.

What you actually need to move

Less than people fear and more than most exports provide.

Three fields. A serial number that identifies the machine, the person currently holding it, and the date they were issued it. With those three you can rebuild everything else over time. Without the serial you have a list of laptops rather than a register, and without the issue date you can’t answer a refresh question.

Useful but survivable losses: purchase price, supplier, warranty end date, previous holders, repair history. Nice to keep and not worth delaying a migration over, because most of it can be reconstructed from finance records or simply allowed to start fresh.

So the question to put to any vendor is narrow. Can you export serial, current holder and issue date for every device, in a machine-readable file, on request?

Ask on the way in, not on the way out

Here’s the timing point that costs people most, and it’s entirely avoidable.

Asking a vendor what happens to your data when you leave is a comfortable question during a sales process and an uncomfortable one during a notice period. The answer you get is also better, because at the point of sale they want to reassure you and at the point of exit they have no particular incentive to make it easy.

Get it in the contract if you can. A sentence specifying the fields, the format and the timeframe for an export on request costs nothing to agree at signing and is close to impossible to negotiate afterwards.

What to do:

  • Ask the exit question during the sales process, every time.
  • Specify serial, holder and issue date as a minimum.
  • Request the export format in writing: a spreadsheet or an API, not a PDF.
  • Test the export once while you are still a happy customer.

Run both for a while

A clean cutover date sounds tidy and creates a gap. Parallel running is messier and loses nothing.

The reason is devices in motion. On any given day some machines are in transit to new starters, some are coming back from leavers, and a few are in repair, and those are exactly the records that fall between two systems when one stops and the other starts. A device that left the old platform’s warehouse on Tuesday and arrives after the new platform went live on Wednesday belongs to neither record unless somebody is watching.

So stop new orders on the old platform first, let everything in flight land, and only then switch the record. Four to six weeks of overlap covers most movement, and the overlap costs a month of one subscription against the cost of reconstructing a dozen lost records.

A company that lost nine records

A 237-person company moved platforms on a fixed date because the old contract ended and nobody wanted to pay for an extra month.

The export arrived and looked complete. What it didn’t contain were the 9 devices that had been dispatched but not yet delivered when it was generated, because the old system counted them as in transit rather than issued and the export filtered on issued. Nobody noticed for five months, by which time the holders had changed in two cases and one machine had gone missing entirely.

Ask specifically what state filter an export applies. An export of issued devices isn’t an export of your devices.

Reconcile after the move, not before

Everybody wants to clean the data first. It’s the wrong order and it delays things by months.

Move what you have, flag what you doubt, then reconcile in the new system where you have working tooling and a reason for people to engage. Cleaning first means doing the slow confirmation work twice, once in a system you’re leaving and again when something has changed in the interim.

Mark unverified records as unverified rather than deleting them. A record you doubt is more useful than no record, provided nobody mistakes it for confirmed.

Where we fit

RemoAsset is our own product. It covers procurement and retrieval across 80+ countries with each device tracked from issue through return, from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges.

Three limits, and the first is directly relevant to a migration. It has no network discovery, so anything missing from the file you import stays missing until a person confirms it exists. It has no software licence management. And only the Subscription tier publishes a figure, with pay-as-you-go quoted on request.

Workwize, Firstbase, GroWrk, allwhere, Esevel and Deel IT all accept migrations and none publishes a rate card. Ask every one of them the same export question before signing, including us.

Checklist

Checklist:

  • The exit export question asked during the sales process, not at notice.
  • Serial, current holder and issue date confirmed as exportable.
  • The export’s state filter understood, so in-transit devices are included.
  • Four to six weeks of parallel running, with new orders stopped first.
  • Unverified records flagged rather than deleted.
  • Reconciliation scheduled after the move, in the new system.

Final Thoughts

The hard part of switching platforms isn’t choosing the new one. It’s that your asset history lives inside the thing you’re leaving, and how much of it survives was decided when you signed the original contract.

So ask on the way in. Three fields, a format, a timeframe, written down while everybody is being helpful. And when you do move, let the devices in flight land before you switch the record, because those are the ones that quietly disappear.

Frequently asked questions

What data do we actually need to migrate?

Three fields per device as a minimum: the serial number, the current holder, and the date it was issued. With those you can rebuild everything else over time. Purchase price, supplier, warranty dates and repair history are useful but survivable losses, and most can be reconstructed from finance records if you need them later.

When should we ask about data export?

During the sales process, before signing with anybody. The answer is both easier to obtain and more generous when a vendor is trying to win you than when you have given notice. Get the fields, the format and the timeframe written into the contract, because that sentence costs nothing at signing and is close to impossible to negotiate later.

Should we cut over on a single date?

No. Run both in parallel for four to six weeks instead. Devices in transit, coming back from leavers or in repair are the records that fall between two systems when one stops and another starts. Stop new orders on the old platform first, let everything in flight land, and only then move the record across.

What goes wrong with exports most often?

A state filter nobody asked about. An export of issued devices will quietly omit anything the system counts as in transit, which can be a dozen machines on any given day, and the file looks complete because nothing indicates what was left out. Ask explicitly which device states the export includes.

Should we clean the data before migrating?

No, move it and reconcile afterwards. Cleaning first means doing slow confirmation work in a system you’re leaving, and then repeating it when things change in the interim. Move what you have, flag the records you doubt as unverified rather than deleting them, and reconcile in the new system where you have working tooling.

Will the new platform find devices missing from the file?

Generally not. Logistics platforms know about devices they have handled, so anything absent from your import stays absent until a person confirms it exists. That makes the migration a people exercise as much as a data one, and it is worth setting a cut-off date after which unconfirmed devices are recorded as unknown.