MSP acquisition due diligence checklist: PSA, tickets, documentation and data rights

Why an MSP diligence checklist should cover data rights

The checks you already run in IT-services diligence (PSA reporting, ticket samples, RMM coverage, client contracts) answer two questions at once: how healthy the service operation is, and whether the seller holds years of operational records it has the right to license for AI training. Adding a rights section costs one extra page on the request list, and nobody has to hand over a single ticket to answer it.

Both sides of the table benefit. A sell-side advisor can surface a possible additional source of proceeds before the business goes to market. A buy-side advisor learns whether the target's service history is an asset, a liability or both, and whether client agreements allow the MSP to reuse it at all.

The demand behind this is specific. AI developers are training agents to triage, troubleshoot and resolve IT problems, and they need real examples of that work: the alert, the ticket, the technician's notes, the time entries, the escalation and the fix. A mature MSP's PSA holds exactly that sequence, often across a decade of clients and technologies. M&A advisors who work IT services deals are well placed to notice it because the PSA reports are already in the data room.

How to use this checklist

Work through it during the data room review and the first management meeting, before the LOI narrows everyone's attention to price and terms. Every item asks for metadata, a document you would request anyway, or a yes or no answer from management. None asks for ticket contents, client names or credentials.

Tick an item only when you have seen the document or a written answer. Anything left unticked becomes a follow-up question, not an assumption.

The MSP due diligence checklist

PSA and ticket history

• Which PSA runs service delivery (ConnectWise PSA, Autotask, HaloPSA or another), and in which year did it go live?
• Were tickets migrated from an earlier PSA, and does the old system or a full export of it still exist?
• Rough annual ticket volume, split between reactive tickets and alert-generated or recurring maintenance tickets.
• Are resolution notes, internal notes and time entries completed consistently, or do many tickets close blank?
• Are tickets linked to configurations, agreements and SLAs, so each one can be traced to an environment and a contract?
• Do closed statuses carry meaning (resolved, escalated to vendor, duplicate, client-caused), or does everything close the same way?

RMM, documentation and security tools

• Which RMM platform is in use, and how long does it keep alert, patch and script-run history?
• Is there a documentation platform such as IT Glue or Hudu holding runbooks, standard operating procedures and network diagrams?
• Who wrote the runbooks and automation scripts: employees, subcontractors or a vendor?
• Do security tools (EDR, SIEM, backup) retain incident records that the MSP, not only the client, can access?
• Are credentials stored in the documentation platform? They must be excluded from any data work, whatever else happens.

Client contracts and data rights

• The standard MSA and the largest client agreements: what do the confidentiality, data use and return-of-data clauses say?
• Does any agreement permit use of de-identified or aggregated service data, or does it limit use strictly to delivering the services?
• Which clients sit in regulated sectors (healthcare, financial services, government) with business associate agreements or flow-down terms?
• Is there a documented process for client data at offboarding, and has it been followed?
• Has any part of the service history already been licensed or shared for AI training?

People, size and authorship

• Peak full-time headcount, contractors excluded. The SourceX baseline is 50+ full-time employees at peak (contractors excluded).
• Which share of technical delivery ran through subcontractors or offshore partners, and under what intellectual property terms?
• Do employment agreements or the handbook state that work product belongs to the company?

Licensing pre-screen for the owner

• Would the owner consider an exclusive AI-training license for an agreed term, paid once, separate from the sale?
• Who would act as the authorized sponsor: the owner, CEO, CFO or another authorized representative?
• Is there someone inside the MSP who can run exports and own a metadata inventory?

Authorship gets its own section because copyright ownership follows it. The US Copyright Office's circular on works made for hire explains that a work prepared by an employee within the scope of employment belongs to the employer, while commissioned work from an independent contractor counts as work made for hire only in listed categories and with a signed written agreement. A runbook library written by salaried engineers is a cleaner asset than scripts a subcontractor produced under a loose statement of work. This is general information, not legal, tax or financial advice. Confirm with deal counsel before relying on it.

How to read the results

The rights readiness checklist goes deeper on contract language once a seller looks promising, and who qualifies lists every baseline requirement.

Where the licensing question fits in the deal timeline

Integration is where history quietly disappears. If the platform will fold the acquired MSP into its own tenant, the Microsoft 365 tenant migration playbook covers what to keep before cutover.

Red flags that end the licensing conversation, not the deal

• Ticket contents are mostly about client systems, every MSA forbids secondary use, and client consent is unrealistic.
• Many clients are healthcare providers and tickets routinely contain patient information.
• The PSA was purged, or a migration brought over only open tickets.
• The history has already been licensed for AI training.
• Nobody at the MSP can export the PSA or the documentation platform.
• A lender, receiver or trustee controls the assets and has not been involved.
• Records were generated or padded with AI to look larger.

How an advisor makes the introduction

1. Ask the owner whether they want to explore licensing at all, and how it should sit alongside the sale process.
2. Register as a partner, then send your referral link or submit the MSP through the referral form.
3. SourceX checks headcount, operating history, the spread of systems and rights directly with the owner or another authorized sponsor.
4. The MSP lists its PSA, RMM, documentation and email systems as metadata, for example with the data inventory builder; no records change hands at this stage.
5. Price and terms are agreed with the MSP, as one all-in price, before AI labs and data buyers review the opportunity.
6. Once an agreement is signed, the MSP delivers data under the redaction rules agreed at the start and receives a one-time payment.

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company, and the reward is paid only after the buyer pays and SourceX receives its fee. No reward is guaranteed, and it is never deducted from what the company receives. If a seller already pays you a success fee, tell them about the referral relationship and check your engagement letter and firm policy before you register.

Next step

Add the licensing pre-screen items to your next IT-services request list. When a seller passes, register as a partner and introduce the owner, or have them apply directly at sourcex.si/apply using your referral link.