Helpdesk migration
Field-level mapping, validation, and rollback between Splashtop Remote Support and Zendesk. We move data and schema; workflows are rebuilt natively in Zendesk.
Splashtop Remote Support
Source
Zendesk
Destination
Compatibility
5 of 10
objects map 1:1 between Splashtop Remote Support and Zendesk.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Splashtop Remote Support to Zendesk is a category-crossing migration from a remote access and endpoint management tool into a full-service helpdesk and ITSM platform. Splashtop Remote Support manages computers, technicians, and access permissions; Zendesk manages tickets, agents, organizations, and support channels. We map Splashtop Technicians to Zendesk Agents with role preservation, Computer Groups to Zendesk Organizations, and access-permission relationships to custom fields or tags on the Agent record. Session history is not available for export from Splashtop's public API or admin console CSV, so we flag it as non-migratable and document it in the scope agreement. SOS Requests from Splashtop Enterprise (service desk channel requests) migrate as Zendesk Tickets with the original session URL preserved in a custom field. Automations, workflows, and service desk channel configurations do not migrate as code; we deliver a written inventory for the customer's admin to rebuild in Zendesk Admin Center.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Splashtop Remote Support object lands in Zendesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Splashtop Remote Support
Technician
Zendesk
Agent (User)
1:1Splashtop Technicians map to Zendesk Agent records via email match. Role definitions (Admin, Technician, User) from Splashtop infer from the Access Permissions CSV because role schemas are not exported as standalone artifacts. We preserve the inferred role in a custom field splashtop_role__c on the Zendesk User record. Any Splashtop Technician without a matching email in the destination Zendesk org goes to a reconciliation queue for the customer to provision the User before record import continues.
Splashtop Remote Support
Computer Group
Zendesk
Organization
1:1Splashtop Computer Groups map to Zendesk Organizations. Group Name becomes Organization Name, and Group description maps to the Organization Notes field. The Group hierarchy (parent groups, child groups) is flattened during migration because Zendesk Organizations do not natively support hierarchical parent-child relationships; we represent hierarchy via the Organization field zd_parent_org__c as a custom lookup or as a naming convention (e.g., 'Parent Group > Child Group') in the Organization Name.
Splashtop Remote Support
Computer
Zendesk
Asset (Service Cloud) or Organization custom field
lossySplashtop Computers have no native Zendesk equivalent because Zendesk is a helpdesk system, not an endpoint management platform. If the customer licenses Zendesk Service Cloud, we map Computers to Zendesk Assets linked to the corresponding Organization (based on the Computer Group). If Service Cloud is not in scope, we append the managed computer list as a JSON blob in a custom Organization field (splashtop_managed_computers__c) for audit reference. The Computer Name, Group Name, and Last Session Time are preserved in either case.
Splashtop Remote Support
Access Permissions
Zendesk
User role + Organization tags
1:1Splashtop Access Permissions define which Technicians can reach which Computers or Groups, and at what role level. We decompose this matrix into two parts: the role (Admin, Technician, User) maps to the Zendesk User role (Agent, Admin), and the technician-computer-group relationship is preserved as a tag on the Zendesk User (e.g., tag: computer_group_abc) or as entries in a custom junction object if Service Cloud Assets are in scope. The Access Permissions CSV is the source of truth; we use it as a lookup table during both the Technicians and Computer Groups migration phases.
Splashtop Remote Support
Service Desk Channel (Enterprise tier)
Zendesk
Channel
1:1Splashtop Enterprise Service Desk Channels — SOS Call, invitation links, PIN codes, and web form widgets — have Zendesk equivalents at the Channel level. SOS Call session requests map to Zendesk Tickets with the channel set to the SOS-equivalent channel (email or web form depending on how the customer configured the SOS flow). Web form custom fields migrate as Zendesk ticket custom fields with equivalent field types. Channel-level routing rules do not migrate as code; we document the routing configuration for the admin to rebuild in Zendesk Admin Center under Channels.
Splashtop Remote Support
SOS Request
Zendesk
Ticket
1:1Open SOS Requests (Enterprise-tier support session requests tracked in Splashtop's Service Desk console) migrate to Zendesk Tickets. The SOS session URL is preserved in a custom field splashtop_session_url__c on the Zendesk Ticket for agents to reference the original session context. Request status (open, pending, resolved) maps to Zendesk Ticket Status (Open, Pending, Solved). Requester email from Splashtop resolves to a Zendesk End User; if no matching End User exists, we create one. Closed or historical SOS Requests are migrated as historical tickets with the Splashtop ticket ID preserved in a custom field for cross-referencing.
Splashtop Remote Support
Computer Group hierarchy
Zendesk
Organization field + parent lookup
lossySplashtop Computer Groups support nested hierarchies (parent group containing child groups containing computers). Zendesk Organizations are flat; we represent the hierarchy using a custom field parent_group__c on the Organization record and a naming convention for the Organization Name that reflects the full path (e.g., 'IT Department > Workstations > Engineering'). We validate that each organization's parent reference resolves to an existing Organization record before committing the import batch.
Splashtop Remote Support
Deployment Code
Zendesk
Configuration artifact (not migrated)
lossySplashtop Deployment Codes are scoped to the Splashtop account and are used to silently install the Splashtop Streamer on managed endpoints. These codes have no Zendesk equivalent and are not migrated. We deliver a CSV inventory of all active Deployment Codes with their associated computer counts and expiry status as part of the migration handoff documentation. The customer uses this to decommission the Splashtop Streamer deployment post-migration and provision a new remote support agent on each endpoint.
Splashtop Remote Support
RDP Profile (Splashtop Connector)
Zendesk
Configuration artifact (not migrated)
lossySplashtop Connector supports importing and exporting RDP profiles as CSV files, including Profile Name, Deploy Code, Enable Recording, and RDP-specific settings. RDP profiles are endpoint configuration data tied to the Splashtop Connector and have no Zendesk equivalent. We export the RDP profile CSVs as part of the migration artifact package and deliver them separately for the customer's IT team to evaluate whether the replacement remote support solution requires equivalent configuration.
Splashtop Remote Support
Session History
Zendesk
Non-migratable
lossySplashtop does not expose session history via its public REST API or admin console CSV export. Session logs are retained within the Splashtop web console but are not retrievable as standalone exportable records. We cannot migrate session history to Zendesk because no export mechanism exists on the source side. We document this gap in the scope agreement and recommend the customer archive screenshots or PDF exports of any required session logs from the Splashtop console before the migration window closes.
| Splashtop Remote Support | Zendesk | Compatibility | |
|---|---|---|---|
| Technician | Agent (User)1:1 | Fully supported | |
| Computer Group | Organization1:1 | Fully supported | |
| Computer | Asset (Service Cloud) or Organization custom fieldlossy | Fully supported | |
| Access Permissions | User role + Organization tags1:1 | Mapping required | |
| Service Desk Channel (Enterprise tier) | Channel1:1 | Fully supported | |
| SOS Request | Ticket1:1 | Fully supported | |
| Computer Group hierarchy | Organization field + parent lookuplossy | Fully supported | |
| Deployment Code | Configuration artifact (not migrated)lossy | Fully supported | |
| RDP Profile (Splashtop Connector) | Configuration artifact (not migrated)lossy | Fully supported | |
| Session History | Non-migratablelossy | Not supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Splashtop Remote Support gotchas
API access requires Splashtop Enterprise
Computer-count billing means scoping errors directly inflate costs
On-Prem and cloud versions have different API capabilities
Two-app architecture requires both Streamer and Business App to be migrated
Zendesk gotchas
Data export requires API scripting on non-Enterprise plans
Automations cap at 500 active rules and 1,000 tickets per hour
Help Center has no native export feature
Custom Objects and full data export are Enterprise-only
Pair-specific challenges
Migration approach
Discovery and tier identification
We audit the Splashtop Remote Support account across tier (Basic, Plus, Premium, Enterprise), computer count, technician count, Computer Group structure and hierarchy depth, Access Permissions CSV completeness, active Service Desk Channels (Enterprise only), and open SOS Requests. We pair this with a Zendesk edition decision: Suite Team ($55/agent) covers core ticketing, agent management, and reporting; Suite Growth adds macros, automations, and SLA policies; Service Cloud is required if the customer wants Asset management to hold the Splashtop computer inventory in Zendesk. The discovery output is a written migration scope, a data availability assessment (API vs CSV), and a Zendesk edition recommendation.
Schema design and Zendesk configuration
We design the destination schema in Zendesk. This includes provisioning Zendesk Agents (matching technician emails), Organizations (mapped from Computer Groups with hierarchy flattened via naming convention or parent lookup), custom fields on User records (splashtop_role__c, splashtop_access_groups__c), custom fields on Organization records (splashtop_group_path__c, splashtop_managed_computers__c if not using Service Cloud Assets), custom fields on Tickets (splashtop_session_url__c, splashtop_sos_request_id__c), and Channel configuration for migrated SOS Call and web form channels. Schema is validated in a Zendesk Sandbox before production migration begins.
Access Permissions decomposition and role inference
We parse the Access Permissions CSV to build a technician-computer-group matrix. From this matrix we infer role assignments (Admin vs Technician vs User) for each technician, map each computer-group assignment to an Organization tag or Asset relationship, and flag any inconsistencies where a technician's permissions vary across groups. The output is a technician-to-role mapping file and a technician-to-organization access list that we use during the User and Organization import phases. Any inferred role with low confidence is flagged for the customer's admin to confirm before the User import phase.
Sandbox migration and reconciliation
We run a full migration into a Zendesk Sandbox using production-like data volume. The customer's support operations lead reconciles record counts (Agents in, Organizations in, open SOS Requests migrated as Tickets, Access Permission relationships preserved), spot-checks 20-30 random technician-computer access assignments against the Splashtop Access Permissions CSV, and signs off the schema and mapping before production migration begins. Any mapping corrections — particularly around organization hierarchy and role inference edge cases — are resolved here, not in production.
Production migration in dependency order
We run production migration in record-dependency order: Zendesk Users (Agents, from Technicians with role inference applied), Organizations (from Computer Groups with hierarchy flattened), Asset records (from Computers, linked to Organizations via Group membership, if Service Cloud is in scope), open SOS Requests (as Tickets with splashtop_session_url__c and splashtop_sos_request_id__c populated), and Channel configurations (documented for admin rebuild). We disable Zendesk SLA policies and triggers before import to prevent imported tickets from triggering unintended automations, and enable them after migration validation completes.
Cutover, session history gap documentation, and rebuild handoff
We freeze Splashtop writes during cutover, run a final delta pass for any SOS Requests created during the migration window, then enable Zendesk as the system of record. We deliver the session history gap documentation (with screenshots of the Splashtop console session log location), the Access Permissions inventory with role inferences, the Deployment Code CSV, and the RDP Profile CSVs as separate artifacts. We do not rebuild Splashtop Enterprise service desk workflows, SOS routing rules, or channel configurations as Zendesk automations or triggers; those are documented separately for the customer's Zendesk admin to rebuild. We support a one-week hypercare window for reconciliation issues raised by the support team.
Platform deep dives
Splashtop Remote Support
Source
Strengths
Weaknesses
Zendesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. All 7 core objects map 1:1 between Splashtop Remote Support and Zendesk.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Splashtop Remote Support and Zendesk.
Object compatibility
All 7 core objects map 1:1 between Splashtop Remote Support and Zendesk.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Splashtop Remote Support: 200 calls per minute per deployment (Splashtop On-Prem); cloud Enterprise tier rate limits are not publicly documented.
Data volume sensitivity
Splashtop Remote Support exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Splashtop Remote Support to Zendesk migration scoping. Not seeing yours? Book a call.
Walk through your Splashtop Remote Support to Zendesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Splashtop Remote Support
Other ways to arrive at Zendesk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.