Migrate from Splashtop Remote Support to HubSpot Service Hub

Splashtop Computer records (Computer Name, Group Name, Last Session Time, IP Address, Notes) map to a HubSpot custom object named Endpoint or endpoint_record that we provision during migration. Hostname maps to a text field, Group Name maps to a picklist or lookup to a HubSpot Team, Last Session Time maps to a datetime field for the support agent's reference. We create the custom object schema in HubSpot before any data import and map all standard Computer properties to typed HubSpot fields. Endpoint records are associated via a custom lookup to the HubSpot Company representing the client organization that owns the endpoint.

Splashtop Technicians map directly to HubSpot User accounts. We resolve by email address match. Admin-role Technicians become HubSpot Super Admins; standard Technicians become HubSpot Agents with Service Hub seat permissions. Role names are preserved in a custom text field technician_role__c for audit. Any Splashtop Technician without an email match in the destination HubSpot portal goes to a reconciliation queue for the customer admin to provision before user-assigned records import.

Splashtop Computer Groups map to HubSpot Teams. HubSpot Teams control ticket assignment routing and user permission scoping. Group hierarchy (parent groups and subgroups) translates to a flat team structure in HubSpot; nested group relationships are documented in a parent_team__c reference field. We export Group assignments alongside the computer list CSV and reconstruct the group mapping during HubSpot team provisioning.

Splashtop Access Permissions define which Technicians can reach which Computers or Groups and at what role. Splashtop exports these as a CSV with user_id, computer_id, role, and status. We infer the role hierarchy (Admin vs Technician vs User) and use it to configure HubSpot User seat types and Team membership during provisioning. The original permission CSV is delivered as a handoff artifact for the customer to reapply post-migration since HubSpot's permission model does not have a direct endpoint-access permission concept.

Splashtop SOS Call generates attended support requests that can be routed to technicians or channels. Open SOS requests at migration time are converted to HubSpot Tickets with the original requester's contact information, subject line, and status preserved. We export the SOS request list from the Splashtop Service Desk console and create corresponding HubSpot Tickets during migration. Closed SOS requests do not migrate as historical tickets unless the customer explicitly scopes them; we flag this as a data-loss disclosure item during scoping.

Splashtop Enterprise Service Desk Channels (SOS Call, invitation links, PIN codes, web form widgets) have no direct HubSpot equivalent. We map each active Splashtop channel to a HubSpot Ticket pipeline or a HubSpot Inbox conversation stream. Web form widget configurations are documented in a written channel inventory for the customer admin to rebuild using HubSpot Forms and the customer portal. Custom fields on Splashtop web forms map to HubSpot Ticket custom properties that we create before migration.

Splashtop Computer properties including IP address, hostname, operating system, last logged-in user, and Notes text field map to custom fields on the Endpoint custom object in HubSpot. IP address maps as a text field (HubSpot does not support IP as a native field type). OS information maps to a picklist. These fields give HubSpot agents endpoint context when a support ticket references an affected device.

Splashtop Deployment Codes are account-scoped strings used to silently install the Splashtop Streamer on managed computers. These are Splashtop-specific and have no HubSpot analog. We preserve the deployment code CSV as a handoff artifact. The customer retains this data if Splashtop continues to run as a co-managed tool alongside HubSpot for remote access sessions that require in-app support beyond what HubSpot Tickets provide.

Splashtop Connector supports importing and exporting RDP profiles as CSV with fields including Profile Name, Deploy Code, Enable Recording, and RDP-specific settings. We transfer the profile CSV as a handoff artifact. RDP connection profiles are Splashtop-specific; they have no native HubSpot equivalent and are documented for the customer's IT team to reapply if RDP-based remote access continues to be needed post-migration.

Splashtop role definitions (Admin, Technician, User with granular permission levels) are not exported as a standalone artifact. We infer role assignments from the Access Permissions CSV and the Technician list. Admin-tier Technicians are provisioned as HubSpot Super Admin or Service Hub Admin users; standard Technicians are provisioned as Service Hub Agents. We document the inferred role mapping in the migration handoff report for the customer's HubSpot admin to review and adjust seat types post-migration.

Splashtop Remote Support is priced by the number of managed computers, not by user count. We capture the exact computer count from the Splashtop computer list export and API during discovery, validate it against the customer's current billing statement, and use it as the scoping baseline. This count drives migration scope pricing and is documented as a billing reference for the customer to adjust their Splashtop subscription tier post-migration if they reduce endpoint count.

Splashtop does not expose session history (timestamps, duration, technician, endpoint, session notes) via its public API or admin console CSV export. Session logs are retained in the Splashtop web console but are not available as a standalone export artifact. We document this limitation explicitly and do not claim to migrate historical session data. If the customer requires session audit trails, they retain Splashtop access for session log review or export screenshots manually from the console. This is a pair-specific data-loss item disclosed during scoping before any migration begins.