Helpdesk migration

Migrate from Salesforce Service Cloud to Gorgias

Field-level mapping, validation, and rollback between Salesforce Service Cloud and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.

Salesforce Service Cloud logo

Salesforce Service Cloud

Source

Gorgias

Destination

Gorgias logo

Compatibility

67%

10 of 15

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

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Try the reverse

Gorgias
Salesforce Service Cloud

Overview

What this migration involves

Moving from Salesforce Service Cloud to Gorgias is a schema simplification, not a field-for-field copy. Salesforce organizes data around Cases linked to Contacts, Accounts, Entitlements, Milestones, and EmailMessages in a multi-object relational graph; Gorgias uses a flat Ticket object with embedded Customer profiles and conversation threads. We resolve that structural difference during scoping, collapsing the case-child hierarchy into Gorgias ticket conversations while preserving entitlement timestamps, case origin channels, and historical SLA compliance data. We do not migrate Salesforce Flows, Entitlement Processes, or Case Milestones as live automation — these require rebuild in Gorgias Rules and Macros, and we deliver a written inventory of every active flow and SLA rule for the customer's admin to reconstruct. E-commerce teams on Shopify and BigCommerce find the sharpest fit because Gorgias's native order-lookup and refund-action sidebar requires no custom integration.

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

Salesforce Service Cloud logo

Salesforce Service Cloud

What's pushing teams away

  • The total cost of ownership远超 base license pricing — storage overages at $125/GB, Agentforce consumption charges at $2 per conversation, and 8–10% annual contract uplifts compound into a 30–40% true-cost premium over sticker price.
  • Complexity of configuration makes basic admin tasks requiring a Salesforce consultant, creating dependency on external expertise for changes that should be self-service, especially for mid-market teams.
  • API rate limits on lower-tier editions throttle integrations and bulk exports, forcing teams to batch operations or purchase higher licenses just to run nightly sync jobs reliably.
  • Steep learning curve and unintuitive UX for non-power-users causes low agent adoption, leading to shadow IT in the form of spreadsheets and informal tools that undermine the central case record.
  • Annual contract lock-in with no pro-rated exit creates switching cost pressure, making migrations feel high-stakes and expensive even when the platform no longer fits the team's operational model.

Choosing

Gorgias logo

Gorgias

What's pulling them in

  • Shopify-native integrations pull order details, shipment status, and return data directly into the ticket view, eliminating the need for agents to switch between apps.
  • Unlimited user seats mean growing support teams do not trigger billing changes; pricing scales only on billable ticket volume.
  • AI Agent automates responses to high-volume queries like order status and returns, measurably reducing the number of billable tickets each month.
  • Omnichannel inbox consolidates email, live chat, Facebook, Instagram, WhatsApp, SMS, and voice into a single threaded view.
  • SOC 2 Type II certification and GDPR-aligned data handling satisfy enterprise procurement requirements for customer support platforms.

Object mapping

How Salesforce Service Cloud objects map to Gorgias

Each row shows how a Salesforce Service Cloud object lands in Gorgias, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Salesforce Service Cloud

Case

maps to

Gorgias

Ticket

1:1
Fully supported

Salesforce Cases map to Gorgias Tickets as the primary record. We map CaseNumber to Gorgias ticket ID, Subject to ticket subject, Description to ticket body, Origin to channel (email/chat/social mapped to Gorgias channel enum), Status to ticket status (Open, Pending, Resolved, Closed), and Priority to ticket priority. The Salesforce Case.AccountId relationship resolves to the Gorgias Customer record. Salesforce RecordType maps to Gorgias ticket Tags or a custom ticket field if the customer needs multi-department case type distinction. Parent cases and sub-cases collapse into Gorgias linked tickets or a custom field depending on the customer's operational model.

Salesforce Service Cloud

Contact

maps to

Gorgias

Customer

1:1
Fully supported

Salesforce Contacts merge into Gorgias Customer records. We map Contact.Email to Customer email (the dedupe key), Contact.FirstName and LastName to Customer name, Contact.Phone to Customer phone, and Contact.Address fields to Customer address. The Salesforce Contact-to-Account relationship collapses because Gorgias does not maintain a separate Account object; Account name and domain become Customer attributes. If the organization uses Partner Contact roles or shared mailboxes, we map those to Gorgias additional addresses on the Customer record.

