Back to Blog

IT Due Diligence When You’re Buying a Distributor, Not a Software Company

ERPInformation TechnologyLeadership

Last updated: October 14, 2026

IT due diligence on a distributor means checking the ERP version and support dates, the customizations and integrations hanging off it, whether licenses and the MSP contract survive the sale, and who knows how it all works. Do it before the letter of intent (LOI) turns into a purchase agreement, because after that every finding is your budget. Buying a software company gets you a code review. Buying a distributor gets you a server closet.

Day nine of a 45-day exclusivity window. The buyer was a PE-backed industrial supply platform, around $400 million in revenue, picking up a fastener and fittings distributor outside Tacoma that did about $52 million. The deal team wanted “a quick look at the systems.”

The CIM, the seller’s confidential information memorandum, said “fully integrated ERP environment.”

Sure.

What was actually there was Dynamics GP 2016 on SQL Server 2016 on a single Windows Server 2016 box in a closet beside the break room, 37 customizations written over eleven years by two different partners (one of which no longer exists), an EDI connection to two big-box home improvement chains that ran through a value-added network (VAN) nobody had a login for, and a pricing engine living in an Access database on the warehouse manager’s desktop. He’d been there 23 years. He was also, it turned out, the only person who knew the SQL Server SA password, which is the master admin login for the database under the ERP.

None of that killed the deal. It changed the price, and it changed the first ninety days. Which is the whole job.

Where I’m coming from, so you can discount it. I run a consulting group that cleans up exactly these environments after close, so I’m biased toward finding things. And this is KORE1’s site, where the IT staffing services group earns its fee when a finding turns into a contract seat. Neither fact changes what’s sitting in the closet.

Consultant inspecting an old tower server in a distributor's server closet while a deal team member watches during IT due diligence

What IT Due Diligence Covers When the Target Isn’t a Tech Company

IT due diligence is the buyer’s review of a target company’s systems, software contracts, data, security, and IT people before signing, done to find costs and risks that should change the price, the deal terms, or the integration plan. For a distributor, the ERP sits in the middle of nearly every finding.

Most of what you’ll find online about this is written for buying software companies. Code quality, architecture, open-source exposure, who owns the IP. Real stuff. If that’s your deal, go read what acquirers actually check in technical due diligence instead of this.

A distributor doesn’t sell its code. It sells boxes.

So the technology question gets narrower and, honestly, more boring. Can this company take an order, pick it, ship it, invoice it, and collect on it the day after you own it, and what will it cost to keep doing that once it’s inside your stack? Boring is fine. Boring is where the money hides.

Start With the ERP, Because Everything Else Hangs Off It

Nearly every distributor I’ve looked at in the $20 million to $150 million range runs on one of about eight ERPs. Epicor Prophet 21 or Eclipse. Infor CloudSuite Distribution, which half the industry still calls SX.e. Dynamics GP or Business Central. Sage 100. Acumatica. NetSuite. And a surprising number on something homegrown from the early 2000s that one consultant still supports from Boise.

Three questions about it, in order.

First, what version, and when does it stop getting patched? Not “what ERP.” What version, on what database, on what operating system. Then look up the dates yourself, because the seller’s IT person will tell you it’s fine. Microsoft’s lifecycle pages are blunt about this, and if you’re buying a GP shop, these are the dates I’d put in front of the deal team.

ComponentSupport endsWhat it means for the deal
Dynamics GP 2016Extended support ended July 14, 2026Already unpatched. The upgrade or replacement is a day-one cost.
SQL Server 2016Extended support ended July 14, 2026; paid Extended Security Updates run through July 2029Buying ESUs is a bridge with an annual invoice, not a plan.
Windows Server 2016Extended support ends January 12, 2027About three months out. It lands inside most closing timelines.
Dynamics GP 2018Extended support ends January 11, 2028One budget cycle away.
Dynamics GP, current releaseRetires December 31, 2029The whole product line. The move belongs inside your hold period, so price it now.

