Equipment When You Acquire a Company

TL;DR

• Equipment in an acquisition arrives as a fleet nobody can describe, and the register you were handed is almost certainly incomplete.
• Do not standardise in month one. Inventory, secure and establish ownership first, in that order.
• The urgent question is not what hardware they have. It is which devices hold data and which of them you now cannot account for.
• Leavers during a transition are the highest-risk group, because nobody owns their offboarding during the handover.
• Expect three populations: company-owned and managed, company-owned and unmanaged, and personal devices with access.
• Budget for a refresh you did not plan, because inherited fleets are usually older than the seller implied.

The Fleet That Arrived With a Spreadsheet

The asset list came over with the data room. Two hundred and six devices, serials, models, assigned names. It looked thorough and the integration team treated it as a starting point, which it was, just not in the way anybody expected.

Six weeks in, the real count was 237. The extra thirty-one were a mixture: machines bought on expenses that never entered the register, devices belonging to contractors who were not on the employee list the inventory was built from, and nine laptops still assigned to people who had left in the previous year and whose equipment had never been recovered. Two of those nine were unaccounted for entirely.

Nobody had misled anybody. The seller's asset list was an accurate record of what their asset process knew about, and their asset process had the same four failure modes every asset process has. The gap between that list and reality was the integration risk, and it was invisible until somebody counted.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

The real issue with equipment in an acquisition is not what you are inheriting. It is what the register you were handed does not know about.

Equipment in an Acquisition: the First Five Weeks

The sequence matters more than the speed, and the common error is starting with standardisation because it feels like progress.

Week one: establish the three populations. Company-owned and centrally managed. Company-owned and not managed. Personal or contractor devices with access to company systems. Every subsequent decision depends on which bucket a device sits in, and the third bucket is usually larger than anybody expects.

Week two: secure, do not standardise. Confirm encryption state, confirm you can reach the device if you need to, and confirm the access path can be revoked. A device you cannot revoke access from is the only genuinely urgent item on this list.

Week three: reconcile against people. Compare the device list to the actual employee and contractor list as it stands after the deal, not as it stood in the data room. This is where the unrecovered leaver devices surface.

Week four: establish ownership and lease position. Owned outright, leased, or on a device-as-a-service arrangement. Each has different implications and the paperwork is often less clear than the finance summary suggested.

Week five: now plan the refresh. With a real inventory and a real age profile, the standardisation conversation becomes a budget question with evidence rather than a preference.

When This Is Not Worth a Project

Under about 25 inherited people. Then it is an afternoon of asking everybody what they have, and a project plan is overhead. The honest version at that size is a shared document and two days.

A pure asset purchase with no staff. If nobody transferred, the equipment is stock rather than a fleet, and the question is disposal or redeployment rather than integration.

The seller ran a mature programme. It happens. If they can produce a dated inventory, a management platform export and leaver records that reconcile, verify a sample and move on. That verification is still worth a day.

You are selling the unit on again within the year. Then standardising is money spent on somebody else's estate, and the right posture is secure, document and leave the hardware alone.

What People Actually Need Answered

Will my laptop be taken away? The first question every transferring employee asks, and leaving it unanswered for six weeks generates more anxiety than any honest answer would. Even "nothing changes before March" is better than silence.

Who do I contact when it breaks? During a transition this is genuinely ambiguous, and the ambiguity means people stop reporting faults and work around them.

What happens to the software I rely on? Often a bigger concern than the hardware, and a question the equipment workstream gets asked regardless of whether it owns the answer.

Is anyone watching what I do now? Worth addressing directly. Introducing device management to a population that never had it is a legitimate change and it reads as surveillance if it arrives without explanation.

What about my own laptop? For anybody in the third population, this needs a specific answer rather than a general policy, because the honest answer may be that they need company hardware they have never had.

The Inventory You Build Yourself

The handed-over list is a starting point and should be treated as a hypothesis. Three sources together get you to something defensible.

The seller's asset register. Whatever exists. Treat every row as unverified until confirmed.

Their management platform export, if they had one. This is usually more accurate than the asset register, because it reflects devices that actually exist and check in rather than devices somebody recorded. The difference between the two lists is immediately interesting.