Salesforce Service Cloud

Account

maps to

Gorgias

Customer (attribute merge)

many:1
Fully supported

Salesforce Accounts attach organization-level data (Industry, Type, AnnualRevenue, NumberOfEmployees, BillingAddress) to the Customer record in Gorgias. We merge Account fields into the Customer object as custom attributes. Hierarchical Account structures (Parent Account) do not have a direct Gorgias equivalent; we flatten parent-child relationships into a single Customer record and flag the Account hierarchy for the customer's admin to model in Gorgias Tags or a custom attribute if business logic depends on it.

Salesforce Service Cloud

CaseComment

maps to

Gorgias

Ticket conversation message

1:many
Fully supported

Salesforce Case Comments (both public and private, distinguished by IsPublished) map to Gorgias ticket conversation messages. Public comments migrate as customer or agent messages based on the CreatedById type; private comments migrate as internal notes attached to the ticket. Rich-text formatting in CaseComment.CommentBody sanitizes to plain text with HTML preserved where the destination renders it. If the customer requires private-comment visibility in Gorgias, internal notes serve that function without a separate migration path.

Salesforce Service Cloud

EmailMessage

maps to

Gorgias

Ticket conversation message

1:1
Fully supported

Salesforce EmailMessage records on Cases migrate to Gorgias ticket conversation messages. We map Subject, TextBody, HtmlBody (sanitized), FromName, FromAddress, ToAddress, CcAddress, and BccAddress. Email direction (Incoming/Outgoing) maps to Gorgias message direction. Attachments on EmailMessage extract separately and link to the Gorgias message via the attachment API. The Salesforce EmailMessage parent Case relationship resolves to the migrated ticket ID at migration time.

Salesforce Service Cloud

Entitlement

maps to

Gorgias

SLA rule (configuration only)

lossy
Fully supported

Salesforce Entitlements define SLA terms (response time, resolution time, business hours) and are linked to Contacts and Accounts. Gorgias SLA rules provide response and resolution targets but do not preserve historical breach state or remaining time. We do not migrate Entitlement records as data; instead, we deliver a written inventory of every Entitlement Process and Milestone Type with its terms (first response time, case resolution time, business hours ID), and the customer's admin configures corresponding Gorgias SLA rules from that document. SLA compliance history (breached vs met) does not migrate as a field.

Salesforce Service Cloud

CaseMilestone

maps to

Gorgias

SLA compliance history (not migrated live)

lossy
Fully supported

Salesforce CaseMilestone records track SLA breach windows (RemainingTime, CompletionDate, MilestoneType) tied to Entitlements. Gorgias does not have an equivalent milestone object. We preserve milestone completion data as a custom Ticket attribute (e.g., sla_first_response_met__c boolean) derived from the Salesforce milestone timestamp at migration time, and we flag any open (uncompleted) milestones as tickets requiring follow-up in the SLA inventory document. This is a data snapshot, not a live automation migration.

Salesforce Service Cloud

Case Team Members

maps to

Gorgias

Ticket assignee or Tag (configuration)

1:1
Mapping required

Salesforce CaseTeamMember records assign roles to Users on individual Cases. Gorgias does not have a native case team concept. We map CaseTeamMember roles to Gorgias ticket Assignee or to a Tag prefixed with the team role (e.g., tag:escalation-tier2). If the original Salesforce case has multiple assigned team members beyond the primary owner, we add them as Tags or internal notes documenting the full team roster. Customers with complex multi-agent case ownership receive a written recommendation for Gorgias Views and routing rules to approximate the team model.

Salesforce Service Cloud

CaseHistory

maps to

Gorgias

Ticket event log (custom attribute)

1:1
Fully supported

Salesforce CaseHistory tracks field-level audit changes (Field, OldValue, NewValue, CreatedDate). Gorgias does not have a native audit trail object for field changes. We migrate CaseHistory as a structured text attribute on the ticket (ticket_history__c) containing a chronological list of field changes, or as internal notes in the ticket conversation for the most recent significant status transitions (Status, Priority, Owner). Full field-level audit history is documented in the migration handoff for the customer's admin to reference.

