Migrate from Spiceworks Cloud Help Desk to Salesforce Service Cloud

Spiceworks Cloud Tickets map to Salesforce Service Cloud Cases. The export provides ticket ID, summary (Case Subject), description (Case Description), status (Case Status), priority (Case Priority), creator (Contact/Requester), assignee (User), and timestamps (CreatedDate, ClosedDate). We resolve the assignee by email against Salesforce Users, falling back to name match. Priority values (low, medium, high, urgent) map to Salesforce Case Priority with a custom picklist if the destination org uses non-standard values. Ticket ID preservation is optional; we recommend skipping ID preservation to avoid conflicts with Salesforce's auto-numbering and to allow the import to run at full speed.

Spiceworks Cloud technician accounts (name, email, role) map to Salesforce User records. We resolve by email address. Inactive Spiceworks technicians are migrated as inactive Salesforce Users so that case assignment history is preserved. Any Spiceworks technician without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before case import begins. Role assignment (admin, technician) maps to Salesforce Permission Set or Profile assignment, determined during scoping.

Spiceworks Cloud Organizations map to Salesforce Account records. The export provides org name and primary contact. If the destination org uses Person Accounts for end-user organizations, we convert to that model; otherwise we create standard Business Accounts. Organization-to-Account mapping is the first phase of migration because Case records require an AccountId lookup when the requester is linked to an organization.

Spiceworks Cloud end users who submit tickets map to Salesforce Contact records. Name and email migrate directly; phone migrates if present. Deduplication is by email address, with the earliest-created Contact retained on conflict. Requesters without email addresses require manual handling and are flagged in the scoping report. If the destination org uses Person Accounts, requesters migrate to Person Account records instead.

Spiceworks Cloud Knowledge Base articles (title, body content, category assignment) map to Salesforce Knowledge articles. Article titles become Salesforce ArticleTitle; body content migrates as HTML-formatted ArticleBody. Spiceworks category assignment maps to Salesforce Data Category Groups, which we configure in the destination org before article import. We do not migrate article versioning history because Spiceworks Cloud does not export version metadata. Salesforce Knowledge must be enabled and an article type created before migration begins; this is a pre-migration configuration step.

Spiceworks Cloud ticket tags export as a list of string values. If the destination Salesforce org uses a custom multi-select picklist for tag data, we create the field before migration and populate it directly. If no tag field exists, we create a custom field sw_tag__c (TEXT 255) to store comma-separated legacy tag values as a reference field for the admin to redistribute into Salesforce Topics or a custom taxonomy post-migration.

Spiceworks Cloud custom ticket fields (string, boolean, date, number, select, multi-select) require pre-creation in the destination Salesforce org before migration. We provide a custom field mapping template during the preparation phase listing each Spiceworks custom field, its type, and the corresponding Salesforce field API name to create. Fields not pre-created are flagged at import time and either skipped or held in a correction queue. Standard Spiceworks fields that have no Salesforce equivalent (e.g., ticket type, category) are mapped to existing Case fields or custom fields per the scoping checklist.

Spiceworks Cloud's JSON export does not include attachment files directly. Community posts confirm that attachments are not exported from Cloud Help Desk to third-party destinations. We capture attachment filenames and Spiceworks-hosted URLs from the JSON export where available, re-download them if the URLs remain accessible, and upload them to Salesforce as ContentVersion records linked to the parent Case via ContentDocumentLink. If Spiceworks-hosted URLs are no longer accessible, we document each missing attachment in the handoff report with the Case number and original filename for manual retrieval.

Spiceworks Cloud's built-in JSON export does not include the full comment thread or internal notes. A Spiceworks Community post from July 2022 explicitly confirms that neither internal notes nor public comments are included in the Cloud export. We cannot migrate conversation history as a direct data operation. We flag this gap during scoping, document it in the migration checklist, and advise customers to screenshot or manually export critical conversation threads before the migration window if conversation history is required for compliance or continuity. No Salesforce object receives comment thread data because the source data is not available.

Spiceworks Cloud does not expose a reporting API. Historical ticket volume reports, SLA compliance reports, and technician performance reports cannot be extracted programmatically. We advise customers to export any required reports via Spiceworks built-in reporting or Power BI before the migration window closes. We do not migrate Spiceworks reports because there is no API to extract them; we deliver a written reference list of the reports to rebuild in Salesforce Reports & Dashboards or CRM Analytics as a post-migration task.