Helpdesk migration
Field-level mapping, validation, and rollback between LiveHelpNow and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
LiveHelpNow
Source
Salesforce Service Cloud
Destination
Compatibility
8 of 11
objects map 1:1 between LiveHelpNow and Salesforce Service Cloud.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from LiveHelpNow to Salesforce Service Cloud is a structural migration for support teams that have outgrown a budget helpdesk and need enterprise case management, Einstein AI routing, and deep CRM integration. LiveHelpNow organizes data around Conversations, Tickets, Agents, Knowledge Base articles, and Canned Responses; Salesforce Service Cloud uses Cases, Contacts, Accounts, and Omni-Channel with Skills-Based Routing. We map LiveHelpNow ticket statuses to Salesforce Case Status values, resolve operator-to-User assignments by email match, and generate a Knowledge Base article ID cross-reference table so that any embedded KB links in chat widgets or portals update to the new article IDs. Survey configurations, workforce management scheduling, and post-chat survey trigger rules are platform settings that do not export as data; we deliver a written inventory of these for the customer's admin to rebuild in Salesforce Flow or Omni-Channel. The LiveHelpNow API has no publicly documented rate limits, so we use conservative request pacing and monitor for 429 responses to avoid mid-migration interruptions.
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.
Source platform
LiveHelpNow platform overview
Scorecard, SWOT, gotchas, and pricing for LiveHelpNow.
Destination platform
Salesforce Service Cloud platform overview
Scorecard, SWOT, gotchas, and pricing for Salesforce Service Cloud.
Data migration guide
The complete Salesforce Service Cloud migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Salesforce Service Cloud migration checklist
Pre- and post-cutover tasks for moving onto Salesforce Service Cloud.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a LiveHelpNow object lands in Salesforce Service Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
LiveHelpNow
Ticket
Salesforce Service Cloud
Case
1:1LiveHelpNow Tickets map to Salesforce Cases. We map LiveHelpNow ticket status (New, Pending, Solved, Archived) to Salesforce Case Status picklist values within a configured Business Process, preserving the original ticket ID in a custom field lhn_original_id__c for reference. Priority from LiveHelpNow (Low, Normal, High, Urgent) maps to Case Priority. If LiveHelpNow tickets have custom fields, we pre-create matching Case custom fields in Salesforce before import and flag any type mismatches (date vs datetime, text vs picklist) during scoping.
LiveHelpNow
Conversation
Salesforce Service Cloud
EmailMessage + Case
1:1LiveHelpNow chat conversations migrate as EmailMessage records linked to the parent Case. The chat message content, timestamps, operator name, and customer identity populate EmailMessage fields (TextBody, FromName, FromAddress, Incoming, MessageDate). Read/unread status at the conversation level maps to a custom boolean field lhn_is_read__c since Salesforce EmailMessage does not track read state natively. The parent Case is resolved via a cross-reference lookup created during the ticket import phase.
LiveHelpNow
Knowledge Base Article
Salesforce Service Cloud
Knowledge Article
1:1LiveHelpNow KB articles migrate to Salesforce Knowledge articles with the Article Type configured in Salesforce before import. Title, body content (rich text), and category assignment transfer. We generate a cross-reference table mapping each LiveHelpNow article ID to the new Salesforce Knowledge Article Version URL Name so that any embedded KB links in chat widgets, portals, or support emails update post-migration. The customer confirms all published KB URLs during validation.
LiveHelpNow
KB Category
Salesforce Service Cloud
Data Category Group
lossyLiveHelpNow KB categories form a hierarchical folder structure. Salesforce Knowledge uses Data Category Groups and Categories for article organization. We replicate the category tree by creating Salesforce Data Category Groups before article import and assign category membership during the article migration phase so that navigation remains consistent in the Salesforce help center.
LiveHelpNow
Agent
Salesforce Service Cloud
User
1:1LiveHelpNow Agent profiles (name, email, role, queue assignments) map to Salesforce User records. We resolve agents by email match against the destination Salesforce org's User table. Any LiveHelpNow agent without a matching Salesforce User enters a reconciliation queue for the customer's admin to provision before record import resumes. LiveHelpNow role names map to Salesforce Profile and Role assignments if the customer provides the role hierarchy document during scoping.
LiveHelpNow
Canned Response
Salesforce Service Cloud
Email Template or Quick Text
lossyLiveHelpNow Canned Responses (pre-written templates organized in agent or shared folders) map to Salesforce Email Templates or Quick Text depending on use. Shared folder organization migrates as a folder structure in Salesforce. If canned responses include merge fields, we map them to Salesforce merge field syntax during the template import. Individual agent canned responses migrate as Quick Text records.
LiveHelpNow
Custom Ticket Field
Salesforce Service Cloud
Custom Case Field
1:1LiveHelpNow custom fields on tickets are extracted as a schema during discovery. We pre-create matching custom fields on the Salesforce Case object before data migration begins. Field types are matched (text to text, number to number, date to date); picklist values in LiveHelpNow map to Salesforce picklist or multi-select picklist fields with the same values. Any LiveHelpNow field without a direct Salesforce type equivalent is documented as a gap for admin resolution.
LiveHelpNow
Survey Response
Salesforce Service Cloud
Custom Case Field or Feed Item
1:1LiveHelpNow survey response data (the answers submitted) migrates as custom fields on the Case record if the survey uses a fixed set of questions. For variable or freeform surveys, response data migrates as a Case Feed Item or a custom object record linked to the parent Case. Survey question logic and trigger rules are not migratable; we deliver a written survey configuration inventory for the admin to rebuild in Salesforce.
LiveHelpNow
Tag
Salesforce Service Cloud
Topic or Case Tag
1:1LiveHelpNow tags on tickets follow a flat naming convention. Tags migrate as Salesforce Topics with TopicAssignment records linked to Cases, or as a multi-select picklist custom field on Case depending on the customer's preference during scoping. TopicAssignment preserves the flat tag names and allows the customer to use Salesforce Topics for broader content and case classification in Lightning.
LiveHelpNow
Social Channel Message
Salesforce Service Cloud
Case with Social Post
1:1Facebook, Twitter, and other social messages surface as ticket-linked conversations in LiveHelpNow. We migrate the message content and link it to the corresponding Case record. Social-specific metadata (Twitter handle, Facebook page, social channel type) migrates as custom fields on the Case or as a linked Social Post record if the destination org includes Social Customer Service features. Social post engagement metrics (likes, retweets) are preserved as custom fields since Salesforce does not update them post-migration.
LiveHelpNow
Workforce Management Data
Salesforce Service Cloud
Service Resource + Omni-Channel Capacity (configuration)
lossyLiveHelpNow scheduling, agent availability windows, and queue routing rules exist as platform configuration, not transactional data. We export workforce management settings as a written configuration inventory (queue names, operating hours, availability windows, routing rules) that the customer's Salesforce admin uses to build Omni-Channel Presence Configurations, Service Channels, and Capacity Models in Salesforce. Active scheduling configs do not migrate as functional code; the admin rebuilds the routing logic in Omni-Channel.
| LiveHelpNow | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Ticket | Case1:1 | Fully supported | |
| Conversation | EmailMessage + Case1:1 | Fully supported | |
| Knowledge Base Article | Knowledge Article1:1 | Fully supported | |
| KB Category | Data Category Grouplossy | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Canned Response | Email Template or Quick Textlossy | Fully supported | |
| Custom Ticket Field | Custom Case Field1:1 | Fully supported | |
| Survey Response | Custom Case Field or Feed Item1:1 | Fully supported | |
| Tag | Topic or Case Tag1:1 | Fully supported | |
| Social Channel Message | Case with Social Post1:1 | Fully supported | |
| Workforce Management Data | Service Resource + Omni-Channel Capacity (configuration)lossy | Mapping required |
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.
LiveHelpNow gotchas
Cloudflare infrastructure dependency causes silent service outages
API rate limits are not publicly documented
Survey configurations do not export as logic
Knowledge base article IDs do not persist across export/import
Salesforce Service Cloud gotchas
Data Export 512MB file size cap breaks large org exports
API Daily Request Limits vary by license edition
No automatic data backup in base Salesforce
Picklist dependencies silently break records when unmapped
Workflow rules fire unexpectedly during data load
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the LiveHelpNow account across tiers (Essential/Professional/Premium), ticket volume, conversation count, Knowledge Base article count, agent count, active canned response folders, and any custom ticket field schemas. We review the destination Salesforce org for existing Case object configuration, Business Processes, Record Types, Omni-Channel routing setup, and active validation rules. The discovery output is a written migration scope document with object counts, a preliminary mapping table, and a Salesforce edition recommendation if the customer does not already have Service Cloud provisioned.
Schema pre-creation in Salesforce
We create the destination schema in Salesforce before any data migration begins. This includes provisioning custom fields on Case (matching LiveHelpNow custom ticket field types), creating Salesforce Knowledge Article Types and Data Category Groups, configuring Omni-Channel Presence Configurations and Service Channels, and creating folder structures for Email Templates mapped from LiveHelpNow canned responses. Schema is deployed to a Salesforce Sandbox first for validation and signed off by the customer's Salesforce admin before production migration begins.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's support operations lead reconciles record counts (Cases in, Knowledge Articles in, Agents mapped to Users, Email Templates in), spot-checks 25-50 random records against the LiveHelpNow source, and signs off the schema and mapping before production migration begins. The Knowledge Base cross-reference table is validated here so that embedded link updates can be planned before production cutover.
Agent-to-User reconciliation
We extract every distinct LiveHelpNow operator referenced on Tickets, Conversations, and Canned Responses and match by email against the destination Salesforce org's User table. Any LiveHelpNow operator without a matching Salesforce User enters a reconciliation queue. The customer's Salesforce admin provisions any missing Users (active or inactive depending on whether the original operator is still active). Migration cannot proceed past this step because OwnerId references are required on Cases and Article Assignments.
Production migration in dependency order
We run production migration in record-dependency order: Salesforce Knowledge Data Category Groups (folder structure), Knowledge Articles (with cross-reference table generated), Users (manually provisioned and validated), Cases (with LiveHelpNow ticket ID preserved in lhn_original_id__c), Email Messages (linked to parent Cases), Tags (via TopicAssignment), Custom Field data, Canned Responses (as Email Templates or Quick Text), Social messages (linked to Cases), and Survey Responses (as custom fields or Feed Items). Each phase emits a row-count reconciliation report before the next phase begins. We pace requests conservatively against the LiveHelpNow API and monitor for 429 responses to avoid mid-migration interruptions.
Cutover, validation, and configuration handoff
We freeze LiveHelpNow writes during cutover, run a final delta migration of any records modified during the migration window, then deliver the Knowledge Base cross-reference table, the survey configuration inventory, and the workforce management settings document to the customer's admin team. We support a one-week hypercare window where we resolve any reconciliation issues raised by the support team. We do not rebuild LiveHelpNow queue routing as Omni-Channel Skills-Based Routing inside the migration scope; that is a separate configuration engagement or an internal admin task.
Platform deep dives
LiveHelpNow
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across LiveHelpNow and Salesforce Service Cloud.
Object compatibility
1 of 7 objects need a manual workaround.
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
LiveHelpNow: Not publicly documented.
Data volume sensitivity
LiveHelpNow doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 LiveHelpNow to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your LiveHelpNow to Salesforce Service Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave LiveHelpNow
Other ways to arrive at Salesforce Service Cloud
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.