MSP roadmapping FAQ

Assessment and scoping define the work, risks, assumptions, and boundaries. Quoting prices that approved scope and collects the client decision. QBR work turns the same client baseline into roadmap, budget, and follow-up decisions.

No. Client portals can supply useful inputs such as ticket trends, requests, approvals, reports, and client activity. The QBR still needs an owner, a decision record, a roadmap, budget context, and follow-through.

A 12-36 month plan showing what IT investments the client should make, when, and why. Covers hardware refresh, security upgrades, software migrations, and budget allocation.

Audit current state. Identify gaps against their business goals. Prioritize by risk and ROI. Assign rough timing and budget. Present options, not mandates. Update quarterly.

Tie recommendations to business outcomes they care about. "Your server is old" doesn't land. "This server failing costs you $15k/day in downtime" does. Make the cost of inaction clear.

UniFi Fabrics is Ubiquiti's management layer over Site Manager for grouping multiple UniFi sites under shared administration and identity. For MSPs, the value is cleaner fleet visibility and role-based controls across client sites, not a replacement for scope, support ownership, or client approvals.

Yes, if you manage many UniFi sites and need one place to see site health, assign roles, and use SSO. It does not remove the need to document who owns the console, who approves changes, and which work is included in the agreement.

Ubiquiti says Fabrics includes API-driven workflows and a Fabric API, and Art of WiFi notes Site Manager API keys connect through unifi.ui.com. Treat API work as billable engineering scope until you know the endpoints, auth model, and reporting requirements.

The main risks are cloud dependency, permission sprawl, unclear client ownership, and assuming multi-site visibility equals support scope. Art of WiFi notes the Site Manager API depends on Ubiquiti cloud and does not support legacy self-hosted Network Application.

Standardization can reduce training and quoting friction when the client fit is real. Do not force it into every environment. Scope discovery, migration work, firewall policy, support boundaries, and exception handling before you quote it.

Scope identity provider setup, Fabric readiness, group mapping, VPN, Wi-Fi, Door Access, local accounts, exclusions, logs, break-glass access, and offboarding evidence. The work is access policy design, not just a Site Manager setup task.

The identity provider can sync user state, but the MSP and client still need a named offboarding owner. Someone must verify group removal, local UniFi users, Door Access credentials, VPN access, logs, exceptions, and emergency accounts after the user leaves.

Ubiquiti documents Microsoft Entra, Google Workspace, Active Directory, LDAP, and JumpCloud LDAP as identity provider options for UniFi Fabrics. MSPs should confirm licensing, group quality, ownership, and lifecycle process before quoting the implementation.

Separate subscription cost from implementation and recurring review work. Price licensing, IdP readiness, group cleanup, VPN and Wi-Fi policy, Door Access mapping, pilot testing, logging, exception review, and quarterly access review as distinct scope.

Addigy is usually better when the MSP wants one operating plane for many Apple clients, with live troubleshooting, reporting, and repeatable service delivery. Mosyle is usually better when client-owned accounts, public pricing, and clearer handoff language matter more.

The client should own the Apple management layer where possible, including Apple Business Manager and the APNs certificate account. The MSP can manage the service, but ownership, admin access, recovery, renewal, and exit terms should be written into the scope.

The client should own Apple Business Manager because it represents the organization’s devices, device assignments, roles, Apps and Books, and MDM service connections. The MSP can administer ABM, but the client needs recoverable ownership and documented admin access.

The client should control the Managed Apple Account or Apple Account used for the APNs certificate, with the MSP named as renewal owner when renewal is part of the managed service. Apple says APNs certificates need annual renewal, so the account used to create the certificate matters.

Quote discovery first, then implementation. Include Apple Business Manager, APNs, current MDM removal, supported OS versions, pilot devices, user communication, app deployment, FileVault, Activation Lock, rollback, reporting, and acceptance criteria.

UniFi is usually better when the MSP wants a deeper Ubiquiti standard, stronger community support, and room for cameras, gateways, door access, or multi-site management. TP-Link Omada is usually better when the client needs practical business Wi-Fi on a tighter hardware budget and the support model is simple.