A direct confirmation from each person. Unglamorous and the only method that catches the expense-claim purchases and the second laptop in somebody's drawer. One message to every transferring employee asking what they have, with serial if they can find it.

What to do: build the union of all three, not the intersection. A device appearing in any source exists until proven otherwise, and the ones appearing in only one source are the rows worth investigating first.

Expect the union to exceed the handed-over list by somewhere between 10 and 20 per cent. That is normal and it is not evidence of anything untoward; it is the ordinary gap between an asset process and reality, which we cover in why asset registers go wrong.

Data Handling, Which Is the Part With a Deadline

Of everything in this article, this is the only workstream with a genuine clock on it, and it is worth separating from the hardware questions.

Establish what is on the devices, roughly. Not file by file. By category: customer data, financial records, source code, personnel information. The categories determine how urgently an unmanaged or unaccounted-for device matters.

Identify the devices you cannot account for. The two missing laptops in the opening story are the whole reason this is week one work rather than month three. A device you cannot locate, holding data in a category that matters, is a decision that needs making rather than a line on a register.

Decide and record what you concluded about each. Whether the data was encrypted, whether access has been revoked, whether the realistic risk is material. The record matters as much as the conclusion, because this is precisely the question an external reviewer asks after an acquisition and an undocumented judgement reads as no judgement at all.

Revoke before you retrieve. Access removal is immediate and within your control. Physical recovery is slow and often never completes. Teams that chase hardware before cutting access have the sequence backwards, and the reason matters: a device with no credentials on it is a hardware loss, while the same device with live access is an open door. The first is a write-off and the second is an incident, and which one you are dealing with is decided entirely by how quickly somebody disabled the account.

Get advice where the answer is legal rather than technical. Whether any particular situation requires notification to anybody, and what obligations attach to data in a given jurisdiction, varies by circumstance and is not something a general article can tell you. The honest position is that this differs by jurisdiction and by the facts, and it is worth a conversation with somebody qualified rather than an assumption.

What to do: a one-page note listing unaccounted devices, what category of data each likely held, what was revoked and when, and what you concluded. Produced in week one, dated. It takes an hour and it is the artefact you will be glad exists.

The Second Supplier Nobody Mentioned

Worth its own short section because it surprises people and because it is almost universal above a certain size.

Acquired companies frequently have more than one equipment supplier, and only one of them appears in the central finance picture. The others exist because a regional office needed something quickly, or because a team had a preferred reseller, or because an earlier acquisition brought its own arrangement that never got consolidated.

The symptoms are specific. Devices in the fleet that do not match any purchase record you were given. Invoices from a vendor nobody can identify. A region whose hardware is consistently a different model from everywhere else.

Why it matters. Each arrangement may have its own terms, its own lease schedule and its own exit conditions, and you cannot plan a refresh against contracts you have not seen. It also means your inherited fleet has more variety than the standardisation conversation assumed.

What to do: ask the question directly of the regional leads rather than of finance, because finance only knows about arrangements that went through finance. One message asking who they buy laptops from usually surfaces everything within a day.

The Leaver Problem During a Transition

This is the highest-risk area and it is caused by a gap in ownership rather than by anybody's negligence.

During a handover, the seller's HR function is winding down and the buyer's has not taken over. Somebody resigns in that window, and their offboarding falls between two processes. Equipment is the part most often missed, because it requires somebody to know the person had a laptop and to care enough to chase it.

What to do: name one person on each side, by name, responsible for equipment recovery during the transition period, and give them a shared list. This is a ten-minute decision that prevents the most common integration loss.

Treat pre-deal leavers as a separate exercise. The nine unrecovered devices in the opening story were all pre-deal. Recovery after six months is unlikely, so the realistic outcome is a documented write-off, and documenting it is what matters. A device quietly deleted from a register is a question somebody will ask later; a device written off on a date by a named person is a complete answer.

Set a cut-off and stop chasing. Open-ended recovery efforts consume attention indefinitely for a diminishing return. Pick a date, chase hard before it, write off after it. Six weeks from the transition is a defensible line for pre-deal leavers, and stating it in advance means nobody has to decide case by case when somebody inevitably asks whether it is worth one more email.

