Helpdesk migration

Migrate from Thulium to Gorgias

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

Thulium logo

Thulium

Source

Gorgias

Destination

Gorgias logo

Compatibility

58%

7 of 12

objects map 1:1 between Thulium and Gorgias.

Complexity

CModerate

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Thulium to Gorgias is a shift from a CRM-native helpdesk model to a Shopify-native customer experience platform. Thulium stores customer service data across Cases, Contacts, Companies, and embedded Conversations with a flexible CRM custom field schema (nine field types including list, yes/no, date, numeric, and email); Gorgias uses a Ticket-Customer structure with a different custom field type model and no native CRM Company object at its core. We extract Cases with their flattened conversation timelines, Contacts with their CRM custom field values, and Agents as Gorgias users, applying field-type mapping where Thulium's list, yes/no, and date field types do not map directly to Gorgias field types. We do not migrate automations, macros, or Rules as code; we deliver a written inventory of every Thulium workflow and automation for the customer's admin to rebuild in Gorgias. Attachment handling differs by import method—Gorgias does not attach files via CSV import, so we re-upload attachments through the Gorgias REST API after the primary record migration.

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

Thulium logo

Thulium

What's pushing teams away

  • Limited platform recognition outside Europe makes it harder to find Thulium-experienced consultants or replacement talent compared to global brands like Zendesk.
  • Smaller ecosystem of third-party integrations compared to larger helpdesk platforms limits connectivity to niche business tools.
  • Lack of publicly documented API rate limits and bulk export endpoints makes programmatic data extraction uncertain for technical teams.
  • Teams requiring advanced AI features may outgrow Thulium's capabilities as customer service expectations escalate with generative AI adoption.

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 Thulium objects map to Gorgias

Each row shows how a Thulium 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.

Thulium

Case

maps to

Gorgias

Ticket

1:1
Fully supported

Thulium Cases map directly to Gorgias Tickets as the primary support record. Each Case carries a status (open, pending, resolved, closed), priority, and assignee. We extract the conversation history embedded within the Case (email, chat, and voice sub-objects), flatten it into a linear chronological message thread on the Gorgias Ticket, and preserve the original timestamp on each message. Case channel type maps to the Gorgias channel field (email, chat, phone). If Thulium uses custom status labels, we apply a status mapping table during the transform phase.

Thulium

Contact

maps to

Gorgias

Customer

1:1
Fully supported

Thulium CRM Contacts (name, email, phone, and custom field values) map to Gorgias Customer records. The Thulium contact email serves as the dedupe key during import. Thulium CRM custom field values attached to a Contact migrate to the corresponding Gorgias Customer custom field; where the field type differs (e.g., Thulium list or yes/no to a Gorgias text field), we apply a value-mapping table at transform time to preserve the data as readable text rather than a raw value code.

Thulium

Company

maps to

Gorgias

Customer (organization attribute)

1:1
Fully supported

Thulium Companies (organizational name, address, and Company-level custom fields) map to the organization attribute on the Gorgias Customer record. We link each Thulium Contact to its parent Company via a lookup resolution step before inserting the Customer record in Gorgias. If Gorgias is on a plan without organization fields, we map Company data to a Customer-level custom text field to preserve the account context.

Thulium

Conversation

maps to

Gorgias

Ticket Message

lossy
Fully supported

Individual email, chat, and voice interactions stored as sub-objects within a Thulium Case are flattened into a chronological message thread within the corresponding Gorgias Ticket. Each message carries the sender (agent or customer), channel, timestamp, and message body. Internal notes from Thulium map to private internal messages in Gorgias. We preserve the original message timestamp and author so the full conversation chronology is intact in Gorgias.

Thulium

Agent

maps to

Gorgias

User (Agent)

1:1
Fully supported

Thulium Agents (user accounts assigned to Cases and Companies) map to Gorgias User records. We resolve each Agent by email match against the Gorgias destination. Any Thulium Agent not yet provisioned in Gorgias is held in a reconciliation queue while the customer's admin creates the corresponding User account. Agent role assignments (admin, supervisor, agent) map to Gorgias permission groups where applicable.

Thulium

Custom Fields (CRM)

maps to

Gorgias

Custom Fields (Customer/Ticket)

1:1
Fully supported

Thulium CRM custom fields on Contacts and Companies require type-aware mapping before import into Gorgias. Thulium field types map as follows: text and large text map to Gorgias text fields; numeric maps to Gorgias number fields; date maps to Gorgias date fields; email maps to Gorgias text with email validation applied; link maps to Gorgias URL fields; list maps to Gorgias text (list values serialized as comma-separated text); yes/no maps to Gorgias text with a true/false value. We build a per-field mapping table during scoping and apply it at transform time to preserve data fidelity.

