TL;DR
Leavers get a process. People changing teams get an email and a new manager, and the laptop just carries on. That is why internal moves damage an asset register more than departures do: nothing triggers, nobody checks, and the record quietly stops matching reality.
- An internal move has no trigger in most systems. That is the whole problem.
- Four records change: owner, cost centre, access groups and device tier.
- Keep the machine by default. Swap only when the specification genuinely differs.
- The cost centre is the one finance will chase you about in nine months.
- A move is the cheapest moment to catch a register error, so use it.
- Promotions are moves too, and they are the ones people expect kit for.
Why changing teams breaks the register
A departure fires events everywhere. Payroll changes, access is revoked, somebody chases the laptop, and the asset record closes.
An internal move fires almost nothing. The person keeps their account, their machine and their building pass. One field changes in the people system and that is usually the end of it.
So the asset register keeps saying the device belongs to a team the person left eighteen months ago, and nobody notices until a reconciliation or a budget review.
What that costs in practice
Three things, none of them dramatic and all of them annoying.
Finance sees device costs sitting against the wrong cost centre, so team budgets are wrong in both directions. The receiving manager has no idea what their team is actually holding. And when the person eventually leaves, the retrieval request goes to somebody who stopped managing them two roles ago.
That last one is the expensive version, because a collection that goes to the wrong manager is a collection that does not happen.
The four records to change
Keep the list short enough that it survives contact with a busy week.
| Record | Why it matters | Who usually owns it |
|---|---|---|
| Assigned owner | Who gets chased at the end | IT or the asset register |
| Cost centre | Whose budget carries the device | Finance |
| Access groups | What the person can still reach | IT or security |
| Device tier | What they are entitled to next refresh | IT policy |
Three of those four are administrative. The access one is not, and it is the one most often skipped because it needs somebody to decide what the person should lose rather than simply what they should gain.
Access is a subtraction problem
Moves tend to be handled as additions. The person joins the new team’s groups and keeps the old team’s groups, because removing access requires knowing what they no longer need and nobody wants to be the person who broke something.
Over a few years that produces people with accumulated access that matches no current role, which is a recognised control failure under management standards such as ISO/IEC 27001, the information security management standard and a practical risk whatever framework you use.
The fix is a default rather than a judgement: old team access is removed after a stated handover window unless the receiving manager asks for it to stay, and the request is recorded. the UK National Cyber Security Centre device security guidance makes the same point about reviewing what a device and its user can reach rather than only what they were originally given.
Swap the machine, or keep it
Disclosure: RemoAsset, named below, is owned by the same people who publish PeopleOpsHQ. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money.
Default to keeping it. A move is not a refresh, and swapping working hardware because somebody changed reporting line is a cost with no benefit attached.
Three situations genuinely justify a swap.
The specification no longer fits. Somebody moving from a support role into engineering may need a different class of machine, and moving the other way may free up a better one.
The operating system is wrong for the new work. Teams standardised on different platforms make this real rather than cosmetic.
The device is already near end of life. A move is a convenient moment to bring a refresh forward by a few months, since the person is already adjusting to change.
Everything else is a keep. If the machine works and the specification fits, changing it creates a shipment, a setup, a migration and a returned device for no gain.
When you do swap, the old machine matters
An internal swap leaves a working device in somebody’s house. That is the moment the chain usually fails, because unlike a departure there is no leaving date forcing the issue.
Collection needs a date attached to it or the machine sits for a year. Where that collection is arranged with packaging and a booked courier, it happens; where it means the person finding a box themselves, it does not. Device collection with packaging arranged covers that mechanism, and the limitation to state is that no logistics service will tell you a swap happened. The trigger has to come from your own move process.
Whatever the device’s next step, data handling still applies. Where a machine is being redeployed to somebody in a different team, a documented wipe against a standard such as NIST Special Publication 800-88 on media sanitization is the difference between a redeployment and an accidental data transfer.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Lateral move, same platform | Any | One standard tier | Records drift | Update the four records, keep the machine |
| Move into engineering | Any | Tiered kit | Specification gap | Swap, and recover the old machine |
| Promotion | Any | Entitlement by level | Expectation of new kit | Decide on specification, not status |
| Move across platforms | Any | Mixed fleet | Tooling mismatch | Swap, plan the data migration first |
| Frequent internal mobility | 200 plus | No move trigger | Register never accurate | Hook the asset update to the people system |
Making the move trigger itself
A checklist nobody runs is the same as no checklist. The only version of this that survives is one hooked to something that already happens.
The people system is the hook. A team or manager change in there is the one event guaranteed to be recorded, because payroll and reporting depend on it. Everything else is optional and therefore skipped.
Three ways to use it, in order of effort.
A monthly report. Anybody whose team changed last month, compared against the asset register’s owner field. Differences get fixed. This is an hour a month and catches most of it.
A notification. The move generates a task for whoever owns the register. Better, and needs a small integration.
A genuine sync. The register reads owner and cost centre from the people system rather than storing its own copy. Best, and the only version that cannot drift, but it needs the two systems to agree on identity.
Most teams under 200 people should do the first one and stop there. The arithmetic does not justify an integration project for something a monthly report handles.
Use the move to check the record
A move is the cheapest possible audit moment. Somebody is already looking at this person’s details, so confirming the serial number of the machine they actually have costs one question.
Do it on every move and the register corrects itself gradually without a dedicated reconciliation exercise. That matters more than it sounds, because where personal data sits on a device, frameworks such as the consolidated text of the General Data Protection Regulation attach obligations to the data rather than to the hardware, and an accurate map of what is where is the thing that makes any response to a request possible.
For the adjacent question of what to do when the person asks for better hardware as part of the move, see our guide to answering an upgrade request. For the chain that gets a swapped machine back into service, storage and redeployment of returned devices is the piece most teams are missing.
See how a swapped machine gets collected and redeployed at storage and redeployment of returned devices, or read our guide to answering an upgrade request.
Frequently asked questions
Why do internal moves break the asset register?
Because nothing triggers. A departure fires events across payroll, access and retrieval, and the asset record closes. A move changes one field in the people system and leaves the laptop where it is. So the register keeps naming a team the person left, and nobody notices until a reconciliation or a budget review, by which point several moves have stacked up.
What records actually need changing?
Four. The assigned owner, so the right manager gets chased at the end. The cost centre, so the device sits against the right budget. Access groups, which is the one that needs an actual decision. And the device tier, which sets what the person is entitled to at the next refresh. Three are administrative and the access one is not.
Should the person get a new laptop when they move?
Default to no. A move is not a refresh, and replacing working hardware because somebody changed reporting line is cost without benefit. Swap when the specification genuinely no longer fits, when the new team runs a different platform, or when the machine was due for replacement anyway and the timing is convenient. Everything else is a keep.
Why is access the hardest part?
Because moves are handled as additions. The person joins the new team’s groups and keeps the old ones, since removing access means knowing what they no longer need and nobody wants to break something. Over a few years that leaves people with access matching no current role. A stated handover window with removal as the default fixes it better than case by case judgement.
What happens to the old machine after a swap?
It sits in somebody’s house, which is where the chain usually fails. Unlike a departure there is no leaving date forcing the issue, so collection needs a date attached or the device is still there a year later. Arranging packaging and a courier makes it happen; asking the person to find a box themselves does not.
How do we stop this needing a checklist nobody runs?
Hook it to the people system, because a team or manager change is the one event guaranteed to be recorded. A monthly report comparing team changes against the register’s owner field takes about an hour and catches most of it. A notification is better. A genuine sync cannot drift but needs the systems to agree on identity, and under 200 people the report is usually enough.
Does a promotion count as a move?
Yes, and it is the one where people expect new equipment, which makes it the awkward case. Decide on specification rather than status: if the work genuinely needs a different class of machine, swap it, and if it does not, the promotion is not a hardware event. Tying kit to seniority rather than to need is how equipment budgets drift and how exception requests start arriving.
PeopleOpsHQ covers the operational side of distributed work. We describe suppliers with their limitations stated, and we take no vendor money.