Cloud Gateway Ultra is a strong starting point for a simple small office that needs a separate gateway, ordinary routing and segmentation, and a clear spare and recovery plan. Use UDR7 only when an integrated Wi-Fi shape genuinely fits the site. Validate the current Ubiquiti specification and the client’s actual traffic before ordering either.

Yes, for small sites with predictable traffic, a simple network design, and a documented spare and recovery path. It is a poor fit when the client has high outage sensitivity, unknown ISP dependencies, heavy VPN use, or expects enterprise-style recovery without paying for it.

Use UDR7 for a compact site where an integrated gateway and Wi-Fi layout genuinely fits the coverage plan. Avoid it when access-point placement, cameras, network expansion, or a fast hardware-replacement requirement would make an all-in-one appliance a constraint.

Include discovery, gateway sizing, ISP and failover design, staging, VLAN and VPN work, hardware and spares, cutover, validation, documentation, firmware ownership, administrator ownership, and exclusions. The hardware line should be the least surprising part of the quote.

Omada often wins on upfront hardware cost, but that is not the full project cost. MSPs still need to price cabling, design, controller care, firmware windows, spares, documentation, and support boundaries before calling it cheaper.

Yes, if the MSP manages multiple Omada customers and wants cleaner customer, site, and user structure. It does not remove the need to define who owns the controller, licensing path, backups, admin access, and future change work.

Either can work for smaller hospitality sites if the scope covers coverage design, PoE budget, guest Wi-Fi policy, spare hardware, onsite labor, and escalation. If the hotel needs formal enterprise support or strict wireless validation, the MSP should scope that before recommending either platform.

Include current-state assessment, AP and switch counts, PoE budget, cabling assumptions, controller ownership, VLANs, guest Wi-Fi, firewall changes, spares, documentation, testing, and what future changes are included versus billable.

UniFi is usually better when the MSP wants lower hardware cost, a repeatable Ubiquiti standard, and strong multi-site management options. Ruckus Unleashed is usually better when the site has harder RF, denser client load, or a client who will pay for stronger wireless performance.

Ruckus Unleashed can be a good fit for single-site or small-site SMB clients that need stronger Wi-Fi without a separate controller appliance. MSPs still need to define admin ownership, remote management, firmware windows, backups, documentation, and the migration path if the client later needs SmartZone or Ruckus One.

UniFi usually has the lower access point hardware cost, but the cheaper project depends on PoE, switching, cabling, controller ownership, spares, validation, and support scope. A Ruckus quote can still be the better business decision when poor RF would create recurring tickets on cheaper gear.

Ruckus Unleashed is strongest as a simpler SMB or single-site management model. Service providers can use premium remote management options for multiple installations, and growing clients may later need SmartZone or Ruckus One, so the MSP should name the trigger for that migration in the scope.

Scope the business goal, AP count, PoE class, switch budget, cabling, floor plan, guest Wi-Fi, VLANs, controller ownership, firmware policy, spare hardware, coverage validation, and support SLA. The brand decision comes after the operating model is clear.

UniFi is usually better when the client needs lower hardware cost and accepts an MSP-led support model. Meraki is usually better when the client values vendor-backed cloud management, formal support, and renewal discipline enough to keep paying for it.

UniFi is usually the safer fit when the MSP wants a broader product set, more mature multi-site management, and room to grow into adjacent products. Alta Labs is usually the cleaner fit when the client wants subscription-free networking and the deployment is small enough that the support model stays tight.

Alta Labs markets its platform around a subscription-free feel for core networking management, which is the main reason MSPs look at it. That does not remove the MSP's recurring costs for monitoring, firmware windows, admin access, documentation, spares, and support.

It can work for smaller MSP deployments, but the public docs still show separate local accounts per Control appliance and a cloud or local split. That means MSPs should treat Alta Labs as a younger platform and validate support, access, and recovery workflows before standardizing on it.

Alta Labs is worth a look when the client wants subscription-free Wi-Fi, the site count is small, the network is fairly simple, and the MSP can define support boundaries clearly. It is a weaker fit when the client may need a broader product lineup, deeper policy work, or a more mature multi-site operating model.