Salesforce Service Cloud

KnowledgeArticle

maps to

Gorgias

Help Center article

1:1
Fully supported

Salesforce Knowledge Articles (with ArticleType variants: FAQ, Article, HowTo, Troubleshooting) migrate to Gorgias Help Center articles. We map Title, Summary, UrlName, and Body (with rich text sanitization). Article Version data (Language, VersionNumber, Status) maps to article version and publish state in Gorgias. Article Categories migrate to Gorgias Help Center categories. If the customer uses Salesforce Data Categories for article taxonomy, we map those to Gorgias Help Center sections and recommend rebuilding the category hierarchy post-migration.

Salesforce Service Cloud

Solution

maps to

Gorgias

Help Center article

1:1
Fully supported

Salesforce Solutions (reusable knowledge articles linked to Cases) migrate to Gorgias Help Center articles. We map Solution.Title to article title, Solution.Body to article body, and Solution.Status to publish state. If the customer uses Solutions alongside Knowledge Articles, we recommend merging both into the Gorgias Help Center with a Solution/Article tag distinction. Solution attachments migrate as article attachments via Gorgias's media upload API.

Salesforce Service Cloud

Asset

maps to

Gorgias

Customer attribute (custom field)

1:many
Fully supported

Salesforce Assets represent products purchased by an Account with install date, status, and product relationship. Gorgias does not have a native Asset object. We migrate Asset name, status, and install date as custom attributes on the Customer record (e.g., asset_product_name__c, asset_status__c). If the customer relies on Asset-to-Case linkage for warranty and entitlement lookups, we document the relationship and recommend a post-migration configuration using Gorgias Customer attributes and a linked product catalog if needed.

Salesforce Service Cloud

Custom Object

maps to

Gorgias

Custom Object

1:1
Fully supported

Salesforce Custom Objects (API name ending in __c) with lookup relationships to Case, Contact, or Account migrate to Gorgias custom objects or custom ticket attributes depending on complexity. We pre-create the destination schema during scoping, including custom ticket fields for flat properties and related records for lookup-heavy custom objects. If the custom object has no Gorgias equivalent, we recommend a third-party data store or a rebuild in Gorgias's customer attribute model. API naming conventions preserve the __c suffix in the migration mapping document.

Salesforce Service Cloud

User

maps to

Gorgias

Agent (Gorgias team member)

1:1
Fully supported

Salesforce Users (agents and admins) map to Gorgias Agents by email match. We extract every Salesforce User referenced as Case.OwnerId and map to a Gorgias agent account. Inactive Salesforce Users migrate as inactive Gorgias agents (or archived) depending on the customer's retention policy for historical assignment. If the organization uses Salesforce Profiles and Roles for permission scoping, Gorgias's team permission model (Admin, Agent, Superviewer) replaces those — we document the profile-to-role mapping as part of the handoff.

Salesforce Service Cloud

Tags

maps to

Gorgias

Tags

1:1
Not supported

Salesforce Topics for Cases (the lightweight taxonomy object) map to Gorgias Tags. We extract Case.Tags and map directly to Gorgias tag names. If Salesforce uses tag groups (Topics for Objects), we preserve the group prefix in the tag name (e.g., region:EMEA becomes tag:region-EMEA) and document the taxonomy mapping for the admin to restructure in Gorgias.

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.

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

Gorgias logo

Gorgias gotchas

High

AI Agent adds outcome-based fees on top of billable ticket costs

High

Overage billing for tickets scales nonlinearly

Medium

API rate limits restrict bulk export throughput

Medium

Agent data visibility cannot be restricted by role for GDPR use cases

Low

Knowledge Base translations require separate API calls per locale