Three Populations, Three Different Answers

Company-owned and managed. The easy case. Confirm the posture, plan the refresh, carry on. Most of your inherited fleet should end up here.

Company-owned and unmanaged. The population that needs the most work. These devices hold company data and you cannot see their state or reach them. Enrolling them retrospectively is possible and is a different exercise from zero-touch provisioning, because the device is already in somebody's hands and in use. Expect to need their cooperation and a window.

Personal or contractor devices with access. Not an equipment problem at all. The control shifts from the device to the access, which means your directory rather than your asset register, and the honest answer is often that these people need issued hardware they have never had. Budget for it, because this is the population most likely to produce an unplanned purchase.

Why Not to Standardise Equipment in an Acquisition Yet

The instinct is strong and acting on it early is usually a mistake, for three reasons.

You do not yet know what you have. Standardising against an inventory that is 15 per cent short means ordering the wrong quantity and discovering the gap after the budget is committed.

It is the most visible possible change to a nervous population. Taking somebody's working laptop away in week three of an acquisition, to replace it with an equivalent machine in a different colour, is a cost with no benefit they can perceive. It spends goodwill you will want later.

The age profile decides the sequence, and you do not have it yet. Once you know that forty devices are within six months of end of life and a hundred and sixty have two years left, the plan writes itself and it is not a standardisation project, it is a staggered refresh.

What to do: standardise on the way in rather than by replacement. Every new hire and every refresh gets your build. The inherited fleet converges over the normal replacement cycle at no incremental cost, which for most acquisitions is the right answer.

Leases, Subscriptions and the Paperwork Nobody Read

Ownership is rarely as simple as the finance summary implies, and the detail matters because it constrains what you can do.

Owned outright. Simplest. You can redeploy, sell or dispose of devices as you choose, subject to data handling.

Leased. There is a schedule, an end date and usually a return condition. Replacing a leased device early may not save money and disposing of one may not be permitted. Find the agreements before planning any refresh.

Device-as-a-service or subscription. The commercial position is different again, and the contract may bind to headcount or to a term rather than to specific devices. Changing the arrangement mid-term may not be possible.

What to do: ask for the agreements specifically rather than for a summary, and read the exit terms before you plan anything. We have written about DaaS contract terms and about what you keep on exit, and the same discipline applies: the exit clause is the one that decides your options.

And check for a parallel arrangement you were not told about. It is common for one region or one team to have had its own supplier, with its own terms, invisible in a central finance summary.

Enrolling Devices That Are Already in Use

The unmanaged population needs bringing under management, and doing it to a device somebody is actively working on is a different exercise from provisioning a new one.

It requires their cooperation, so it requires an explanation. Enrolment on an in-use machine typically involves the holder doing something: installing a profile, restarting, entering credentials. People will do that willingly if they understand what it is and reluctantly or not at all if it arrives as an instruction from a company they have just been acquired by.

Say what it does and what it does not do. The honest version is usually that it lets you confirm encryption, push security updates and, if the device is lost, protect company data. If it also allows remote wipe, say so plainly, including the fact that a wipe would remove their data too if the device holds any. People discovering that capability later, by rumour, is considerably worse than being told.

Sequence it by risk, not alphabetically. Devices held by people with access to customer data or financial systems first. The rest can follow over a quarter.

Give people a window rather than a deadline. A two-week window with a reminder works better than a date, because the one thing guaranteed to produce resistance is a mandatory restart during somebody's busiest afternoon.

Expect a residual group. There will be devices that never get enrolled: people on leave, contractors ending soon, machines too old to support the tooling. List them, decide whether each is acceptable or needs replacing, and do not leave the list implicit.

What to do: write a short note covering what is being installed, what it can see, what it cannot see, and who to ask. Four paragraphs. The teams who skip this spend considerably longer handling the resulting questions one at a time, and in a population that is already uneasy the explanation is cheap insurance.

Building the Age Profile, Which Decides the Budget

Once the count is real, the age profile is the artefact that turns a vague standardisation wish into a costed sequence.