Thulium

Tag

maps to

Gorgias

Tag

1:1
Fully supported

Thulium Tags applied to Cases for categorization map directly to Gorgias Tags. We apply a value-mapping table for any naming differences between Thulium tag names and the target tag names in Gorgias. Tags with identical names in both platforms match automatically. Tags with different names require explicit mapping during the transform phase.

Thulium

Attachment

maps to

Gorgias

Attachment

lossy
Fully supported

Files attached to Thulium Cases or Contacts are exported with original filenames preserved and re-uploaded to Gorgias via the REST API after the primary record import. Gorgias does not attach files via CSV import; the REST API is the only reliable path for attachment migration. We batch attachments by parent record, re-upload each file, and link it to the corresponding Ticket or Customer record. Inline images embedded in conversation messages are handled as separate attachment records.

Thulium

Workflow / Automation

maps to

Gorgias

Not migrated

lossy
Fully supported

Thulium workflows and automation rules do not migrate to Gorgias as code. Thulium's workflow model uses different trigger conditions, actions, and branching logic than Gorgias Rules and Macros. We deliver a written inventory of every active Thulium workflow and automation with its trigger conditions, actions, and recommended Gorgias Rules or Macros equivalent. The customer's admin rebuilds these in Gorgias post-migration.

Thulium

Macros / Templates

maps to

Gorgias

Macros

1:1
Fully supported

Thulium canned responses and templates map to Gorgias Macros, which include predefined responses and actions. Simple macros with static text and standard actions migrate via mapping. Macros with conditional logic, placeholders referencing Thulium CRM fields, or integrations to external tools require manual review and adjustment in Gorgias after migration.

Thulium

Reports / Dashboards

maps to

Gorgias

Not migrated

lossy
Fully supported

Thulium reporting configurations, custom dashboards, and analytics views do not migrate to Gorgias as they are platform-specific reporting definitions. We deliver a written report inventory listing each Thulium report with its filters, metrics, and visual configuration as a reference for the customer's admin to recreate in Gorgias Analytics or via a third-party BI tool connected to Gorgias data.

Thulium

Call Recordings

maps to

Gorgias

Ticket Attachment

lossy
Fully supported

Thulium voice call recordings embedded in Cases are exported as audio files and re-uploaded as attachments to the corresponding Gorgias Ticket record. Call metadata (duration, disposition, agent) is preserved in the ticket message thread as a structured note. If Thulium stores call recordings in a separate system, we flag this during scoping and coordinate with the customer on retrieval before the migration window.

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.

Thulium logo

Thulium gotchas

Medium

Custom field type mismatches require field-level mapping

Low

Conversation history embedded in Cases requires flattening

Low

Agent-to-Case linkage must be preserved explicitly

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

  • Thulium's undocumented API limits extraction predictability

    Thulium does not publish API rate limits or provide a bulk export endpoint, which means data extraction during migration depends on undocumented behavior rather than a defined API contract. We probe the Thulium API during discovery to establish safe request pacing, but teams moving from Thulium should budget extra scoping time to handle rate-limit discovery and retry logic that would not be necessary with a platform like Gorgias that publishes its limits (40-80 requests per 20 seconds). If Thulium's API becomes unavailable during extraction, we pause and resume with backoff rather than losing data integrity.

  • Gorgias CSV import excludes attachment files entirely

    Gorgias's CSV import method does not support file attachments. Any attachments stored in Thulium (Case files, inline images, Contact attachments) will not transfer via CSV. We handle this by re-uploading all attachments through the Gorgias REST API after the primary record migration, batched by parent record with filename and record linkage preserved. This adds a post-migration step and a second API session that must be paced to Gorgias's rate limits, which we manage with queue-based processing and exponential backoff.

  • Thulium CRM custom field types require field-level mapping

    Thulium CRM custom fields support nine distinct types (text, large text, email, numeric, link, list, yes/no, date, text-with-indexing) that do not map one-to-one to Gorgias field types. We build a field-level mapping table during scoping before any import begins. List-type fields are particularly affected: Thulium list values must be serialized to text in Gorgias unless Gorgias supports an equivalent picklist structure on the target plan. This mapping step is required and adds a scoping phase to the timeline, particularly for accounts with more than 20 custom CRM fields.

  • Thulium workflows and automations do not transfer to Gorgias Rules

    Thulium workflow and automation logic (routing rules, escalation triggers, conditional branching) is not transferable to Gorgias Rules as code. The two platforms use different automation models with different triggers, conditions, and action types. We document every active Thulium workflow in a written inventory delivered at migration handoff, with a recommended Gorgias Rules equivalent for each. The customer's admin rebuilds these post-migration. This is not a limitation of the migration service; it is a platform architectural difference.

  • Gorgias does not have a native Company object

    Thulium maintains a distinct Company record separate from Contact, linked by a relationship field. Gorgias uses a Customer object that can hold organization information but does not have a separate Company table with its own custom fields. If Thulium Company records contain data in Company-specific custom fields, those fields must be mapped to Customer-level custom fields or a note attached to the Customer record during migration. We flag this during scoping and agree on a strategy with the customer before the import.