Include current-state assessment, control ownership, firmware windows, monitoring, guest Wi-Fi changes, VLAN or firewall work, spare gear, RMA handling, documentation, and what future changes are billable. Subscription-free hardware still needs a priced support model.

UniFi is cheaper mainly because it does not require the same mandatory cloud license model. The risk is that the MSP may still own controller maintenance, documentation, monitoring, and client support, so the quote has to price that work clearly.

Meraki is easier to justify when the client has multiple sites, wants stronger vendor support, needs cleaner license visibility, and can budget renewals without treating every invoice as a surprise. It is a poor fit when the client only wants the cheapest hardware.

An MSP can standardize on either platform, but the standard must include discovery, support boundaries, renewal handling, admin access, documentation, and exception rules. The platform choice matters less than whether the client understands what is included.

Include current-state assessment, hardware, licensing, configuration, cutover, documentation, recurring support boundaries, future roadmap items, and approval ownership. Do not quote only the shopping cart and hope the client understands the operational work.

UniFi Protect is usually better when the client wants lower recurring vendor cost, local storage, and accepts an MSP-led support model. Verkada is usually better when the client has multiple sites, more stakeholders, and will pay for cloud management, vendor support, renewals, and auditability.

UniFi Protect usually has the lower vendor software bill because Ubiquiti markets Protect around no camera licensing fees. That does not make the MSP's work free. Retention design, exports, user access, firmware policy, recorder health, and after-hours footage requests still need a priced support model.

Verkada is easier to justify when the client has multiple locations, non-technical managers, stricter access expectations, renewal discipline, and a real need for cloud management, automatic updates, support, and audit logs. It is a weaker fit when the client only wants the cheapest camera hardware.

Scope camera placement, cabling, PoE budget, VLANs, recorder sizing, retention days, user access, clip exports, firmware windows, hardware replacement, mobile access, and what becomes billable after installation. Subscription-free cameras still create support tickets.

Quote the project and the recurring support model separately. The project covers discovery, design, install, cutover, and acceptance testing. The support model covers user changes, retention checks, device health, evidence exports, license or warranty tracking, reporting, and billable exceptions.

SonicWall is often better when the client needs a practical SMB firewall standard, clearer HA renewal math, and a support model the MSP already knows. Fortinet is often better when the client needs a broader network and security architecture, stronger central management, and can fund the extra licensing and admin work.

Choose based on the operating model, not vendor preference. Check HA licensing, support entitlement, central management, ZTNA scope, migration labor, reporting needs, and who owns renewals. The cheaper hardware quote is not cheaper if it hides support work.

SonicWall says associated HA pairs can share licenses from the primary appliance. Fortinet's NGFW ordering guide says each appliance in an HA cluster needs its own license and FortiCare contract, with the same license level across the cluster. That difference belongs in the quote before the client approves redundancy.

Fortinet can be better for complex clients that need richer network architecture, FortiManager or FortiGate Cloud, FortiAnalyzer, FortiClient EMS, and deeper policy control. It is not automatically better for every SMB client. If the client will not pay for the full operating model, the stronger platform can become a margin problem.

Scope the renewal owner, support contract, security bundle, HA impact, firmware plan, reporting cadence, ZTNA or VPN changes, migration cleanup, after-hours testing, and documentation. Renewal work should appear in the client roadmap before it becomes an emergency quote.

UniFi Enterprise Firewall Core is Ubiquiti's enterprise-scale UniFi Cloud Gateway. For MSPs, the useful question is not whether the hardware is powerful. It is whether the quote includes discovery, high availability design, rollback rules, spares, support ownership, and client change approval.

It can reduce the firewall license line item, but it does not remove MSP cost. UI Care, CyberSecure Enterprise, design, failover testing, documentation, onsite labor, after-hours work, and support ownership still need to be priced clearly.

Include current-state capture, design review, client approvals, rollback criteria, onsite and remote owner assignments, validation tests, and next-day support boundaries. A firewall change touches internet, VPN, voice, apps, printing, cameras, and remote access, so the change window needs a written done-state.

