Telling People Their Laptop Is Being Replaced

Telling people their laptop is changing

Whatever the message says, the reply contains the same three questions. Answer them in the message and you remove most of the thread.

When exactly? People have deadlines. “During Q2” is not an answer, it is a worry with no end date. Give the day.

What happens to my files? Specifically, what moves automatically, what they have to move themselves, and what is simply gone. The third category is the one that generates complaints.

What do I lose? Browser tabs, local tooling, saved passwords, that script in a folder nobody backs up, the particular way their terminal is set up. These are small and they matter, and pretending they do not is why refresh communications go badly.

Why the framing is wrong by default

Internally this is an upgrade with a budget attached. Externally it is somebody taking away a machine that works and that they have spent two years configuring.

Lead with the second reading. “Your laptop is being replaced on the fourteenth, here is what that means for you” lands better than “good news, new hardware”, because the second one is answering a question nobody asked.

What the message should contain

Six lines, in this order. Longer than that and the important part gets skimmed.

The line most people leave out

Line four. Teams describe what the migration covers and go quiet about what it does not, because the gap is awkward.

Name it anyway. Local files outside the synced folders, anything installed without administrative rights, locally stored credentials, virtual machines, container images. Saying these are not transferred, with a date by which the person should handle them, costs one sentence and prevents the conversation that starts “nobody told me”.

Announce the programme once, then go individual

One company-wide note explaining that a refresh cycle exists, what the interval is, and how people will be told. Then an individual message per person with their own date.

The combined version fails in both directions: a company note with no personal date generates anxiety, and a personal note with no context reads as if something is wrong with their machine specifically.

Give them two machines for two days

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.

The single most effective change available here is not a better message. It is overlapping the two devices.

A same-day handover means the person stops work, migrates, discovers something missing, and cannot get it because the old machine has gone. Two days of overlap turns every one of those discoveries into a two minute fix.

It costs you two days of holding one extra device per person, staggered across the programme, which is a small inventory cost against a visible drop in support load and complaints.

What to ask for at the end of the overlap

A confirmation from the person that they have what they need, before collection is booked. One line, and it converts the return from something being taken to something being released.

That matters practically as well as emotionally: the commonest cause of a machine sitting uncollected for months is that the person was not sure they were finished with it, so they quietly kept it.

Once the confirmation exists, the collection should be immediate rather than scheduled vaguely. Collection with packaging and a courier arranged is the mechanism that makes a booked date realistic, and the limitation worth stating is that it cannot generate the trigger. The confirmation step is yours.

Then say what happens to the old one

People ask, and the answer builds more goodwill than anything else in the process. Say whether it is wiped and reissued, resold, or disposed of, and say that the wipe is documented.

Where data protection frameworks such as the consolidated text of the General Data Protection Regulation apply to what was on the machine, a documented erasure against a standard such as NIST Special Publication 800-88 on media sanitization is both the correct handling and the specific reassurance people are asking for when they wonder what happens to their old laptop.

The decision table

When somebody says no

Occasionally a person simply does not want the new machine. It is worth understanding why before treating it as resistance, because the reasons are usually practical.

Three come up repeatedly.

Timing. They are mid-project and cannot lose two days. This is almost always reasonable and almost always solvable by moving the date, so move it rather than arguing.

A specific dependency. Something on the old machine that nobody can reproduce, often an old tool, a licence tied to hardware, or a build environment assembled over years. This is a real risk and needs a technical conversation rather than a policy one.

The new machine is worse for their work. Sometimes true, particularly where a standard specification was set for the majority. Worth hearing, because it is the same signal as an upgrade request arriving from a whole team.

Where to hold the line

On machines past end of support. A device no longer receiving security updates is a different conversation, and the right framing is that it is being retired rather than upgraded.

Say that plainly, give a date, and offer whatever help makes the dependency problem solvable. For the backlog of machines in exactly that position, our guide to answering an upgrade request covers the opposite direction of the same conversation, and the two policies should agree with each other.

Record the refusals

Not to police them. Because a pattern of refusals from one team is information about the standard specification, and three people with the same irreproducible dependency is a documentation gap worth closing before the next cycle.

One thing to measure afterwards

How many days elapsed between the new machine arriving and the old one being collected. Not satisfaction, which nobody answers honestly, and not ticket volume, which measures your support team rather than the process.

That one number tells you whether the overlap length is right, whether the confirmation step is happening, and whether people felt finished. When it starts stretching past a fortnight, something in the message stopped being clear, and it is usually line four.

Frequently asked questions

PeopleOpsHQ covers the operational side of distributed work. We describe suppliers with their limitations stated, and we take no vendor money.