Get purchase dates, not model years. A model released in 2023 may have been bought in 2025, and the warranty and refresh clock runs from purchase. Where purchase dates are missing, serials will usually give you a manufacture date, which is a reasonable proxy.

Band them against your own refresh cycle. Due now, due within twelve months, due in one to two years, and beyond. Four bands is enough and more is false precision given the data quality.

Expect the profile to skew old. Capital spend commonly slows in the period before a sale, so the inherited fleet is frequently a year further through its life than a casual look suggests. Treat any age figure from the data room as optimistic and verify a sample.

Then cost the first two bands only. Devices due now and within a year are your actual budget ask. Anything further out is a planning assumption and putting it in a funding request invites a conversation you do not need yet.

One caution worth stating. A device being old is not on its own a reason to replace it if the holder is content and it is secure. Age-based replacement applied rigidly to an inherited fleet produces exactly the unnecessary, visible churn described earlier. Use the profile to budget and sequence, not as an automatic trigger.

What to Tell the Transferring Team, and When

Communication is the part of equipment in an acquisition that costs nothing and determines how the rest is received.

Week one: say that nothing is changing yet. Even if you do not know the plan, you know that much, and it answers the question everybody is actually asking. Silence gets filled with the assumption that laptops are being taken away.

Week two or three: explain the counting exercise. When you message everybody asking what hardware they hold, say why. A request for serial numbers with no context reads as an audit aimed at individuals rather than at a register.

When you enrol: explain the tooling. Covered above, and the single most important message in the sequence.

When you have a refresh plan: publish the sequence, not the policy. People want to know when their turn is, not what the standard build is. A named quarter is enough.

Always: say who to contact for a fault. The most practical message of all, and the one most often omitted because it feels too small to announce during a major transaction.

What to do: five short messages over a quarter, each answering one question, each from a named person. That is the entire communications plan and it prevents most of the friction that otherwise attaches itself to the equipment workstream.

What This Costs

Three costs, and only one of them appears in a deal model.

The refresh you did not plan. Inherited fleets skew older, because capital spend often slows in the year before a sale. Expect to replace more devices sooner than the age profile in the data room suggested, and treat any figure you were given as a floor.

The enrolment project for unmanaged devices. Not large per device and real in aggregate, and it requires the cooperation of people who are already managing a lot of change.

The hardware for the third population. Contractors and anybody who was using their own machine may now need issued equipment. This is the cost most often missed entirely, because that population does not appear on an asset register by definition.

The costs that do not materialise, and are worth not budgeting for: a standardisation programme in year one, and a data migration of the asset register itself, which is usually a rebuild rather than a migration and is cheaper than it sounds.

Where the Equipment Comes From During Integration

Acquisitions generate a burst of equipment demand at exactly the moment your own process is under strain, and in markets you may not have operated in before.

RemoAsset is one option for that, and disclosure matters: RemoAsset is owned by the same people who publish this site. It buys, registers, ships and later retrieves devices, which is useful during an integration specifically because the inherited population needs equipping in unfamiliar locations and because the records are created by the fulfilment rather than by somebody maintaining a register during a period when nobody has spare attention.

Where it struggles, stated plainly: pricing is quote-based and requires a demo, so it cannot be compared against alternatives on cost without a call; and it is a newer platform with a smaller footprint than the legacy global resellers, which is exactly the consideration that bites if the acquired company operates somewhere unusual. Ask specifically about the countries you have just acquired before assuming coverage.

It also does not solve the inherited-fleet problem. Nothing you buy will tell you what the seller's register did not know, and that remains a counting exercise somebody has to do.

The Decision Table

What Nobody Plans For and Should

Who answers equipment questions during the handover. Name one person on each side. Ambiguity here means faults go unreported for weeks.

What happens to devices for people who do not transfer. There is always a group who stay with the seller or leave, and their equipment needs a documented destination before the day.

The second laptop. A surprising number of people in acquired companies have two machines, usually an old one nobody collected. These only surface in a direct confirmation.

Keyboard layouts and regional variants. If the acquired company is in a different market, your standard build may be the wrong physical hardware, which turns a standardisation plan into a procurement problem.

