You Acquired a Team and the Hardware Did Not Come With It: A Practical Guide for HR Teams Equipping People From Scratch

By [Author Name] · [Date] · [X] min read · [Table of Contents]

TL;DR

• Equipment for an acquired team is what you do when people transfer and their devices do not.
• It happens more than anybody expects, because hardware often sits with the entity being wound down rather than the people being hired.
• The work splits three ways: find out what they actually have, equip the gap, and decide whether to standardise now or later.
• Three patterns: clean break, partial transfer, and the one where nobody knows.
• Choose based on how much time you have before day one, not on how many people transferred.
• Done right it looks like a slightly busy onboarding week. Done badly it runs for two quarters.

Twelve engineers transfer on the first of the month. Four weeks beforehand somebody in legal mentions, in passing, that the laptops are assets of the acquired company and the acquired company is being dissolved. So the devices are not coming. Nobody had put that in the integration plan because nobody had thought to ask.

It happens repeatedly and in several shapes. A company buys a team and the hardware stays with the seller because it was leased. Another finds the devices do come across but are four years old, unmanaged, and configured for a domain that will stop existing. A third discovers that of fifteen machines, six belong to the company, five were bought personally by the people using them, and four cannot be accounted for by anybody.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

The real issue is not buying laptops. It's that an acquisition hands you a group of people who are already working, already productive, already in the middle of things, and you have to re-equip them without stopping the work they were acquired for.

When You Don't Actually Need to Change Anything

Stage one: the devices transferred and they're fine. Rare but real, usually with an asset purchase where the hardware was explicitly included and the machines are recent. Enrol them in your management system, update the register, and move on. The temptation to replace everything for consistency is expensive and nobody thanks you for it.

Stage two: friction appears. The machines are old, or they're the wrong platform for your estate, or they were managed by a system you don't run. Nothing is broken today and in six months three of them will fail at once. This is the stage most acquisitions actually sit in.

Stage three: it's a liability. Devices you cannot see, cannot update and cannot wipe, holding data belonging to a company that no longer exists, in the hands of people who now work for you. That's the state nobody chose and several companies end up in because the integration plan covered systems and not hardware.

Stage four: the hardware never came at all. Twelve people, day one, no machines. Operationally the clearest of the four, because the ambiguity is gone and it's just procurement at speed.

What HR Teams Actually Need from an Equipment Plan

> "Are the devices coming or not?" > Ask it explicitly, in writing, before the deal closes. > It falls between legal, IT and the seller, so it is nobody's named responsibility and routinely goes unanswered until too late.

> "How many people and where are they?" > The second number matters more than the first. > Twelve people in one city is a week's work. Twelve across six countries is a different project with customs in it.

> "What are they using right now?" > Ask the people, not the seller's register. > The seller's list will be out of date for exactly the reasons every register is out of date, and these people are about to leave so nobody is maintaining it.

> "Do we standardise immediately?" > Usually not on day one. > Equipping a team at speed and standardising a team are different projects, and attempting both at once delays the one that actually matters.

> "Who pays?" > Settle it before you order, because an unplanned hardware spend arriving after close is the thing that turns a procurement task into a political one.

There's a sixth question that only surfaces later. What happens to the old machines, the ones that did come across or the ones people own personally? Devices holding a dissolved company's data need handling properly rather than being left in a drawer, and the personally owned ones are a conversation rather than a process.

The Three Patterns and What Each One Costs

The clean break. What it is: no hardware transfers. Everybody gets new machines from you. When it's right: whenever the devices are more than about three years old, or the platform doesn't match yours, or the management system can't be transferred. Which is most of the time. When it fails: on timing. If you discover it four weeks out and your usual lead time into their markets is three, you have a week of slack and no room for a customs problem.

Partial transfer. What it is: some devices come, some don't, often split by who bought what. When it's right: when the recent machines are genuinely fine and replacing them would be waste. When it fails: on the register. A team split across transferred and new devices with two origins and two ages is the hardest thing to track accurately, and it stays hard for years because the record was never clean at the start.

Nobody knows. What it is: the seller cannot say what exists, who holds it, or what condition it's in. When it's right: never chosen, only inherited. When it fails: immediately and continuously. You're equipping people whose current state is unknown, so you will both over-order and leave somebody without a machine.