Pair-specific challenges

  • Salesforce Entitlements and Case Milestones do not migrate as live SLA automation

    Gorgias has SLA rules (response time, resolution time, business hours) but no equivalent to Salesforce's CaseMilestone object that tracks RemainingTime, milestone completion timestamps, and breach state per individual case. We cannot migrate Entitlement records and active milestone timers as live data — a case with 45 minutes of SLA breach time remaining does not become a live countdown in Gorgias. We preserve milestone completion data as a custom ticket attribute snapshot at migration time, deliver a written inventory of every Entitlement Process and Milestone Type for the admin to configure in Gorgias SLA rules, and flag any cases with open SLA breaches as requiring immediate review post-migration. Teams that rely heavily on SLA enforcement must plan for manual SLA configuration in Gorgias before go-live.

  • Salesforce Flows and Apex triggers do not migrate to Gorgias Rules

    Salesforce Flow (record-triggered, scheduled, screen) and Apex trigger-based automations are architecturally incompatible with Gorgias Rules and Macros. A Salesforce Flow that escalates cases based on entitlement tier, creates follow-up tasks on case close, or updates Account fields from case data cannot be translated automatically to a Gorgias rule. We do not migrate Flows as code. We deliver a written inventory of every active Salesforce Flow with its trigger, conditions, actions, and a recommended Gorgias Rule equivalent, and the customer's admin rebuilds them in Gorgias's visual rule builder post-migration. This is one of the highest-scope items in Service Cloud to Gorgias migrations and should not be underestimated during planning.

  • API daily request limits on Salesforce Enterprise and below throttle large exports

    Salesforce Enterprise Edition caps API requests at 100,000 per 24-hour rolling window. When an org has active integrations (Outlook sync, Slack connectors, other CRM apps), API headroom for migration extraction shrinks. We audit API consumption during scoping and schedule migration passes during off-peak hours. For orgs exceeding the daily limit, we split extractions by date range or record type across multiple nights. Failure to account for this results in REQUEST_LIMIT_EXCEEDED failures mid-job, causing incomplete exports and silent record truncation.

  • Dependent picklists silently break records when values are unmapped

    Salesforce dependent picklists enforce value relationships — a Country picklist gates a State picklist, for example. When migrating to Gorgias, which has a flat attribute model, naive value translation can land records with unrecognized picklist combinations or silently skip records with values not in the Gorgias field's allowed list. We review all picklist dependencies during field mapping, generate a picklist value translation table before any records load, and resolve unmapped values to a default or open-text field. Without this step, customer segmentation and routing logic in Gorgias built on migrated picklist data will produce incorrect results.

  • E-commerce order context in Salesforce requires separate Shopify integration rebuild

    Teams that migrated to Salesforce Service Cloud and built Shopify or BigCommerce order lookups through custom integrations or AppExchange packages will lose that context when moving to Gorgias. Gorgias's native Shopify sidebar provides order lookups, refunds, cancellations, and return initiation without additional configuration, but the historical order data visible in the migrated Salesforce Cases (typically pulled via custom fields or related objects) must be reconnected to Gorgias through the native Shopify integration setup. We map the existing Salesforce order-reference fields to Gorgias Customer attributes during migration and flag the Shopify integration reconnection as a post-migration setup step rather than a data migration step.

