The short version. This is a reconciliation wearing the costume of an import. The file moves in minutes; establishing which of the records in it are actually true takes weeks, because your existing register has drifted and the migration is the first time anybody checks. Plan it as a data quality exercise with a cut-off date and a physical verification sample, and do not migrate assignment history as though it were fact when nobody has confirmed it in two years.
Why this is not an import
An import assumes the source data is correct and the task is moving it. Asset registers are almost never correct, because they are maintained by people under time pressure as a side effect of other work, and nothing in normal operation forces a check.
So the migration becomes the moment the drift surfaces. Devices listed against people who left. Serial numbers missing on a share of the fleet. Two records for the same machine because it was re-registered after a repair. Entries with no serial at all, created from a purchase order.
None of that is unusual and none of it is a failure of your team. It is what registers look like after a few years, and the migration is simply the first thing that ever audited it.
The five fields that actually matter
Most registers carry twenty columns. Five of them determine whether the new system is usable.
Serial number, because it is the only identifier that survives a change of holder, a repair and a rename. Records without one are nearly impossible to reconcile later.
Current holder, as a person rather than a department, with enough identity to match against your HR system.
Location or country, because it drives everything about retrieval and because it is frequently stale.
Status, meaning assigned, in stock, in transit, retired or lost, with a definition everyone agrees on.
Acquisition date, which drives refresh planning and depreciation and is often the easiest field to recover from purchase records if it is missing.
Everything else can be backfilled later. These five cannot, practically, once the old system is gone.
Run a verification sample before you trust anything
Take a random sample of around thirty records and physically confirm them. Message the listed holder and ask them to read back the serial number from the underside of the machine.
The proportion that comes back wrong is your register’s real accuracy, and it is the single most useful number in the project. Most companies are surprised by it in one direction or the other, and either outcome changes the plan.
If accuracy is high, migrate the history and move on. If it is poor, do not carry the bad data across, because importing it makes the new system inherit a credibility problem on day one and people stop trusting it before it has done anything.
Decide what happens to history
Three options, and the right one depends on that accuracy figure.
Migrate everything, appropriate when the register is in good shape. You keep assignment history and the continuity is genuinely useful for audit questions later.
Migrate current state only, which means every device gets a record showing where it is now, with no history behind it. Cleaner, faster, and you lose the ability to answer who held this in 2024.
Migrate current state and archive the old system’s export, which is the pragmatic middle and what most companies should do. The new platform holds verified current state; a dated CSV sits in storage for the rare historical question.
Whichever you pick, write down which one you chose and why, because somebody will ask in eighteen months.
The cut-off problem
Devices keep moving while you migrate. People join, leave and swap machines during the three weeks the project runs, and changes made in the old system after the export are invisible to the new one.
Set a cut-off date, announce it, and run a freeze on register changes if you can. Where a freeze is impossible, keep a manual log of every change after the cut-off and apply them to the new system at the end. That log is tedious and it is much cheaper than discovering a fortnight of untracked movements afterwards.
What to ask the incoming vendor
What import format they accept, and whether they will take a file with missing serial numbers or reject the whole row.
Whether they deduplicate on serial, and what happens when two rows share one.
Whether assignment history can be imported at all, since some platforms only accept current state and that changes your options above.
And what the export looks like coming back out, which you should ask on the way in rather than on the way out.
RemoAsset is our own product, so treat this as disclosure. It covers procurement and retrieval across 80+ countries with a Subscription tier published from $1,499 a year, and includes HRMS integration at that tier, which matters here because holder matching against your HR system is most of the reconciliation work. Its limits: it enrols devices but is not an MDM in its own right, it wipes devices but is not a certified ITAD, and coverage and lead times vary by market.
How to run it
Export and sample first. Thirty records physically verified before any decision about history.
Fix the five fields on the current-state rows, and accept that the rest can be backfilled.
Set and announce a cut-off, with a manual log for anything that moves after it.
Reconcile at the end, not at the start, and keep the old export archived with a date on it.
How long does an asset register migration take?
The file transfer takes minutes and the project takes weeks, because the work is reconciliation rather than import. Expect two to four weeks for a few hundred devices, most of which goes on verifying holders, recovering missing serial numbers and deciding what to do with records that cannot be confirmed. Companies that budget for an import and discover a reconciliation are the ones whose migrations run over, so plan it as a data quality exercise from the start.
Should I migrate assignment history?
It depends on how accurate your register actually is, which you should measure before deciding. If a verification sample comes back largely correct, migrate the history because the continuity is useful for later audit questions. If it comes back poor, do not carry it across, because the new system inherits a credibility problem on day one and people stop trusting it before it has proved anything. The middle path is migrating verified current state and archiving a dated export of the old system.
What do I do about records with no serial number?
Try to recover them first, since the serial is the only identifier that survives a change of holder, a repair or a rename, and a record without one is close to impossible to reconcile later. Purchase records and supplier invoices often hold them. Where recovery fails, decide explicitly whether to migrate the row as an incomplete record or to leave it behind, and document which you chose. What causes problems is migrating them silently and discovering months later that a portion of the fleet cannot be matched to anything.
How do I check my register’s actual accuracy?
Take a random sample of about thirty records and physically verify them by asking the listed holder to read back the serial number from the underside of their machine. The proportion that comes back wrong is your register’s real accuracy rate and it is the most useful figure in the whole project, because it determines whether you migrate history or only current state. Most companies find the number surprising, and either direction changes the plan.
What happens to devices that move during the migration?
They get lost unless you plan for them, because changes made in the old system after the export are invisible to the new one. Set a cut-off date, announce it, and freeze register changes if your process allows. Where a freeze is impossible, keep a manual log of every movement after the cut-off and apply those changes to the new system at the end. The log is tedious and considerably cheaper than discovering a fortnight of untracked movements after go-live.
What should I ask a vendor before migrating in?
Which import format they accept and whether a row with a missing serial is accepted or rejected outright. Whether they deduplicate on serial number and what happens when two rows share one. Whether assignment history can be imported at all, since some platforms accept only current state and that constrains your options. And what the export looks like coming back out, which is far easier to establish while you are being sold to than during a later exit.