Read that table as a price list. Every row costs money. A target running GP 2016 on SQL 2016 today is sitting on software that stopped getting security fixes in July, and the person telling you “it works great” is right. It does. Right up until the cyber insurance renewal asks about it, or something on that box gets encrypted on a Saturday. If the plan is to keep GP alive for a while after close, line up Dynamics GP support people before you need them, because that bench gets thinner every quarter.

Second question. How many customizations, and can somebody hand you the list?

A list. Not a description. “We’ve tailored it to how we do business” is a description. A list has names, what each one does, who wrote it, and where the source code lives. In the Tacoma deal the number was 37, and four had no source code anywhere because the partner that wrote them folded in 2019. Compiled add-ins nobody could change. One of them calculated rebates for their largest customer.

So the rebate math on the biggest account ran through code nobody could read. Nice.

Customization count is the best single predictor I have for what the post-close ERP move costs, because ten customizations usually means migrating data into a standard configuration, while forty means redesigning processes that people will defend line by line, since every customization exists because somebody once won an argument. If you want the long version of what that migration involves, I wrote up how ERP data migration actually goes separately.

Already on NetSuite? Don’t relax. Ask how many SuiteScripts and workflows are live and who tests them when NetSuite pushes one of its two releases a year. In our own change-control process at Foretopia, every release gets assessed in the release preview environment before it reaches production, and any fix it forces goes through the same process as new work. Most distributors have nothing like that. They find out on Monday morning.

Third question, the one sellers like least. Is there one ERP, or one ERP plus the stuff around it that really runs the business? Spreadsheets that rebuild pricing every Sunday night. An Access database. A Crystal Reports server that emails reps their commission numbers. I count every one of those as a system. You should too.

Warehouse worker pulling a pallet of cases toward a trailer at a distributor loading dock

Count the Integrations by Hand

Ask the seller for an integration diagram and you’ll get a slide with the ERP in the middle and six arrows. Arrows are cheap.

What I want is every place data enters or leaves the ERP, and for each one, how it physically moves. On a typical distributor that list looks something like this:

  • EDI with retail and big-box customers, usually 850 purchase orders coming in and 810 invoices and 856 ship notices going out, through a VAN whose contract is in somebody’s personal email.
  • A B2B ordering portal. Or a Shopify store a nephew set up in 2021.
  • The 3PL or WMS feed, which is sometimes an API and sometimes a CSV dropped in an FTP folder at 2 a.m.
  • Bank files and the card processor.
  • Manufacturer price files. Imported monthly, by hand, by one specific person.
  • Windows Task Scheduler running a batch file on a desktop under somebody’s desk, on a PC that must never, ever be turned off. I’m not joking about this one. I’ve seen it in more deals than I haven’t.

For each line, three things. Who owns it. What breaks if it stops. Whether it survives the move onto your systems.

Give the EDI line extra time, because retail trading partners charge back for late or wrong ship notices under the customer’s rules, not yours, and if that connection drops during cutover you’ll be eating deductions on remittances for a month before anybody in finance figures out why.

Spaghetti like this is normal. Eleven years of solving whatever was in front of you looks exactly like this. You just have to price it.

The Licenses Might Not Come With the Company

This one catches deal teams, because it looks like a legal issue, gets parked with counsel, and counsel reviews the contracts they were handed. Nobody handed them the ERP order form from 2014.

Start with structure. In a stock purchase, the company holding the licenses still exists after close, so the contracts usually stay where they are unless they carry a change-of-control clause, and plenty of software agreements do. In an asset purchase the contracts have to be assigned to the buyer, and most of the software license agreements I’ve read don’t allow assignment without the vendor’s written consent. Consent usually comes. Sometimes with a fee. Sometimes the vendor uses the moment to move you onto current pricing, which on a perpetual license from 2014 can be a very different number.

Then compare what was bought against what’s in use. Count heads.

Distributors are famous for shared logins. Twelve named users, thirty people at the counter and in the warehouse sharing them. The seller has been carrying that compliance problem quietly for years, and on the day you buy the company it becomes yours, at a moment when your acquisition is in a press release any vendor’s audit team can read.