Migration approach

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

  1. Discovery and scope definition

    We audit the source Salesforce org across edition (Starter Suite through Einstein 1 Service), active Case record types, custom objects, Entitlement processes, Milestone types, active Flows, picklist dependencies, and engagement volume. We pair this with a Gorgias plan recommendation based on ticket volume and e-commerce platform (Shopify, BigCommerce, Magento, or non-e-commerce). The discovery output is a written migration scope document identifying every object, automation, and SLA rule requiring attention, plus a decision tree for Entitlement-to-SLA mapping and Flow-to-Rule inventory scope.

  2. Schema design and picklist translation table

    We design the destination Gorgias schema: ticket fields mapped from Salesforce Case fields, Customer attributes from Contact and Account fields, Help Center categories from Salesforce Knowledge categories, and custom ticket fields for SLA snapshot data (milestone completion state) and any flat Custom Object properties. We build the Salesforce-to-Gorgias picklist value translation table covering all dependent picklists, and we run a validation pass against the Salesforce data to flag any unmapped values before migration begins. Schema is validated in a Gorgias staging environment before production.

  3. Staging migration and reconciliation

    We run a full migration into the Gorgias staging environment using production-equivalent data volume. The customer's CX lead reconciles record counts (Tickets in, Customers in, Help Center articles in), spot-checks 25-50 tickets against the Salesforce source for field accuracy, and reviews the SLA compliance snapshot and Flow inventory document. Any mapping corrections — picklist values, field assignments, entitlement-to-SLA assignments — happen in staging, not production. This step is required before any production migration begins.

  4. Owner and agent reconciliation

    We extract every distinct Salesforce User referenced as Case.OwnerId and match by email against the Gorgias destination's agent list. Any Salesforce User without a matching Gorgias agent account goes to a reconciliation queue. The customer's admin provisions missing agents and assigns appropriate Gorgias permission levels (Admin, Agent, Supervisor) based on the Salesforce Profile and Role mapping document we deliver. Migration cannot proceed past ticket import until all OwnerId references are satisfied.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Help Center articles (Knowledge Articles and Solutions), Customers (from Salesforce Contacts and Accounts merged), Tickets (Cases with EmailMessages and CaseComments resolved to conversation threads), SLA compliance snapshots (milestone completion state as custom ticket fields), Custom Object data (flat properties as custom ticket attributes), and Tags (from Salesforce Topics). Each phase emits a row-count reconciliation report before the next phase begins. We schedule large-volume EmailMessage batches during off-peak hours to stay within the Salesforce API daily limit.

  6. Cutover, SLA configuration handoff, and Flow inventory delivery

    We freeze Salesforce Case writes during cutover, run a final delta migration of any records modified during the migration window, then enable Gorgias as the system of record. We deliver the Entitlement and SLA configuration inventory document and the Flow and Apex trigger rebuild guide 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 configure Gorgias SLA rules, Rules, or Macros as part of the migration scope; those are separate configuration engagements handled by the customer's admin or a Gorgias implementation partner.

Platform deep dives

Context on both ends of the pair

Salesforce Service Cloud logo

Salesforce Service Cloud

Source

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.
Gorgias logo

Gorgias

Destination

Strengths

  • Shopify and BigCommerce integrations surface order, return, and shipment data natively inside every ticket.
  • Unlimited agent seats remove per-user licensing friction as support teams grow.
  • AI Agent reduces billable ticket volume through automated resolution of high-frequency queries.
  • SOC 2 Type II certified with GDPR-aligned data handling for enterprise procurement readiness.
  • Omnichannel inbox aggregates email, live chat, Facebook, Instagram, WhatsApp, SMS, and voice into a single threaded view.

Weaknesses

  • Ticket-volume pricing with overage fees creates unpredictable monthly costs during seasonal traffic spikes.
  • Custom reporting is shallow; raw event-level data export for BI tooling is not natively supported.
  • Knowledge Base, Macros, and Rules lack simple export tooling, making competitive migrations complex.
  • GDPR compliance limitations mean customer data cannot be hidden from agents by role, blocking use by teams with freelance staff.
  • Performance and glitch reports emerge in G2 reviews at higher ticket volumes.

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 Salesforce Service Cloud and Gorgias.

  • Object compatibility

    C

    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

    Salesforce Service Cloud: 100,000 API requests/day on Enterprise (rolling 24-hour window); lower limits on Professional and Starter editions. Concurrent API limits cap simultaneous long-running requests separately..

  • Data volume sensitivity

    A

    Salesforce Service Cloud exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Salesforce Service Cloud to Gorgias 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 Salesforce Service Cloud to Gorgias data migrations

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

Can't find your answer?

Walk through your Salesforce Service Cloud to Gorgias 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 organizations under 20,000 Cases and 10,000 Contacts with no Custom Objects and no Entitlement-to-SLA mapping complexity. Migrations with active Case Milestones, large EmailMessage histories (over 300,000 records), multiple Salesforce Custom Objects, or complex picklist dependencies move to eight to twelve weeks because of milestone timestamp resolution, parent-child relationship reconstruction, and picklist value translation work.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Salesforce Service Cloud.
Land in Gorgias, 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