Migrate from N-able MSP Manager to Zendesk

MSP Manager Customer records map directly to Zendesk Organization. The Customer's primary address, program level, service items, and billing contact information map to Zendesk Organization fields and tags. Multi-location customers in MSP Manager (locations attached to a single Customer) are stored as Zendesk Organization location addresses; if the customer's use case requires separate Organization records per location, we flag this for scoping and the customer chooses the hierarchy strategy before migration begins.

MSP Manager Contact records map to Zendesk End Users (the default user type in Zendesk support). Email, name, phone, role, and portal access flag migrate. If the MSP Manager Contact has a portal_login_enabled flag, the Zendesk End User is provisioned with the same email for portal access. Contact role and department map to Zendesk user fields. We resolve the parent Customer-to-Organization lookup at migration time so End Users are associated with the correct Organization before the ticket import phase begins.

MSP Manager Tickets map to Zendesk Tickets with ticket ID, subject, description, status, priority, category, assigned technician, and timestamps preserved. MSP Manager ticket status (open, pending, resolved, closed) maps to Zendesk ticket status (open, pending, solved, closed). The MSP Manager Category field maps to Zendesk Tags or a custom ticket field depending on the customer's desired categorization scheme. The assigned technician resolves to a Zendesk Agent by email match against the Users table.

MSP Manager custom ticket fields (text, number, dropdown, date, checkbox, rich text, section) map to Zendesk ticket fields by inspecting the live account schema via the MSP Manager API before migration. Some MSP Manager custom field documentation URLs return 404 errors, so we enumerate the actual account schema at discovery rather than relying on published docs. Zendesk field types are matched to MSP Manager field types; any dropdown with dynamic option lists that cannot be safely enumerated is flagged for manual post-migration review. Rich text fields migrate as HTML content to Zendesk's text field.

MSP Manager Time Entries (technician, date, duration, description, billable flag) attach to Zendesk Tickets as internal comments or as a structured audit section depending on the customer's preference. Billable time is preserved as a custom field on the Zendesk comment or as a separate custom Ticket field rather than a live billing record because Zendesk has no native billing module. We flag whether any time entries are orphaned from closed or deleted MSP Manager tickets and require re-attachment before migration.

MSP Manager Expense records (amount, date, vendor, description) attached to tickets map to Zendesk as either a custom Zendesk Expense object (Suite Professional and above via Custom Objects API) or as internal comments on the related Ticket, depending on whether the destination Zendesk tenant has a pre-configured expense custom object. Expenses not linked to tickets are stored as Organization notes or exported as a structured CSV for the customer's admin to reconcile against their accounting software.

MSP Manager Invoices are generated from billable time and expenses and carry status (draft, sent, paid). Zendesk has no native invoice or billing module. We do not migrate Invoices as live records. Instead, we export invoice header and line item data as a structured CSV (invoice ID, customer reference, date, amount, status) for the customer's admin to import into their accounting software (Xero, QuickBooks, or equivalent) post-migration. The CSV is generated during the data audit phase.

MSP Manager KB articles (procedure and policy documentation scoped per Customer) export as HTML content and map to Zendesk Guide articles. Article title, body, and author migrate. MSP Manager's per-customer scoping does not have a direct Zendesk equivalent; we either assign KB articles to a global Zendesk Guide section or use Zendesk's section-per-organization permission model if the customer has configured multi-brand or per-organization Guide permissions on their Zendesk Suite tier.

MSP Manager Assets (device records linked to a Customer, including hardware specs and status) map to Zendesk as a Custom Object (Suite Professional and above) with fields for device name, serial number, type, status, and a lookup to the related Zendesk Organization. Asset data synced from N-sight RMM carries partial device detail; we preserve the asset record and note that full device monitoring context lives in N-sight and is not duplicated in Zendesk.

MSP Manager Service Items (managed service scope and pricing per customer, e.g., per-user or per-device plans) map to Zendesk as a Custom Object if the destination Suite tier supports it, or as Tags on the Organization record if not. Service item name, billing model, and rate migrate as fields on the Zendesk record. If the customer uses service items for SLA tracking in MSP Manager, we map the SLA tier to a Zendesk Organization field or SLA policy configuration post-migration.

MSP Manager customer portal branding (logos, color schemes, ticket submission preferences) is stored as UI configuration state rather than structured exportable records. We capture portal configuration screenshots during the pre-migration audit but treat portal branding as a manual reconfiguration task in Zendesk's Help Center theming and brand settings. The portal configuration data is not available via MSP Manager's OData or Swagger API as structured records.

MSP Manager user accounts with role-based permissions (Admin, Technician, View-only) map to Zendesk Agents and Admins. We resolve users by email match against the Zendesk destination User table. Any MSP Manager user without a matching Zendesk account is held in a provisioning queue for the customer's admin to create before agent import. Role permissions (e.g., whether a user can manage custom ticket fields) do not carry over directly because Zendesk's permission model is structured around Agent roles and Brands rather than MSP Manager's permission categories.