Ask for every software order form, the latest renewal invoice, and the user list pulled from inside the application itself. Then compare the three. They won’t match. That’s fine. You just want to know by how much before you sign.

I’m not your lawyer. The assignment language in your specific contracts is counsel’s call. My job is getting counsel the right pile.

Read the MSP Contract Like a Warehouse Lease

Most distributors this size don’t have an IT department. They have one IT person, maybe, and a managed service provider. The MSP holds the admin credentials, the backups, the firewall configs, the Microsoft 365 tenant, and in more than one deal I’ve worked, the domain registration.

So read that contract the way you’d read the lease on the main warehouse. Term. Auto-renewal. The notice period, which is often 90 days and sometimes 180. What “transition assistance” costs, and whether it’s promised at all. Who owns the documentation the MSP wrote. Whether the per-seat price jumps when your users get added.

The CISA guidance for MSP customers, published in September 2021 and still the clearest government checklist on this I know of, tells customers to make sure MSP accounts aren’t assigned to administrator groups and to require notice of any change in the MSP’s ownership or leadership. Ask the seller whether their MSP’s accounts are domain admins.

They are. They always are.

That second CISA point matters more than it used to. A lot of the regional MSPs serving companies this size have been bought and rolled up in the last few years, so the contract you’re reading may now be serviced by a different company with different rates and a help desk in a different time zone than the one the seller picked.

Long-tenured warehouse manager explaining the company's systems to a younger colleague in a warehouse office

The One Admin Who Knows Everything

Every distributor has one. Sometimes it’s the IT manager. Often it isn’t IT at all. It’s the controller who configured the ERP in 2012, or the warehouse manager with the SA password, or the inside sales lead who keeps the pricing spreadsheet everybody pretends is a system.

Biggest IT risk in most of these deals. It isn’t in any document you’ll be given.

You find them with one dumb question in every management interview. “When this breaks, who do you call?” Write down the names. When the same one comes up four times, that’s your person.

Then do three things before close. Put a retention agreement in front of them that pays out over twelve months, not at close, because an at-close bonus buys you a very cheerful two weeks. Get somebody shadowing them now, during diligence, while they’re still motivated to look helpful. And get what’s in their head written down while they’re around to answer questions, which means passwords into a vault, the nightly jobs into a runbook, and every customization onto that list.

Sometimes they leave anyway. Twenty years of running something your own way doesn’t always survive a new owner’s ticketing system, and I don’t blame them. Plan for a contract ERP backfill who can pick up the system the week they give notice. KORE1’s twelve-month retention rate on placements sits at 92%, and that number matters more here than speed does, because whoever comes in has to learn a system nobody documented.

The Request List I Send the Seller

One page. That’s the point. Long request lists get answered last.

AreaAsk the seller forRed flagWho handles it after close
ERPProduct, version, database, operating system, hosting, current support contractOut of support, or no active support plan with the vendor or a partnerERP program lead, interim IT leadership
CustomizationsNamed list with purpose, author, and where the source livesMissing source code, or the partner who wrote it is goneContract ERP developer
IntegrationsEvery data flow in or out, its method, schedule, and ownerJobs on a desktop; nobody has the EDI provider loginIntegration developer, EDI analyst
LicensesOrder forms, latest renewal invoices, in-app user listShared logins; consent required to assign in an asset dealCounsel, then your procurement team
MSPMaster agreement, SOW, renewal and notice terms, list of MSP admin accountsMSP accounts are domain admins; 180-day notice; no transition clauseYour IT lead, then a new MSP or an internal hire
SecurityBackup design and date of the last restore test, MFA coverage, the latest cyber insurance applicationNo restore test in the last year; insurance answers that don’t match realityContract security engineer
PeopleIT org chart plus the “who do you call” names from every interviewSame name four timesRetention agreement, then a backfill

That cyber insurance application is my favorite document in the whole pile, by the way. Somebody at the target answered a dozen yes-or-no security questions under signature. Compare those answers to what you find in the closet. When they disagree, you’ve learned something about the systems and something about the people.

