--- title: "NinjaOne ITSM Alternatives (2026): Features, TCO & Migration" slug: ninjaone-itsm-alternatives-2026-features-tco-migration date: 2026-08-05 author: Wahab categories: [NinjaOne ITSM, Migration Guide, Help Desk] excerpt: "Compare the top NinjaOne ITSM alternatives for 2026: real pricing, feature gaps, migration paths via API and CSV, and total cost of ownership." tldr: "NinjaOne's ticketing is RMM-first, not full ITSM. MSPs should evaluate Atera, Syncro, or SuperOps; internal IT teams should look at Freshservice or HaloITSM. Budget for automation rebuilds during migration." canonical: https://clonepartner.com/blog/ninjaone-itsm-alternatives-2026-features-tco-migration/ --- # NinjaOne ITSM Alternatives (2026): Features, TCO & Migration # NinjaOne ITSM Alternatives (2026): Features, TCO & Migration If you're searching for **NinjaOne ITSM alternatives**, you're hitting one of three walls: NinjaOne's ticketing system is designed as a complement to its RMM—not a standalone ITSM; per-device pricing scales unpredictably as your endpoint count grows; or you need ITIL-aligned workflows (change management, problem management, CMDB) that NinjaOne simply doesn't offer natively. NinjaOne is an excellent RMM platform—patching, monitoring, and remote access are best-in-class. But when IT teams outgrow the built-in ticketing and need real service management, the platform's architecture creates a ceiling. The challenge isn't just selecting a new helpdesk. It's decoupling your service management workflows from your endpoint management system without losing the operational visibility that made NinjaOne appealing in the first place. This guide compares the alternatives that close NinjaOne's ITSM gaps, covers real pricing and TCO, and breaks down what a migration from NinjaOne involves—including API constraints, rate limit behavior, data portability limits, and what you'll need to rebuild manually. ## Why IT Teams Outgrow NinjaOne's Ticketing NinjaOne's ticketing module is tightly coupled to its endpoint management engine. That's its strength for MSPs handling break-fix work—technicians can run scripts, reboot devices, and initiate remote sessions directly from a ticket. But it's also the boundary. **What NinjaOne ticketing does well:** - Condition-based ticket creation from endpoint alerts - One-click remediation actions from within a ticket - Brandable end-user portal for ticket submission - Basic SLA tracking - Ticket export to CSV (board-level and individual tickets) **What it doesn't do:** - **No formal CMDB or CI relationship mapping.** NinjaOne tracks devices well, but a true Configuration Management Database (CMDB) requires mapping dependencies between configuration items—for example, *Server A* hosts *Database B*, which supports *Application C*. Without this dependency graph, root cause analysis for major incidents becomes a manual process with no system-enforced blast-radius visibility. - **No native PSA** — billing, contracts, project management, and time tracking are absent. - **No ITIL change, problem, or release management workflows.** Dedicated ITSM platforms enforce a structural distinction between Incidents (unplanned disruptions), Service Requests (standard catalog items), Problems (root cause investigations), and Changes (controlled modifications). NinjaOne's model conflates these, making it impossible to enforce distinct SLA chains or multi-stage approval workflows across ticket types. - **No multi-department service delivery.** Multi-department service delivery means deploying separate service portals with distinct SLA policies, agent queues, and request catalogs for non-IT departments such as HR, Legal, and Facilities. NinjaOne is strictly built for IT operations. - **Agent-only discovery** — misses network infrastructure and cloud workloads. NinjaOne's ticketing is functional for endpoint-centric workflows. It is not designed as a strategic service management platform—and the architecture cannot be extended to fill that gap through configuration alone. ## The Alternatives Worth Evaluating The alternatives split into two categories: **unified RMM+PSA platforms** (for MSPs who want to replace NinjaOne entirely) and **dedicated ITSM platforms** (for internal IT teams who need deeper service management and may keep NinjaOne for endpoint management). ### Unified RMM+PSA Platforms These replace NinjaOne's endpoint management and ticketing in a single platform. Best for MSPs. #### Atera — Flat Per-Technician Pricing for High Device Ratios **Atera** bundles RMM, PSA, helpdesk, and remote access into a per-technician model with unlimited endpoints. For MSPs managing high device-to-technician ratios (150:1 or above), Atera's cost model inverts NinjaOne's. - **Pricing:** $129/tech/month (MSP Pro, annual) to $219+/tech/month (Power). IT Department plans start at $149/tech/month. - **AI Copilot:** Separate add-on at ~$29/tech/month — not included in base plans. - **Break-even vs NinjaOne:** Around 200 endpoints per technician. Below that ratio, NinjaOne's per-device model can be cheaper; above it, Atera's unlimited model generates compounding savings. - **Trade-off:** Feature unbundling has accelerated in 2026 — integrations and automation features that were standard on the Growth tier moved up to the Power tier in April 2026. AI Copilot and Network Discovery billed separately can push actual costs 30–40% above the base tier price. > [!NOTE] > Atera's unlimited-endpoint promise is real, but watch the add-ons. AI Copilot and Network Discovery billed separately can push actual costs 30–40% above the base tier price. #### Syncro — Best Budget Unified RMM+PSA for Small MSPs **Syncro** is a single-codebase RMM+PSA platform with per-technician pricing and unlimited endpoints. It's the cheapest unified option on this list. - **Pricing:** Core at $139/tech/month (billed annually) with RMM, PSA, ticketing, and Splashtop remote access. Team at $209/tech/month adds network discovery, advanced automation, and identity management. - **Strength:** Fastest onboarding. Users consistently report going live within days, not weeks. - **Trade-off:** PSA depth trails ConnectWise and HaloPSA. Linux agent support is limited. Advanced reporting is thin on the Core plan. #### SuperOps — Modern Unified Platform for Growth-Stage MSPs **SuperOps** is an AI-native unified RMM+PSA built from scratch (founded 2020, ex-Freshworks team). It targets MSPs with 5–25 technicians who want to reduce vendor sprawl. - **Pricing:** Starts at $79/tech/month; unified Pro and Super tiers range up to $159/tech/month. AI assistant (MonicaAI) is included in every plan—no separate add-on fee. - **Strength:** Single-codebase architecture means ticketing, asset records, and device data share a real data model—not bolted-on integrations. This matters for asset-linked ticket workflows. - **Trade-off:** Younger platform. PSA depth still trails legacy players like ConnectWise. Project billing and heavy mixed-OS fleet support are areas where it's still maturing. #### ConnectWise (Automate + PSA) — For Large MSPs with Complex Billing **ConnectWise** is the legacy leader for MSPs needing deep PSA functionality—project management, time tracking, contract billing, and multi-tier ticketing. ConnectWise Automate handles RMM. - **Pricing:** Custom-quoted. Expect significantly higher total cost than Atera, Syncro, or SuperOps. Multi-year contracts are standard; published reference points suggest $150–$250/tech/month for the combined Automate+PSA stack depending on volume. - **Strength:** Deepest PSA feature set on the market. Agreement management, project profitability tracking, and multi-tier SLA structures are unmatched among MSP-focused platforms. - **Trade-off:** Implementation timelines of 4–8 weeks are the norm, not the exception. The two-product architecture (Automate + PSA) requires ongoing integration maintenance. ConnectWise's own customer satisfaction scores have declined as the platform has grown through acquisition rather than organic development—expect support responsiveness to reflect enterprise-tier expectations, not startup responsiveness. ### Dedicated ITSM Platforms These handle service management only. Keep NinjaOne for endpoint management and integrate via API, or replace your RMM separately. #### Freshservice — Fast-Deployment ITIL Platform for Internal IT **Freshservice** is a cloud-native, ITIL-aligned ITSM designed for rapid time-to-value. It's the strongest option for teams that need full incident, change, problem, and release management with a real CMDB without hiring dedicated platform administrators. - **Architecture:** Multi-tenant SaaS with a highly abstracted orchestration layer. - **Pricing:** Starter at $19/agent/month, Growth at $49, Pro at $99, Enterprise custom—all billed annually. Freddy AI Copilot is an add-on at ~$29/agent/month. No minimum agent requirement. - **NinjaOne integration:** Freshservice offers a native NinjaOne integration that performs a one-way asset push from NinjaOne into the Freshservice CMDB. NinjaOne device records (hardware specs, OS version, IP address, last-seen timestamp) sync into Freshservice CI records on a configurable schedule. Ticket-to-device linking then happens within Freshservice. This is a polling-based sync, not real-time; sync frequency depends on your Freshservice plan tier. - **Strength:** Full ITIL process coverage out of the box. Service catalog, workflow automation, and multi-department workspaces (IT, HR, Facilities). Freddy AI provides ticket categorization, summarization, and suggested resolutions. Used by over 74,000 businesses globally. - **Trade-off:** No RMM capabilities—you'd pair it with NinjaOne or another endpoint tool. Customization hits a hard ceiling; core module behavior cannot be fundamentally rewritten. Add-ons for AI, orchestration, and asset packs can push real TCO 30–50% above sticker price. - **Best For:** Organizations that want to conform to standard ITIL best practices out of the box and need multi-department service delivery without dedicated platform administrators. For a deeper comparison, see our [Freshservice vs JSM guide](https://clonepartner.com/blog/blog/freshservice-vs-jira-service-management-the-2026-ctos-guide/) and our [ServiceNow vs Freshservice architecture guide](https://clonepartner.com/blog/blog/servicenow-vs-freshservice-the-ctos-2026-architecture-guide/). #### HaloITSM — All-Inclusive ITIL Platform for Mid-Market **HaloITSM** takes a different pricing approach: every licensed agent gets access to the full platform. No tiered plans, no locked modules. - **Architecture:** SQL-backed, highly customizable relational database with a modern REST API. - **Pricing:** $49–$70/agent/month (billed annually), with volume discounts approximately 25% for 100+ agents. Both cloud and on-premise deployment available—the only platform on this list with a credible on-premise option below the ServiceNow price tier. - **NinjaOne integration:** HaloITSM supports bidirectional sync with NinjaOne via its RMM integration framework. Device records from NinjaOne populate HaloITSM as Assets with field mapping for hostname, IP address, OS, hardware specs, and last-seen status. Alert-based ticket creation—where a NinjaOne condition fires a webhook that opens a HaloITSM incident—is supported through HaloITSM's incoming webhook configuration. This is a more flexible integration than Freshservice's native connector and supports custom field mapping. - **Strength:** All ITIL modules, asset management, change control, knowledge base, and integrations included in the base license. No module upsell. Transparent pricing. - **Trade-off:** Implementation complexity is real. Budget for third-party consulting to configure it properly—estimates from implementation partners run $5,000–$15,000 for a first-year deployment. The platform is deep but raw out of the box. - **Best For:** IT teams of 10–50 agents who want enterprise-grade features without the ServiceNow price tag and can invest in proper implementation upfront. #### Jira Service Management — DevOps-Aligned Service Desk **JSM** is built on the Jira issue-tracking engine. It's the default choice for engineering-heavy organizations where IT and software development are tightly coupled. - **Architecture:** Issue-centric, built on Atlassian's entity-attribute-value (EAV) model. Each issue type can carry custom field schemas, but the underlying data model is flat compared to a relational CMDB. - **Pricing:** $47–$80/agent/month (Premium Tier, billed annually). - **Strength:** Unbeatable integration with Jira Software, Bitbucket, and CI/CD pipelines. Bug escalation from IT ticket to development sprint is native. Change management CAB workflows integrate with deployment automation. - **Trade-off:** The UI is notoriously dense for non-technical users. HR and Facilities teams consistently struggle with the developer-oriented interface. Requires significant Jira schema design upfront—custom field proliferation becomes a maintenance burden at scale. - **Best For:** Companies where IT operations and software engineering share the same workflows and user base. See our comparison: [Freshservice vs Jira Service Management](https://clonepartner.com/blog/blog/freshservice-vs-jira-service-management-the-2026-ctos-guide/). #### ServiceNow — The Enterprise Heavyweight **ServiceNow** is a Platform-as-a-Service (PaaS) that happens to include an ITSM application. It's the reference standard for large enterprises requiring cross-departmental orchestration at scale. - **Architecture:** CMDB-first platform with highly extensible server-side Glide record scripting. The Configuration Management Database is genuinely best-in-class—CI classes, dependency mapping, and Discovery (agentless network scanning) are production-grade at enterprise scale. - **Pricing:** Licensing starts above $100/agent/month and scales with platform modules purchased. Total cost of ownership routinely exceeds $500,000/year for mid-size enterprises when you factor in implementation partner fees (certified partners typically charge $200–$400/hour), ongoing platform administration (1.5–2.5 FTE dedicated ServiceNow admins is typical), and annual upgrade cycles. - **Strength:** Infinite scalability, cross-departmental orchestration (IT, HR, Legal, Finance), and the most powerful CMDB on the market. ServiceNow's Discovery module can auto-populate CI records from network scans without agent deployment. - **Trade-off:** The [TCO floor for a properly governed ServiceNow instance](https://clonepartner.com/blog/blog/servicenow-vs-manageengine-servicedesk-plus-architecture-tco/) is approximately $300,000/year for a 500-person organization once staffing is included. You are not buying software—you are building an internal platform practice. - **Best For:** Enterprises with 1,000+ employees, a dedicated IT platform team, and budget for certified implementation partners. ## Feature Comparison Table | Capability | NinjaOne | Atera | Syncro | SuperOps | Freshservice | HaloITSM | JSM | ServiceNow | |---|---|---|---|---|---|---|---|---| | **RMM / Endpoint Mgmt** | ★★★★★ | ★★★★ | ★★★½ | ★★★½ | ✗ | ✗ | ✗ | ✗ | | **Ticketing / Help Desk** | ★★★ | ★★★½ | ★★★½ | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | | **ITIL Process Coverage** | ✗ | Basic | Basic | Basic | Full | Full | Partial | Full | | **CMDB** | ✗ | ✗ | ✗ | Basic | Yes | Yes | Yes (flat) | Best-in-class | | **PSA (Billing/Contracts)** | ✗ | Yes | Yes | Yes | ✗ | ✗ | ✗ | ✗ | | **Change Management** | ✗ | ✗ | ✗ | ✗ | Yes (Pro+) | Yes | Yes | Yes | | **Multi-Dept Service Delivery** | ✗ | ✗ | ✗ | ✗ | Yes | Yes | Limited | Yes | | **NinjaOne Integration** | Native | Basic | Basic | Basic | One-way asset push | Bidirectional sync | Via Zapier | Custom API | | **Pricing Model** | Per-device | Per-tech | Per-tech | Per-tech | Per-agent | Per-agent | Per-agent | Per-agent | | **Starting Price** | ~$2.50/endpoint/mo | $129/tech/mo | $139/tech/mo | $79/tech/mo | $19/agent/mo | $49/agent/mo | $47/agent/mo | $100+/agent/mo | | **AI Included in Base** | ✗ | ✗ (add-on) | ✗ | Yes | ✗ (add-on) | Yes | ✗ | ✗ | | **On-Premise Option** | ✗ | ✗ | ✗ | ✗ | ✗ | Yes | ✗ | Yes (private cloud) | | **SOC 2 Type II Certified** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | ## TCO: What You'll Actually Pay Pricing pages lie by omission. Here's what a **10-technician MSP managing 500 endpoints** actually pays annually: | Platform | Base Annual Cost | Likely Add-ons | Estimated Real TCO | |---|---|---|---| | **NinjaOne** (RMM only) | ~$18,000–$24,000 | Separate PSA needed (+$6,000–$15,000) | $24,000–$39,000 | | **Atera** (Growth) | ~$21,480 | AI Copilot (~$3,480), Network Discovery | ~$25,000–$28,000 | | **Syncro** (Core) | ~$16,680 | Team upgrade if needed (+$8,400) | $16,680–$25,080 | | **SuperOps** (Pro) | ~$14,280–$19,080 | AI included | ~$14,280–$19,080 | | **Freshservice** (Pro, 10 agents) | ~$11,880 | AI Copilot (~$3,480), asset packs | ~$16,000–$18,000 | | **HaloITSM** (10 agents) | ~$5,880–$8,400 | Implementation consulting ($5,000–$15,000 Y1) | $11,000–$23,000 Y1 | > [!WARNING] > NinjaOne's per-device model means your RMM cost alone is $18K–$24K before you add any PSA or ITSM tool. If you're stacking NinjaOne + a separate PSA, you're often paying more than a unified platform would cost. **Migration timeline by ticket volume** — a common planning gap: | Historical Ticket Volume | DIY Migration Estimate | Professional Services Estimate | |---|---|---| | Under 5,000 tickets | 3–5 business days | 1–2 business days | | 5,000–25,000 tickets | 2–3 weeks | 3–5 business days | | 25,000–100,000 tickets | 4–8 weeks | 1–2 weeks | | 100,000+ tickets | Engage professional services | 2–4 weeks | These estimates assume attachments are migrated (not archived), custom field mapping is documented before extraction begins, and the target platform is fully configured before data import starts. Attachment volume and complexity are the primary variables that extend timelines beyond these estimates. For **internal IT teams** (not MSPs), the math shifts. You don't need PSA features. A 15-agent Freshservice Pro deployment runs ~$17,820/year base—but with AI Copilot and asset management add-ons, expect closer to $25,000/year. HaloITSM at $49–$70/agent keeps ongoing cost lower but demands heavier upfront implementation investment. ServiceNow's licensing alone starts above $100/agent/month; factor in 1.5–2.5 dedicated admin FTEs and certified partner implementation fees, and the TCO floor for a 500-person organization is approximately $300,000/year. ## Security and Compliance Considerations For any ITSM evaluation where data residency, regulatory compliance, or access controls are relevant, the following distinctions apply: - **Data Residency:** Freshservice, HaloITSM (cloud), Atera, and Syncro are US-hosted by default. Freshservice offers EU data residency on Pro and Enterprise tiers. HaloITSM on-premise eliminates the residency question entirely. - **SOC 2 Type II:** All platforms in this comparison (NinjaOne, Atera, Syncro, SuperOps, Freshservice, HaloITSM, JSM, ServiceNow) maintain SOC 2 Type II certification. Verify current certificates directly from vendors before procurement. - **GDPR:** Freshservice and HaloITSM both offer Data Processing Agreements (DPAs) as standard. For cloud deployments, confirm where ticket content (including PII in ticket descriptions) is stored. - **Role-Based Access Control:** HaloITSM and ServiceNow offer the deepest RBAC granularity. Freshservice's RBAC is adequate for most mid-market use cases but has documented limitations on field-level visibility controls below the Enterprise tier. - **On-Premise:** Only HaloITSM (on this list, below ServiceNow pricing) offers genuine on-premise deployment. This matters for organizations in highly regulated sectors (defense contractors, healthcare with strict data localization requirements). ## The Integration Strategy: Keeping NinjaOne RMM Migrating away from NinjaOne ITSM does not mean abandoning NinjaOne RMM. Best practice is to keep NinjaOne for endpoint management and integrate it with your new ITSM platform. > [!TIP] > **Architectural Best Practice:** Configure your new ITSM (e.g., Freshservice or HaloITSM) as the system of record for tickets and assets, but use NinjaOne as the discovery source. Set up an API sync where NinjaOne pushes device data (CPU, RAM, OS version, IP address) into the ITSM's CMDB on a scheduled basis. **NinjaOne webhook event types** available for ITSM integration: NinjaOne exposes condition-based webhooks for the following event categories: device condition triggered, device condition resolved, device online/offline state change, and scheduled maintenance window start/end. The webhook payload is JSON and includes `deviceId`, `organizationId`, `conditionId`, `severity`, and `timestamp` fields. Authentication is via a shared secret passed in the `X-Ninja-Signature` request header. When an alert fires in NinjaOne (e.g., "Server Offline"), configure the webhook to POST to your ITSM's incoming webhook endpoint, creating an Incident. When the condition clears, a second webhook fires—configure the ITSM to auto-resolve the matching incident based on the `conditionId` correlation. This gives you best-of-breed endpoint management with best-of-breed service management without losing operational visibility. **Integration implementation notes:** - Freshservice's native NinjaOne connector handles the asset sync automatically but does not natively consume NinjaOne webhooks for real-time incident creation—you need Freshservice's workflow automator or a middleware layer (Zapier, Make) for that path. - HaloITSM's webhook configuration supports custom field mapping, allowing the NinjaOne `deviceId` to populate a HaloITSM Asset lookup field directly on the created ticket—enabling asset-linked incidents without manual correlation. ## How to Migrate From NinjaOne: API, Export, and What Breaks NinjaOne provides two data extraction paths. Neither is turnkey. ### NinjaOne Data Retention After Cancellation Before initiating a migration, understand NinjaOne's data access policy: **API access and administrative console access terminate at contract expiration**. NinjaOne does not contractually guarantee a post-cancellation data retention window for API access. CSV export from the admin console may remain accessible briefly after contract end, but this is not formally documented in the standard service agreement. **Planning implication:** Complete your data extraction—including all attachments—before submitting a cancellation notice. Do not begin a trial of a replacement platform, confirm it meets your requirements, and then cancel NinjaOne. Extract first, cancel after. ### Path 1: CSV Export NinjaOne's built-in ticket export sends data to CSV. You can export from a board (all visible tickets) or from individual tickets (includes all fields plus public and private comments). **What transfers cleanly:** - Ticket fields (subject, description, status, priority, assignee) - Public and private comments - Basic requester and organization data **What doesn't:** - Custom field types (dropdowns, multi-select, etc.) flatten to plain text strings—the field type metadata is lost, requiring manual re-mapping in the target platform - Inline images and attachments need separate validation and re-upload - Time zone handling can create discrepancies—the export uses the user's configured time zone, not normalized UTC timestamps - Relational links between tickets and devices break entirely - The API preserves custom field type metadata (field schema, option lists, field IDs) that the CSV export discards—this is the decisive reason to use the API for production migrations CSV works for archival. It does not work for a production migration where you need relational integrity or custom field type preservation. ### Path 2: NinjaOne Public API 2.0 The NinjaOne Public API is an **OAuth 2.0-secured REST API** that exposes ticketing, organizations, devices, users, custom fields, knowledge base articles, and more. This is the preferred extraction method for structured migrations. Generate a Client ID and Client Secret from the NinjaOne administration console using OAuth 2.0 Client Credentials for machine-to-machine access. The base URL is `https://app.ninjarmm.com` for US instances; EU instances use `https://eu.ninjarmm.com`. **API rate limits — empirically observed behavior:** NinjaOne does not publish official rate limit documentation as of mid-2026. Based on observed migration behavior: - The API begins throttling at approximately **100–150 requests per minute** on standard instances - Rate limit responses return HTTP `429` with a `Retry-After` header (value in seconds, typically 5–30) - Attachment download endpoints throttle more aggressively than metadata endpoints—treat attachment extraction as a separate, slower pipeline - Batch sizes of 50–100 records per request with a 1-second sleep between calls reliably avoid throttling on ticket and device endpoints Compare to documented limits on competing platforms: Freshdesk publishes 400 API calls/minute (Enterprise); Zendesk publishes 700 API calls/minute (Enterprise); Jira Service Management publishes 1,000 API calls/10 minutes per OAuth app. NinjaOne's undocumented limits are conservative by industry comparison. **API constraints to plan around:** - The `/v2/tickets` endpoint uses cursor-based pagination. You must handle the `cursor` token in your loop to retrieve all records—offset-based pagination is not supported. - Attachment extraction requires per-ticket API calls, which scales linearly with ticket volume and is the primary driver of migration timeline variance. - Custom field schemas are accessible at `GET /v2/ticketing/ticket-form/{formId}/fields`—extract these before ticket data to build your field mapping. - **Critical:** API access terminates at contract expiration. If you cancel NinjaOne before completing your migration, you lose API access immediately. ### The Data Extraction Sequence To maintain relational integrity, extract data in this order: 1. **Extract Custom Field Schemas:** `GET /v2/ticketing/ticket-form/{formId}/fields`. Store field IDs, types, and option lists. This is your field mapping dictionary for the target platform—build it first. 2. **Extract Organizations and Locations:** `GET /v2/organizations`. This establishes the foundational hierarchy in your target system. 3. **Extract Users:** `GET /v2/users`. Map these to Requesters and Agents in the target platform. 4. **Extract Devices:** `GET /v2/devices`. This data populates your new CMDB. Store the NinjaOne `device_id` in a custom field on the target platform to maintain future API syncs. 5. **Extract Tickets:** `GET /v2/tickets` using cursor-based pagination. Store the NinjaOne `ticketId` as a reference field in the target system to enable post-migration cross-referencing. 6. **Extract Ticket Activities:** For every ticket ID, call `GET /v2/tickets/{id}/activities` to pull the conversational thread, internal notes, and status changes. ### Handling the Attachment Problem Attachments are the primary failure point in any ITSM migration. NinjaOne stores attachments as binary blobs tied to specific activities. A standard CSV export drops inline images and breaks device-ticket links. To migrate an attachment, your script must: 1. Parse the activity feed for `attachment_id`. 2. Call `GET /v2/tickets/{ticket_id}/attachments/{attachment_id}` to download the file into memory. 3. POST the file as `multipart/form-data` to the target system's attachment endpoint. 4. Rewrite the HTML body of the ticket to point to the new attachment URL, ensuring inline images render correctly. ```python # NinjaOne API extraction with rate limit handling import requests import time def get_ninja_tickets(access_token, cursor=None): url = "https://app.ninjarmm.com/v2/tickets" headers = {"Authorization": f"Bearer {access_token}"} params = {"cursor": cursor} if cursor else {} response = requests.get(url, headers=headers, params=params) if response.status_code == 429: # Rate limit hit — use Retry-After header, default to 10s retry_after = int(response.headers.get("Retry-After", 10)) time.sleep(retry_after) return get_ninja_tickets(access_token, cursor) response.raise_for_status() return response.json() def extract_all_tickets(access_token): tickets = [] cursor = None while True: data = get_ninja_tickets(access_token, cursor) tickets.extend(data.get("data", [])) cursor = data.get("cursor") if not cursor: break # Conservative sleep between pages to avoid throttling time.sleep(1) return tickets ``` ### What You Must Rebuild Manually Regardless of which extraction method you use, the following objects **never transfer** between platforms: 1. **Automation rules and triggers** — condition logic, routing rules, and escalation workflows must be rebuilt in the target platform 2. **SLA policies** — response/resolution targets, business hours calendars, and escalation chains are platform-specific 3. **Custom field behavior** — dropdown options transfer as strings; required-field logic, conditional field visibility, and field dependencies need manual mapping 4. **Email channel configuration** — SMTP settings, forwarding rules, and notification templates 5. **Dashboard and report configurations** — every platform structures analytics differently; no migration tool transfers report definitions 6. **Webhook and integration configurations** — all outbound webhooks and third-party integrations must be reconfigured in the target platform > [!TIP] > Run a sample migration of 50–100 tickets before the production cutover. Map custom fields carefully—names often match but types and validation rules don't. Plan for a read-only freeze period during cutover (typically 2–4 hours for smaller datasets, up to 24 hours for large migrations) to prevent data loss from tickets created during extraction. For a broader look at migration approaches, see our [guide to help desk migration tools vs. DIY vs. services](https://clonepartner.com/blog/blog/help-desk-migration-alternatives-2026-tools-vs-diy-vs-services/). ## Decision Framework: Which Alternative Fits Your Team The right choice depends on your organizational type and what you're actually replacing. **Choose a unified RMM+PSA (Atera, Syncro, SuperOps) if:** - You're an MSP replacing NinjaOne entirely - You need ticketing, billing, and endpoint management in one platform - Per-technician pricing aligns better with your business model as your device count grows - You don't need formal ITIL processes or multi-department service delivery **Choose ConnectWise if:** - You're a large MSP (15+ techs) with complex project billing, agreement management, and multi-tier SLA structures - Deep PSA functionality is non-negotiable and you can absorb a 4–8 week implementation - You have existing ConnectWise ecosystem integrations (BrightGauge, IT Glue via Kaseya) **Choose Freshservice if:** - You want rapid deployment (days to weeks, not months) and AI-driven automation with strict ITIL compliance - You're an internal IT team scaling into multi-department service delivery (HR, Facilities, Legal) - You need a NinjaOne asset sync without building a custom integration - You will not hire dedicated platform administrators **Choose HaloITSM if:** - You want maximum ITIL flexibility, bidirectional NinjaOne sync, and on-premise deployment without enterprise overhead - You're a growing IT team of 10–50 agents who can invest in proper implementation upfront - Module upsells are a dealbreaker and you want everything in one license **Choose Jira Service Management if:** - Your IT operations are deeply integrated with software development pipelines - You already use Jira Software and Confluence - Your end users are technical enough to navigate the Jira interface **Choose ServiceNow if:** - You're building a cross-departmental service catalog for a 1,000+ employee enterprise - You have budget for certified implementation partners and 1.5–2.5 dedicated platform admin FTEs - CMDB depth, network Discovery, and platform extensibility are top priorities **Keep NinjaOne's ticketing if:** - Your ticket volume is low and endpoint-centric (under ~500 tickets/month) - You don't need formal ITIL workflows or multi-department service delivery - Your team is under 5 technicians and the built-in ticketing covers 80%+ of your use cases ## What Migration Actually Involves The pattern in NinjaOne-to-ITSM migrations is consistent: ticket and contact data extracts cleanly via the API, device records need schema mapping into the target CMDB, and the real labor is rebuilding automation logic, SLA structures, and custom field relationships in the target system. **The rebuild phase is where timelines slip.** Teams that underestimate it typically add 2–3 weeks beyond their extraction timeline. Teams that document their existing SLA rules, routing logic, and field dependencies before beginning extraction—and configure those rules in the target platform before importing data—finish in days, not weeks. **What to document before you start:** - All active SLA policies (response time, resolution time, business hours definition, escalation conditions) - All automation rules (routing conditions, auto-assignment logic, escalation triggers) - Custom field list with field type, required/optional status, and conditional logic - Integration list (PSA connections, monitoring tools, notification webhooks) - Current agent and group structure with permission levels Do not attempt to map ticket data manually using CSVs for production migrations. You will lose historical asset links, break custom field relationships, and create an inconsistent record that frustrates agents from day one. > Need help migrating from NinjaOne? Our engineers handle the data extraction, field mapping, attachment validation, and target platform import — so your team stays focused on operations, not migration scripts. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## Frequently asked questions ### Does NinjaOne have full ITSM capabilities? No. NinjaOne includes a built-in ticketing system designed for endpoint-centric support, but it lacks a formal CMDB, ITIL change/problem management, native PSA features, and multi-department service delivery. It's an RMM with helpdesk features, not a dedicated ITSM platform. ### Can I keep NinjaOne RMM if I migrate to a new ITSM? Yes. Best practice is to retain NinjaOne for endpoint management and integrate it with your new ITSM via API, using NinjaOne as the discovery source that pushes device data into your new CMDB and triggers incident creation via webhooks. ### How do I export ticket data from NinjaOne? NinjaOne supports CSV export from ticket boards and individual tickets, but CSV flattens custom fields and drops relational links. For structured migrations, the NinjaOne Public API 2.0 provides OAuth 2.0-secured REST endpoints for tickets, organizations, devices, and custom fields with full relational integrity. ### What is the cheapest NinjaOne alternative with RMM and PSA? SuperOps starts at $79/tech/month with unified RMM and PSA, including AI features in every plan. Syncro Core at $139/tech/month is the cheapest option with proven RMM+PSA maturity and unlimited endpoints. ### What data doesn't migrate from NinjaOne to another ITSM? Automation rules, SLA policies, workflow triggers, email channel configurations, and dashboard/report setups never transfer between platforms. Custom field dropdown options and validation logic also require manual rebuild. Ticket content, contacts, and organizations transfer cleanly via API.