Helpdesk migration

Migrate from LiveHelpNow to Salesforce Service Cloud

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 logo

LiveHelpNow

Source

Salesforce Service Cloud

Destination

Salesforce Service Cloud logo

Compatibility

73%

8 of 11

objects map 1:1 between LiveHelpNow and Salesforce Service Cloud.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

LiveHelpNow logo

LiveHelpNow

What's pushing teams away

  • Aggressive post-chat survey prompts frustrate customers — multiple reviews note that survey invitations feel intrusive and reduce the perceived quality of the support interaction.
  • Platform lacks depth for complex enterprise workflows — teams with advanced routing needs, SLAs, or multi-brand support outgrow the feature set and migrate to Zendesk or Salesforce.
  • AI features feel bolted-on rather than integrated — Hue AI is packaged as a separate add-on tier, and early adopters report the agent assist suggestions lack context awareness.
  • Limited API documentation makes third-party integrations feel fragile — developers building custom hooks report unclear endpoint behavior and inconsistent error responses.
  • Chat window customization options are rigid for mid-market brands — teams wanting granular control over chat button placement and proactive invitation triggers find the options limiting.

Choosing

Salesforce Service Cloud logo

Salesforce Service Cloud

What's pulling them in

  • Deep Salesforce ecosystem integration with Sales Cloud, Marketing Cloud, and custom Apex apps creates a single pane of glass for enterprise customer data and cross-functional workflows.
  • Omnichannel case routing — email, chat, phone, social, and messaging — unified under one case object means agents do not lose context when customers switch channels mid-interaction.
  • AI for customer service (Einstein AI / Agentforce) offers automated case classification, suggested replies, and chatbot routing that reduces Tier-1 ticket volume without manual rule authoring.
  • Entitlement and milestone tracking enforces SLA compliance natively, automatically calculating breach windows and surfacing violations to supervisors in dashboards.
  • Salesforce's massive AppExchange ecosystem provides pre-built connectors, industry-specific managed packages, and third-party tools that extend Service Cloud beyond its out-of-box capabilities.

Object mapping

How LiveHelpNow objects map to Salesforce Service Cloud

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

maps to

Salesforce Service Cloud

Case

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

EmailMessage + Case

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Knowledge Article

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Data Category Group

lossy
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

User

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Email Template or Quick Text

lossy
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Custom Case Field

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Custom Case Field or Feed Item

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Topic or Case Tag

1:1
Fully supported

LiveHelpNow 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

maps to

Salesforce Service Cloud

Case with Social Post

1:1
Fully supported

Facebook, 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

maps to

Salesforce Service Cloud

Service Resource + Omni-Channel Capacity (configuration)

lossy
Mapping required

LiveHelpNow 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.

Gotchas + challenges

What specifically takes care here

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 logo

LiveHelpNow gotchas

High

Cloudflare infrastructure dependency causes silent service outages

Medium

API rate limits are not publicly documented

Medium

Survey configurations do not export as logic

Low

Knowledge base article IDs do not persist across export/import

Salesforce Service Cloud logo

Salesforce Service Cloud gotchas

High

Data Export 512MB file size cap breaks large org exports

High

API Daily Request Limits vary by license edition

High

No automatic data backup in base Salesforce

Medium

Picklist dependencies silently break records when unmapped

Medium

Workflow rules fire unexpectedly during data load

Pair-specific challenges

  • Knowledge Base article IDs change on import and break embedded links

    LiveHelpNow assigns internal numeric IDs to knowledge base articles. When we export and import to Salesforce, new Knowledge Article Version records receive new URL Name values. Any embedded link in a chat widget, a portal page, or a canned response pointing to the old LiveHelpNow KB URL becomes invalid after migration. We generate a full cross-reference table mapping each LiveHelpNow article ID to the new Salesforce Knowledge Article Version URL Name and provide a SQL-like update script for the customer's admin to run against their chat widget configurations and portal content. This is a manual step requiring customer confirmation of all published KB URLs during validation.

  • LiveHelpNow API has no published rate limits, increasing migration duration

    LiveHelpNow does not publish API rate limit thresholds in any developer-facing documentation. This means migration tooling must make conservative assumptions about safe request frequency. We start with a low request rate, monitor for 429 responses, and dynamically adjust pacing. Large ticket exports and chat transcript batches take longer than expected as a result. We recommend scheduling migration windows during off-peak hours and avoiding data-heavy phases during known LiveHelpNow maintenance windows.

  • Survey configurations do not migrate as logic

    Post-chat and post-ticket survey questions, triggers, and routing rules in LiveHelpNow exist as platform configuration settings, not as data records. We export survey response data (the submitted answers) but cannot export the survey design itself. Customers must rebuild survey triggers in Salesforce using Flow or Omni-Channel. This can introduce a gap in customer feedback coverage during the transition period. We deliver a written survey configuration inventory listing each survey, its trigger conditions, its questions, and recommended Salesforce equivalents.

  • Chat transcript fidelity is limited by the EmailMessage object

    LiveHelpNow chat conversations contain rich metadata (typing indicators, file attachments mid-conversation, read receipts, operator switching) that does not map cleanly to the Salesforce EmailMessage object. We migrate message content, timestamps, operator name, and customer identity with full fidelity. However, chat-specific metadata (file attachments sent during chat, operator switching events, typing indicators) cannot be preserved in Salesforce's standard activity model without custom development. We document these gaps in the migration validation report.

  • Validation rules and field-level security block import if not coordinated

    Salesforce orgs commonly enforce validation rules on Case (required formats, conditional requireds, picklist whitelists) and field-level security that can cause importing records to fail silently or partially. We coordinate with the customer's Salesforce admin to grant the migration user Modify All Data and Bulk API permissions, and we either temporarily disable validation rules during load or extend them with a migration-context bypass. Skipping this step typically results in 5-20 percent record rejection on the first import attempt, requiring a second pass.