My recommendation is the clean break wherever the budget allows it, and the reason is not the hardware. It's the register. Starting with twelve known devices issued by you on a known date beats starting with twelve partially-known ones, and the difference compounds for the whole time those people work for you.

How to Choose What to Do: Five Questions

How long have you got? This governs everything else. Four weeks into familiar markets is comfortable. Four weeks into markets you've never shipped to is not, and the honest answer may be that some people start on a temporary machine.

Where are these people? Count countries, not heads. An acquisition that brings three people in Poland, two in Brazil and one in Singapore is a logistics project regardless of the total being six.

What do they actually have? Ask them directly, in a short form that takes two minutes. Model, age, who owns it, whether it works. You'll get better data than any register will give you, and you'll get it in about three days, which is faster than the seller's own list will arrive.

Is anything leased? Leased devices are usually the ones that don't transfer, and finding out late is how a clean break becomes an emergency. Ask the question specifically rather than hoping it falls out of the asset list.

Does the platform match? A team on one platform joining an estate on another is a decision, not an accident waiting to be corrected. Making it on day one, when everybody is already unsettled and learning three new systems at once, is usually worse than making it at the first refresh.

Six Platforms Worth Knowing

RemoAsset Best for: equipping a whole team at once across several countries, with the register correct from the first device. Why companies choose it: procurement and delivery across 80+ countries with each machine recorded against a person and a date at the point of issue, which is the thing an acquisition most needs and most often lacks. Pricing is published: 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. It's our own product, so weigh that accordingly. Where it struggles: no network discovery, which matters more here than usual, because the machines the acquired team already holds are invisible to it and finding those is a people exercise. No software licence management, so the acquired team's application estate is a separate problem. And only the Subscription tier publishes a figure, with pay-as-you-go quoted.

Workwize Best for: equipping at volume where stock needs to be held ready. Why companies choose it: own warehouses, so a batch order has somewhere to stage. Where it struggles: publishes no rate card. The figures on its pricing page are savings claims rather than prices. Live domain is goworkwize.com.

Firstbase Best for: speed on a batch of new machines. Why companies choose it: strong supply side and a clean subscription model. Where it struggles: no published price, and retrieval is the weaker half, which matters if the old devices also need collecting.

GroWrk Best for: acquisitions that bring people in markets you don't currently serve. Why companies choose it: flexible arrangements rather than a fixed package. Where it struggles: publishes no rate card, and its pricing page runs a competitor cost estimator whose figures are its own estimates.

allwhere Best for: handing the whole logistics problem over during an integration that already has enough moving parts. Why companies choose it: managed service, low internal lift. Where it struggles: publishes nothing, so comparison requires a conversation.

Deel IT Best for: acquisitions where the employment arrangement is also going through Deel. Why companies choose it: hardware alongside employment, with MDM and support included, and its own page claims coverage above 130 countries. Where it struggles: publishes no price for IT, and its own page states both 130+ and 150+ countries without reconciling the two.

The Decision Table: What Actually Needs Deciding

Most acquisitions land in rows one, two or five.

Ask the People, Not the Seller's Register

This is the recommendation that saves the most time and it's the one most often skipped, because asking the seller feels like the correct channel.

The seller's asset register has the same accuracy problem every register has, with one addition: the people who maintained it are leaving and have no reason to update it. On top of that, an acquired company in the weeks before close is a stressed organisation where nobody's priority is reconciling hardware. So the list you get will be out of date. By how much, nobody can say.

The people, meanwhile, know exactly what they have. They are looking at it.

So send a short form to every transferring person, ideally in the week the deal is announced rather than the week before close. Four questions: what machine are you using, roughly how old is it, who bought it, and does it work properly. Two minutes to answer. Most of them come back within three days.

What comes back is usually more interesting than expected. Somebody will say their laptop has been failing to charge for a month. Two will turn out to be using machines they bought themselves. One will mention a second device nobody knew about. And you'll find the age distribution is wider than the seller's list implied, because the oldest machines are the ones most likely to be missing from a register.

Then compare that against the seller's list and use the difference as your actual plan. Where the two agree, trust it. Where they disagree, trust the person. Where the seller lists something nobody claims, treat it as missing rather than as a device you'll be receiving, because planning around a machine that never arrives is worse than ordering a spare.