Data on devices nobody can find. The two unaccounted-for laptops in the opening story are the whole reason to do this work in week one rather than month three.

Shared and loan devices. Most companies keep a few machines that belong to nobody: conference room laptops, loan units, a spare for visitors. They never appear against a person, so a people-based reconciliation misses them entirely and they often hold old data from whoever used them last.

Devices in transit on the day of the deal. Anything ordered and not yet delivered sits in a gap between two companies' records, and the delivery address may be an office that is closing. Ask what is on order before close rather than discovering it when a parcel arrives somewhere unexpected.

What Getting This Wrong Costs

The expensive version is not money. It is discovering in month four that you cannot account for devices holding company data, during a period when somebody external is likely to ask.

An acquisition commonly triggers a security review, a customer questionnaire or a compliance assessment, because the counterparty wants assurance about what just joined the estate. Being unable to say how many devices exist, how many are managed and how many are unaccounted for is a bad position, and it is entirely avoidable by counting in week one.

The second cost is goodwill, spent on the wrong thing. A standardisation programme in month two is the most visible, least valued change you can make to a population that is already anxious, and it consumes the patience you will need for the changes that genuinely matter.

And the third is the quiet one. Teams that never reconcile the inherited fleet against people carry the seller's unrecovered leaver devices on their register indefinitely, which means every subsequent count is wrong by the same margin and nobody knows why.

So the question about equipment in an acquisition is not what you have acquired. It is how much of it the register you were handed never knew about, and whether you have found out yet.

Merging the Registers, or Not

At some point the inherited records have to live somewhere, and the instinct to migrate them into your existing system is worth questioning.

A migration assumes the source is trustworthy. It is not, which you established in week one. Importing unverified records into your authoritative register contaminates something that was previously reliable, and afterwards nobody can tell which rows came from where.

So import with provenance, or rebuild. If you import, tag every inherited row with its source and its verification state, and keep that tag. If you rebuild, create records as devices are enrolled, refreshed or retrieved, and accept that the inherited fleet enters your register gradually rather than on a single day.

Rebuilding is slower and usually better. It means your register only ever contains records somebody confirmed, which is the property that makes it worth having. The inherited spreadsheet survives alongside as a reference document rather than as data.

Either way, keep the original. The handed-over list is evidence of what you were told at the point of the deal, and that is worth retaining separately from whatever you build. Store it with a date and do not edit it.

What to do: decide this explicitly in week four rather than letting it happen. The default, if nobody decides, is that somebody pastes the inherited spreadsheet into the main register to be helpful, and the provenance is lost permanently.

One practical note on reconciliation. If both companies used a management platform, compare the two exports before touching either register, because that comparison is the most accurate picture available of what actually exists. Devices present in a platform and absent from both registers are real and unrecorded, which is the most useful thing you can learn in the whole exercise.

When You're Ready to Start

Build the union of three sources in week one: their register, their management platform export, and a direct message to every transferring person. Expect the total to exceed the handed-over list and treat that gap as the finding rather than as an error.

Then secure before you standardise. Confirm you can reach and revoke, list what you cannot, and leave the hardware alone otherwise.

And name the two people responsible for equipment recovery during the transition, one on each side, before anybody resigns. That decision costs ten minutes and prevents the most reliable loss in any integration.

A closing thought on why this workstream gets underestimated. Equipment in an acquisition looks like a logistics task, which is why it tends to be assigned to whoever has capacity rather than to whoever has authority. It is actually three different problems wearing one label: a data-risk problem with a real deadline, a people-communication problem that shapes how the whole integration feels to the transferring team, and a budget problem that will not be understood until somebody counts. Only the third is logistics. The first needs somebody who can make a judgement and record it, and the second needs somebody the transferring employees will believe.

So resource it accordingly. The counting is a week of unglamorous work that anybody can do. The decisions about unaccounted devices, the explanation of why management tooling is being installed, and the funding ask for a refresh nobody budgeted for all need somebody with standing. Teams that treat the whole thing as an inventory exercise get an accurate register and a population that spent a quarter assuming the worst, which is a poor trade for work that was going to happen anyway.

Frequently Asked Questions