Migration approach

Six steps for a successful Thulium to Gorgias data migration

  1. Discovery and scoping

    We audit the Thulium account across Cases (count, status distribution, custom status labels), Contacts, Companies, Agents, CRM custom field definitions (field name, type, and any list values), conversation volume per Case, Tags, and attachments. We probe the Thulium API to establish request pacing behavior given the absence of published rate limits. We pair this with a Gorgias plan review to confirm which features (macros, Rules, custom fields, integrations) are available on the target tier. The discovery output is a written scope document, a custom field mapping table, and a Gorgias plan recommendation if the customer's current plan limits are insufficient for the migrating data.

  2. Schema design and field mapping table

    We design the destination schema in Gorgias: creating any missing custom fields on Customer and Ticket objects, configuring Tag names to match Thulium tagging taxonomy, and mapping Thulium CRM custom fields by type. For list-type fields, we enumerate the full list of values and decide on a serialization format (comma-separated text is the default). For date fields, we confirm the format used in Thulium export and configure the corresponding date format in Gorgias. For yes/no fields, we agree on a text representation (true/false or yes/no) to store in the Gorgias text field. The field mapping table is reviewed and signed off before any data is extracted.

  3. Sandbox migration and reconciliation

    We run a full migration into the Gorgias production environment using a subset of records (typically 10-20% sample, prioritized by recent activity) to validate the mapping. The customer's team spot-checks 25-50 records in Gorgias against the Thulium source, verifies conversation thread integrity, confirms that custom field values appear correctly, and validates tag assignments. Any mapping corrections (field name mismatches, incorrect status mapping, conversation thread ordering issues) are addressed here before proceeding to full production migration.

  4. Agent and user provisioning

    We extract every distinct Thulium Agent referenced on Cases, Contacts, and Companies and match by email against the Gorgias destination's User list. Agents without a matching Gorgias User are listed in a reconciliation queue for the customer's admin to provision. Migration cannot proceed past Case and Contact import until the Agent mapping is resolved because assignee references are required on ticket records. The customer's admin creates the missing User accounts in Gorgias, and we re-run the matching step before the production migration window.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Customer records first (with organization attributes resolved from the Thulium Company link), then Agents (user mapping confirmed), then Tickets with flattened conversation threads. Tags are applied to Tickets after the Ticket records are inserted. Custom field values are populated during the insert phase using the field mapping table built during scoping. Each phase emits a row-count reconciliation report before the next phase begins. Attachment re-upload runs as a post-processing step via the Gorgias REST API, batched and paced to respect Gorgias rate limits.

  6. Cutover, validation, and automation handoff

    We freeze Thulium 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 workflow and automation inventory document to the customer's admin team with a recommended Gorgias Rules rebuild plan. We support a one-week hypercare window to resolve reconciliation issues raised by the support team in the first days of Gorgias operation. We do not rebuild Thulium workflows as Gorgias Rules inside the migration scope; that work is documented and handed off for the customer's admin or a Gorgias implementation partner.

Platform deep dives

Context on both ends of the pair

Thulium logo

Thulium

Source

Strengths

  • Unified inbox consolidating calls, emails, and live chat into a single queue for support agents.
  • CRM built into the same platform for contact and company management alongside ticket handling.
  • Cloud-hosted SaaS delivery eliminates infrastructure management for customer service teams.
  • Custom field flexibility across multiple data types supports varied business-specific data capture.

Weaknesses

  • Smaller third-party integration ecosystem compared to global helpdesk competitors like Zendesk.
  • Limited public API documentation makes automated data extraction less predictable for migrations.
  • Platform is primarily recognized in European markets, reducing available implementation and migration expertise.
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?

Moderate Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Thulium and Gorgias.

  • Object compatibility

    C

    3 of 7 objects need a mapping; the rest are 1:1.

  • 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

    Thulium: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Thulium 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 Thulium to Gorgias data migrations

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

Can't find your answer?

Walk through your Thulium 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 accounts under 10,000 Cases and 5,000 Contacts with no more than 20 CRM custom fields. Migrations with complex custom field schemas (list-type fields with many values, yes/no fields), large conversation histories (over 100,000 embedded interactions), or customer-requested manual attachment verification move to seven to ten weeks because of field-type mapping, conversation flattening, and the Gorgias REST API batch pacing required for attachment re-upload.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Thulium.
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