One caution on wording. People transferring in an acquisition are already anxious, and a form asking about their equipment can read as the beginning of something. Say what it's for in the first line: we're making sure everybody has what they need on day one.

Standardising Can Wait, and Usually Should

There's a strong pull toward making everything consistent at the moment of acquisition, and the reasoning is sound. You'll never have a better excuse, everybody expects change, and a mixed estate costs more to support.

It's still usually the wrong call for day one, for three reasons.

The first is capacity. An acquisition is already consuming the attention of everybody involved, including the people being acquired, who are learning new systems, new processes and new colleagues in the same fortnight. Adding a platform change on top of that competes with the work.

The second is that it slows the thing that actually matters. If you decide everybody moves platform, you now need to re-equip people who already have working machines, which turns a twelve-device order into a twelve-device order plus a migration plus a retrieval. Day one gets further away, not closer.

The third is that it's reversible later. A machine reaching end of life gets replaced with whatever your standard happens to be at that point, with no argument, no project and no event anybody has to attend. Over three years the whole acquired estate standardises itself, for free, with nobody noticing.

What's worth doing on day one is narrower: get every device into your management system, get every device onto your register with a named holder, and get the platform decision written down even if you're not acting on it yet. Visibility and a decision, not uniformity.

The exception is security. If the acquired machines cannot be brought under management, cannot be updated, or cannot be wiped remotely, that's not a standardisation question and it does not wait. Replace those, or bring them under control, before anything else on the list.

The Devices That Did Come, and What to Do With Them

Worth a section because this is the half most plans ignore entirely.

If some machines transfer, they arrive holding the acquired company's data, configured against the acquired company's systems, and often still enrolled in a management platform you have no access to. Each of those is a separate job.

Enrolment first. A device you cannot manage is one you cannot patch, which within months becomes the weakest point in your estate. If the previous platform can hand over, do that. If it can't, a wipe and rebuild is the honest option, and it's better done in week one when people expect disruption than in month four when they don't.

Then the data. The acquired company's files, accounts and credentials sit on those machines and some of it may not be yours to hold. That's a question for whoever handles data protection in your organisation rather than for an equipment policy, and it needs asking before the machines are casually folded into normal use.

Then the register. Each transferred device needs a serial, a holder and a date, and the date should be the date it came to you rather than an invented purchase date. Marking them as transferred rather than issued keeps the distinction visible, which matters at the first refresh planning round.

And finally the ones nobody can account for. There will be some. Record them as missing with the detail you have, rather than leaving them off the list, because a known gap is manageable and an unknown one surfaces during the next audit as a surprise.

The Personal Devices Question

A specific case that comes up in most acqui-hires and has no clean technical answer.

In smaller acquired companies, particularly ones that grew quickly or were short of cash at some point, some people will have bought their own machines and been using them for work. Sometimes they were reimbursed, sometimes partly, sometimes not at all. The company may or may not have a record.

Three things follow. The device belongs to the person, so you cannot wipe it, enrol it or take it. Your company data is on it, which is a problem that doesn't go away by not looking at it. And the person has usually been working this way for years, may prefer to continue, and has no particular reason to think the arrangement is anybody's problem.

The clean resolution is to issue a company machine and ask them to move their work to it, then confirm that the company data has been removed from the personal device. That's a conversation rather than an instruction, and it goes better if the new machine is good.

What to avoid is the middle state where the personal device stays in use indefinitely with your data on it and no agreement about any of it. That's the arrangement that becomes a problem at exactly the wrong moment, usually when the person leaves.

Whether any of this is permissible, what can be asked of somebody about their own property, and what obligations attach to data on a personal device all depend on jurisdiction and circumstances. Get local advice rather than applying one policy everywhere.

Where Jurisdiction Comes In

Several things in an acquisition are not equipment questions and should not be settled as though they were.

What transfers when a team transfers, what happens to the acquired company's obligations, who holds what afterwards, and how any of it works for the people involved all differ by jurisdiction and by the structure of the deal. That needs advice in each market, not one answer applied everywhere.

The same applies to data. What you may hold, what must be removed from a transferred or personal device, and who is responsible for it are questions for whoever handles that in your organisation.