What the Findings Turn Into After You Sign

Diligence that ends in a PDF is wasted money. Every red flag in that table is a staffing decision with a date attached, and the date is almost always earlier than the deal team assumed.

For an add-on, the post-close work usually sorts into three piles.

Systems first. Folding the target’s ERP, integrations, and data into your stack is what KORE1 built its post-acquisition systems integration staffing desk to do. I reviewed that page, so I’ll vouch for the sequencing on it.

Then everything that isn’t IT, which is most of it. Finance, HR, payroll, and the integration management office tracking all of the above go to the broader M&A integration staffing group.

And leadership. If the target has no IT leader, or the one it has is the person you just put a retention agreement on, somebody has to own decisions for six to twelve months, and that’s usually an interim CIO seat. Here’s how an interim CIO engagement works if you haven’t hired one before. Platform companies on their fifth add-on often skip that seat because they’ve got a playbook. On the first or second add-on, they almost never should. After close, the admin-access and change-approval gaps diligence turned up become post-close IT governance work.

Things Deal Teams Ask Me Before Signing

How long should IT diligence take on a $50 million distributor?

Two to three weeks of real work, fitted inside whatever exclusivity window you’ve negotiated. The bottleneck is almost never the review itself. It’s how fast the seller answers the request list.

Plan on one site visit, because you learn more in an hour in the server closet and the warehouse than in a week of data room PDFs.

Can our own IT team, or the target’s MSP, run this for us?

Your own IT lead, maybe, if they’ve done one before. The target’s MSP, no, because you’d be asking them to grade their own homework and set up their own renewal.

A lot of platform companies have a strong infrastructure person and nobody who’s read an ERP order form or counted customizations. That’s a gap worth filling with someone outside for two or three weeks. If the target is a software business instead, the review is a different animal, and that’s the technical due diligence staffing model.

What actually kills a deal on the IT side?

Almost nothing in IT kills a deal outright. It reprices it, or moves money into escrow, or changes the first ninety days.

The exceptions I’ve seen are a breach or ransomware event the seller didn’t disclose, customer data that can’t be extracted from the system it’s trapped in, and a major customer’s EDI relationship that depends on something that can’t move. Those three get escalated to the investment committee. Everything else becomes a line item.

Asset deal or stock deal, does IT even care?

More than most people expect. Software licenses and the MSP contract follow different rules depending on structure, so the deal structure decides which contracts need vendor consent.

In an asset deal, both usually need assignment, which means written consent from the software vendor and from the MSP. In a stock deal, you’re hunting for change-of-control language instead. Different homework. Same deadline.

Is paying for outside IT diligence worth it at this deal size?

Usually, yes, measured against the one surprise it catches. An unplanned ERP replacement on a distributor this size is a six- or seven-figure project with a year of disruption attached.

You don’t need a Big Four engagement on a $50 million add-on. You need somebody who has stood in that closet before and knows which questions the seller will try to answer vaguely. I’d rather you spend a little to find the four compiled customizations nobody can open than find them in month seven, when the rebate run for your biggest customer comes out wrong and the only person who understood it retired to Arizona.

What should the first 30 days after close look like on the IT side?

Stabilize. Don’t integrate yet.

Rotate the admin passwords, pull the MSP’s domain admin rights back to what they need, confirm a backup actually restores, sign the retention agreements, and freeze new customizations. Leave the ERP alone in month one. People will push to start the migration right away, and I get it. Moving a system nobody has documented, run by a person who might leave, is how a closed deal turns into a bad quarter.

Go Ask Who Has the Passwords

If you’re a couple of weeks from an LOI on a distributor and nobody has asked that question yet, ask it tomorrow.

Then get the ERP version, the customization list, and the MSP contract in front of somebody who has cleaned up after one of these. If you’d like somebody who has done this to look over what you’ve got, hit me up on LinkedIn. If you already know the answer is people, tell KORE1’s recruiting team which seats you think you need.

Server closets don’t get better on their own.