Migration approach

Six steps for a successful LiveHelpNow to Salesforce Service Cloud data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

LiveHelpNow logo

LiveHelpNow

Source

Strengths

  • Live chat, ticketing, knowledge base, and chatbots in a single integrated workspace without requiring third-party integrations.
  • Professional tier includes call logging and Zoom phone integration for routing without needing a separate telephony provider.
  • Survey and canned response tools are deep and customizable without requiring technical skills to configure.
  • Analytics dashboards and KPI reporting included at every paid tier rather than gated behind an enterprise add-on.

Weaknesses

  • Cloudflare dependency creates outage risk — the November 2025 and November 2021 service interruptions both traced to Cloudflare, not LiveHelpNow infrastructure.
  • API is not publicly documented with a developer portal, making custom integrations and automated migration pipelines difficult to build and maintain.
  • AI features are packaged as a separate paid add-on tier (Hue AI) rather than integrated into core workflows, increasing total cost at scale.
  • No published rate limit documentation means migration tooling must guess at safe request throttling, increasing migration duration.
  • Limited enterprise features — no multi-brand support, no granular SLA configuration, no advanced workforce optimization — cause mid-market teams to outgrow the platform.
Salesforce Service Cloud logo

Salesforce Service Cloud

Destination

Strengths

  • Enterprise-grade security, compliance certifications, and audit logging available across all paid editions with Shield offering enhanced event monitoring.
  • Scalable multi-tenant cloud architecture supporting orgs from 5 users to 150,000+ seat enterprises without infrastructure management overhead.
  • Omnichannel contact center unifying email, live chat, phone, messaging, and social into a single Case timeline per customer interaction.
  • Rich workflow automation via Salesforce Flow, Process Builder, and Apex triggers enabling complex case escalation, routing, and field updates.
  • Native AI capabilities (Agentforce / Einstein) for case auto-routing, classification, suggested responses, and chatbot escalation without third-party add-ons.

Weaknesses

  • Per-seat pricing model with no contact limits creates unpredictable cost scaling for large organizations adding many agents over time.
  • No automatic data backup — organizations must purchase a third-party backup solution or build manual Data Loader exports to protect against data loss from human error, failed deployments, or integrations overwriting records.
  • Steep learning curve for non-technical users requiring dedicated admin resources and formal training investment before teams reach productive velocity.
  • Annual contract requirements and limited pro-ration on exit create significant switching cost friction, especially for organizations evaluating alternatives mid-cycle.
  • Add-on licensing (CPQ, Einstein Activity Capture, Shield, Data Cloud) can double effective per-seat cost without clear documentation of which features are included in base tiers.

Complexity grading

How hard is this migration?

Standard Helpdesk migration. 1 of 7 objects need a manual workaround.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across LiveHelpNow and Salesforce Service Cloud.

  • Object compatibility

    B

    1 of 7 objects need a manual workaround.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    7-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    LiveHelpNow: Not publicly documented.

  • Data volume sensitivity

    B

    LiveHelpNow doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your LiveHelpNow to Salesforce Service Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about LiveHelpNow to Salesforce Service Cloud data migrations

Answers to the questions buyers ask most during LiveHelpNow to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between three and five weeks for accounts under 10,000 tickets, 50,000 chat message records, and 500 Knowledge Base articles. Migrations with large historical chat archives, multiple custom ticket fields, multi-queue routing reconstruction, or Knowledge Base counts above 500 move to eight to twelve weeks because of conservative API pacing on the LiveHelpNow side and the Omni-Channel configuration scope on the Salesforce side.

Adjacent paths

Related migrations to explore

Ready when you are

Move from LiveHelpNow.
Land in Salesforce Service Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day