What's portable is everything else on this page. Ask the people rather than the register. Count countries rather than heads. Get the lease question answered early. Don't standardise on day one. Enrol or replace anything you can't manage. None of that needs legal advice, and all of it determines whether twelve people can do their jobs on the Monday they become yours.

The Four-Week Sequence, in Order

The advice above is a set of principles. Here's what the four weeks between finding out and day one actually look like, because the order matters more than any individual step.

Week one: establish the facts. Get the hardware question answered in writing, including whether anything is leased. Send the four-question form to every transferring person. Ask for the seller's register, knowing you'll use it as a cross-check rather than a source. And count the markets, because that's the number that determines whether the remaining three weeks are enough.

Week two: order. This is earlier than feels comfortable and it's the right call, because lead time is the only constraint you cannot negotiate. Order against the form responses rather than waiting for perfect information, using your standard build for each role. If two or three responses are still outstanding, order for those people anyway on the assumption that they need a machine, because an unused laptop is a much smaller problem than a missing one.

Week three: handle the exceptions. By now you know who's in a difficult market, who has a personal device, who has something unusual that the standard build doesn't cover, and which transferred machines need enrolling or wiping. Three or four conversations, each specific.

Week four: confirm and communicate. Check every order has a tracking position and a delivery address that's still current, because addresses change during acquisitions more than you'd expect. Then tell each person what's arriving, when, and what to do with whatever they currently hold. That last message is the one most often skipped and the one people most remember.

Two things to deliberately not do inside the four weeks. Both are tempting. Don't attempt a full inventory of what the acquired company owns; you're establishing what people hold, which is a different and much faster question. And don't make the platform decision, because you can make it at the first refresh with better information and no time pressure.

If the four weeks is actually two, compress by skipping the register cross-check entirely and ordering on the form responses alone in the first few days. The cross-check is useful and it is not worth a day of lead time.

I'd run week two before the responses are complete rather than after. On one 17-person transfer the last three forms arrived on day 19 of 28, and ordering for those people on day 9 anyway is what made the deadline.

What to Tell the People Transferring

Equipment communication during an acquisition is unusually sensitive and it's usually an afterthought, which is a shame because it's one of the cheapest ways to signal competence at exactly the moment people are assessing you.

The people transferring are, reasonably, uncertain about a lot of things. In that context a clear, specific, slightly boring message about their laptop does disproportionate work: it's evidence that somebody has thought about the details, which implies somebody has thought about the larger things too.

So send two messages rather than one. The first, in week one, is the four-question form with a sentence explaining that it's so everybody has what they need on day one. The second, in week four, tells each person individually what's arriving, roughly when, to which address, and what happens to the machine they're currently using.

That last element is the one that matters most and gets omitted most. Somebody holding a laptop belonging to a company that's being dissolved genuinely does not know whether they're supposed to keep it, return it, wipe it or ignore it, and in the absence of instruction they'll do nothing, which leaves company data on a machine nobody is tracking. Tell them plainly. Keep using it until the new one arrives, then here's what to do with the old one.

Avoid two things in the wording. Don't describe the new equipment as an upgrade, even if it is, because it reads as a comparison with what they had and some people liked what they had. And don't make it conditional on anything administrative, because a message saying equipment will follow once paperwork is complete creates a worry that wasn't there.

If something is going to be late, say so with a date and an interim arrangement. People mid-acquisition handle bad news considerably better than they handle silence, and a laptop arriving a week after day one with advance warning is a non-event, while the same delay unannounced is evidence of chaos.

The Register Debt You Are About to Take On

Worth a section on its own, because this is the cost that lasts longest and it's invisible during the four weeks when you could still prevent it.

Whatever state your asset register ends the acquisition in is roughly the state it stays in. Permanently. There's no natural later moment to fix it: the integration ends, attention moves, and the twelve or forty entries created in a hurry become permanent. Three years later somebody planning a refresh is still guessing about them.

Three specific debts get created if the four weeks are rushed.

The first is the issue date. Machines arrive with none, or with the acquisition date standing in for a purchase date. That breaks refresh planning for those devices permanently, because you cannot tell a two-year-old machine from a four-year-old one. Record the real age if you can establish it, and mark it as estimated if you can't, which is more useful than a confident wrong figure.

