Choosing and Migrating RMM and PSA Platforms

What each platform does – and why the integration matters

The RMM is the agent on every managed endpoint: monitoring, alerting, patch management, scripting, and remote control. The PSA is the business system: the ticketing system, time tracking, agreements, contract billing, and profitability reporting.

The integration between them turns two tools into an operation. An RMM alert creates a PSA ticket against the right client and asset; the technician's time lands on the right agreement; the endpoint count syncs from the RMM to the invoice. When that loop breaks you bill from stale counts and lose unbilled hours. Judge the pair as a pair – a great RMM with a shallow PSA connector costs more in lost billing than it saves in features. Where both live in one platform, the integration problem disappears and another appears: you cannot replace one half without replacing both.

The rest of the tooling is in the MSP tool stack guide.

Pricing shape and what it does to your margin

The number matters less than its shape. RMMs are priced per endpoint or per technician with unlimited endpoints; PSAs per user; combined platforms usually per technician.

• Per endpoint scales with revenue, and a departing client takes its cost with it. It penalizes low-density technicians.
• Per technician, unlimited endpoints is cheapest at 150–200 endpoints per tech and gets cheaper as density rises. It punishes the first hire – a step change in cost with no matching revenue – and "unlimited" is often capped in the fine print.
• Per PSA user is the sleeper cost: every dispatcher, account manager, and part-time bookkeeper who touches a ticket is a license. Check the definitions of full and light users before counting seats.

Model the stack at today's size, at double, and at half – cheap at 1,000 endpoints can be brutal at 400 after losing a large client, especially with a minimum.

Contract term, minimums, and the churn trap

Term and minimums do more damage than list price. Three-year terms are standard from larger vendors, one-year terms often cost materially more, and month-to-month may not exist. Minimums – commonly 50 endpoints or 5 users – survive client churn. Auto-renewal notice windows are often 60–90 days before expiry, and missing one commits you for another term.

Get four things in writing: the term and notice window, the renewal price or a cap on the increase, the right to export all data at any time, and what happens to minimums if your endpoint count falls. Calendar the notice date the day you sign. The rule from startup costs holds at every size: vendor commitments should never outlast the client contracts that fund them.

Integration coverage and automation depth

Ask two questions. Is there a documented, supported API covering tickets, time entries, assets, and agreements, plus native connectors to your documentation, backup, EDR, accounting, and quoting tools? A thin API means paying a consultant to work around it.

And how deep is the automation? For an RMM: scripting in a real language, remediation that runs before a human sees the alert, patch rings and maintenance windows, a versioned script library. For a PSA: workflow rules that route, escalate, and close tickets, SLA timers that drive dispatch, agreement logic that handles overages without spreadsheets. Automation depth is the difference between 150 and 300 endpoints per technician – the whole margin story; see MSP KPIs and benchmarks.

Vendor stability, acquisition risk, and security posture

Nearly every major platform is private-equity owned, and the post-acquisition pattern is predictable: price engineering at renewal, bundling pressure, stagnation, support decline. Weigh the owner's track record as heavily as the product, and favor vendors whose terms and export tooling make leaving an inconvenience rather than a hostage situation – more in MSP vendor and channel.

The RMM is the most dangerous software you run: remote-execution rights on every client device at once. The 2021 supply-chain attack through a widely used RMM encrypted over a thousand downstream businesses, and remote-access vulnerabilities keep appearing in ransomware post-mortems. Before signing, ask for the vendor's SOC 2 report, confirm MFA is enforced rather than optional on every console login, and read their disclosure history and patch speed. A vendor that resists these questions is telling you something. Your own hardening is in securing your MSP.

Typical 2026 costs

Community-reported, quote-based, and typical rather than universal: standalone RMM at $2–6 per endpoint per month, or roughly $130–210 per technician with unlimited endpoints; dedicated PSA at $60–120 per user per month; combined platforms at $130–210 per technician. Implementation fees run from nothing to $10,000–30,000 for enterprise-grade PSAs. Together they typically land at 3–6% of MRR, inside the 8–15% budget for the full stack.

When to switch – and when not to

Switch when the platform caps the business: automation you cannot build, integrations that need manual re-keying, billing that leaks hours, or a renewal quote that changes the economics. Switch when the vendor has been acquired and the roadmap has gone quiet, or a security incident reveals a culture you no longer trust.

Do not switch because a newer product demos better or a peer raves about theirs. Most PSA dissatisfaction is under-implementation – unbuilt workflows, agreements set up wrong, no SOP for ticket handling – and a migration carries the mess along. Fix the ticket management process first. And never switch both halves at once unless you are moving to a combined platform: two migrations back to back is survivable; two at once breaks service delivery.

The migration plan

A well-run migration takes 60–120 days. Budget 2–3 months of paying both vendors, timed on your terms rather than the outgoing vendor's renewal date.

• Weeks 1–3, design: rebuild agreements, boards, statuses, and SLA rules from a clean specification, not a copy of the old configuration.
• Weeks 2–6, data export: clients, contacts, assets, agreements, open tickets, and twelve months of closed history; archive the rest as read-only exports.
• Weeks 4–10, parallel run: integrations connected, one pilot client end to end, then the rest. Bill one full month from both PSAs and reconcile every invoice line.
• Agent swap: deploy the new agent through the old RMM by script, verify check-in and policy assignment against the asset list, then remove the old agent – never the reverse. Expect a 2–5% tail of offline devices needing a manual visit.
• Cutover: on a month boundary, with a freeze on board changes a week either side, and a runbook for the day.
• Close-out: confirm the final export, written confirmation the old contract has ended, revoke the old vendor's access, update your documentation.

Bottom line

Buy the pair as a pair, and buy on shape rather than sticker: pricing model, term and minimums, API depth, automation, and vendor ownership and security posture decide what the platforms really cost over three years – typically 3–6% of MRR. Switch only for reasons that survive a written justification, never both halves at once, and plan the migration as a 60–120 day project: parallel run, scripted agent swap, two to three months of contract overlap in the budget.