Quote HA as design and testing work, not just a second appliance. The scope should cover VRRP design, switch and power paths, ISP failover, cable labeling, failover testing, recovery testing, and the acceptance criteria that prove the client is protected.

Yes, if the firewall change affects uptime, security policy, site connectivity, remote work, compliance, or client budget. Put it on the roadmap with timing, risk, scope, dependencies, and budget so it does not become a surprise weekend project.

UniFi Drive can fit clients that need simple local storage inside a UniFi-standard site. Synology is usually stronger when the NAS participates in backup, restore, sync, Microsoft 365 protection, or file operations that need mature admin workflows.

Use a UniFi NAS when the workload is narrow, the client already fits a UniFi standard, and the MSP has separately documented offsite copy, monitoring, restore tests, permissions, firmware windows, and replacement ownership.

Synology can be a good MSP backup component because DSM has packages for Hyper Backup, Snapshot Replication, Active Backup for Business, and Active Backup for Microsoft 365. It still needs sizing, offsite copy, immutable protection, monitoring, and restore tests before it becomes a recovery promise.

Pick Synology when the NAS is already part of the site standard and the backup job is narrow enough to stay simple. Pick Veeam when you need more control over repositories, reporting, and recovery design, or when the backup service itself is a core operational offering.

Only on the software line. The MSP still pays for NAS hardware, disks, offsite copy, monitoring, restore testing, and the labor required to prove recovery. License-free can help margin, but it does not remove the cost of a real backup service.

Synology is a strong fit when you want license-free Microsoft 365 backup to NAS storage and the recovery scope is simple. Veeam is usually better when you need broader service-provider reporting, a more established backup operations model, or a consistent workflow across many workloads.

Verify the offsite copy, restore test cadence, retention, permissions, and support boundaries before you quote either product. Backup status is not the same as a proven restore, and the client should see the difference in the scope of work.

An MSP NAS restore plan should define the protected data, offsite destination, retention, immutable layer, restore-test cadence, recovery owner, success criteria, monitoring alerts, permissions review, and client-approved support boundaries.

Scope the backup software, cloud or offsite destination, retention, encryption owner, failed-job monitoring, restore tests, firmware windows, drive replacement, and emergency labor. UniFi Drive can be storage, but the MSP still has to design the recovery model.

Keep existing ONVIF cameras when they have current firmware, documented credentials, clean streams, acceptable image quality, working event behavior, and a named support owner. Replace cameras that cost more to support than they save in hardware budget.

Yes, UniFi Protect supports third-party ONVIF cameras, but adoption is not the same as a managed support promise. MSPs should test each model for stream quality, motion events, audio, retention, thumbnails, and client review workflow before quoting the migration.

Scope camera inventory, firmware, ONVIF profile, PoE budget, VLAN reachability, admin credentials, stream settings, motion behavior, audio, retention target, bandwidth, replacement candidates, and support ownership. The quote should separate discovery, test adoption, cleanup, replacement, and handoff.

Some third-party cameras can send motion events to Protect, but MSPs should test the exact model and firmware. Motion events are not the same as UniFi-native AI detections, so quotes should state which cameras support the client's expected review workflow.

Name the support owner in the quote. If the MSP owns the camera, price firmware policy, credential storage, stream tuning, event troubleshooting, monitoring expectations, and replacement recommendations. If nobody owns it, replace the camera or exclude it from the support promise.

RMM data should turn into decisions: patch exceptions, lifecycle risk, noisy alerts, and configuration gaps should become roadmap items or scoped project quotes. If the data only becomes a report full of red boxes, the MSP is creating anxiety without budget approval.

No. A client portal can supply useful QBR inputs, including ticket trends, requests, approvals, reports, and client activity. A QBR still needs an owner, a decision record, a roadmap, budget context, and follow-through.

Scopable turns portal signals, assessments, gaps, QBR notes, and roadmap decisions into quote-ready scope and client follow-through. It does not replace a portal. It keeps the work after the portal from getting lost.