The second is transferred devices entered as issued. A device you bought and a device you inherited are different things: different age, different warranty position, different disposal route, and often different condition. One extra field distinguishing them costs nothing at entry and cannot be reconstructed afterwards.

The third is the unaccounted machines. There will be some the seller listed and nobody claims. The instinct is to leave them off the register, because recording something you don't have feels wrong. Record them as missing with the serials you have, because a known gap is something you can close later and an unknown one surfaces during an audit as a surprise.

The cheap version of all three is one spreadsheet column added before you start entering anything: origin, with values of purchased, transferred or unaccounted. That single column is the difference between a register you can plan from and one you have to apologise for.

The Second Acquisition, and What Carries Over

Companies that acquire once usually acquire again, and the second one is where the cost of improvising the first becomes visible.

Three things carry over and are worth capturing while the first is still fresh, which is the fortnight after day one rather than six months later.

The diligence question, in the exact words that got an answer. Copy it verbatim. Something like: does any hardware transfer with the team, is any of it leased, and who is the named person who can confirm that. Those three clauses took somebody a week to extract the first time and they go into the checklist in one line.

The form, with whatever wording actually produced replies. Response rates to that four-question form vary enormously with the framing, and the version that worked is worth keeping verbatim rather than rewritten.

And the markets you learned to ship to. The single most expensive part of a first acquisition into an unfamiliar country is working out how, and that knowledge is immediately reusable. Record the route, the lead time you actually experienced rather than the one you were quoted, and anything that surprised you at customs.

What does not carry over is the timeline. Every acquisition has a different gap between finding out and day one, and the plan that fitted four weeks does not compress to two by doing the same things faster. What compresses is the register cross-check and the exception handling; what does not is the lead time.

One more thing worth recording while you remember it. What you got wrong. The address that was out of date, the person whose form never came back, the machine nobody could account for. That list is short, specific and more useful to the next person than any process document, and it stops being writeable about three weeks after the integration ends.

The Cost of Getting This Wrong

The direct cost is visible and recoverable: a batch of laptops, ordered late, possibly at a worse price because there was no time to shop. Unpleasant on a budget line and genuinely not the expensive part.

What costs more is the first impression. People transferring in an acquisition are already wondering whether they've landed somewhere competent, and arriving on day one without a working machine answers that question in a way nothing later quite corrects. I've seen that single detail cited by somebody resigning nine months after a transfer, and the laptop was not really the point.

Second is the register. That is the cost that lasts. A team whose devices entered your estate partially documented stays partially documented, because there's never a natural moment to fix it. Every subsequent audit, refresh plan and departure involves somebody guessing about those twelve machines. That's three to five years of small friction from two weeks of haste.

Third is the unmanaged device, which is a risk rather than a cost until it isn't. A machine you cannot patch or wipe, holding your data and a dissolved company's, in a market you have no presence in, is the sort of thing that looks fine for two years.

So the question worth asking isn't how fast you can get laptops. It's whether anybody has confirmed in writing whether the existing ones are coming.

When You're Ready to Move Beyond Handling It Ad Hoc

Most companies handle their first acqui-hire by improvising, and that's fine. The signal that it needs a process is the second one, particularly if it brings people in markets you haven't shipped to before.

What a process looks like here is short. A question in the diligence checklist about whether hardware transfers and whether anything is leased. A standard two-minute form that goes to transferring people the week of the announcement. A decision rule about what you keep, which is roughly anything under two years old on a platform you support. And a standing position that standardisation waits for the first refresh, unless the device cannot be managed, patched or wiped, in which case it is replaced immediately.

That's four things and they fit on a page. The value is that the lead-time question gets asked while there's still time to act on the answer.

RemoAsset is our own product. So apply the appropriate scepticism. The part relevant to an acquisition is narrow: getting a batch of machines to people in several countries at once, with each one recorded against a person and a date from the moment it ships, which is the register you'd otherwise spend a year reconstructing. It has no network discovery, so the devices the acquired team already holds stay invisible until somebody asks them, and no software licence management.

If you're in diligence on an acqui-hire right now, the single most useful thing you can do this week is get the hardware question answered in writing.

Frequently Asked Questions

Get the hardware question answered while there is still time to act on the answer.