Helpdesk migration

Migrate from FocalScope to Gorgias

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

FocalScope logo

FocalScope

Source

Gorgias

Destination

Gorgias logo

Compatibility

75%

9 of 12

objects map 1:1 between FocalScope and Gorgias.

Complexity

CModerate

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from FocalScope to Gorgias is a multi-channel inbox reconstruction that requires careful schema translation across two platforms with different API architectures. FocalScope uses a SOAP-based API and a queue-centric data model where tickets, Categories, and Standard Responses all carry routing and classification metadata; Gorgias uses a REST API and a ticket-centric model where routing is handled by Rules, macros replace Standard Responses, and Categories become either custom fields or tags. We translate FocalScope SOAP responses to JSON-compatible structures, reproduce queue-to-team routing through Gorgias Rules, and preserve Standard Response templates as Gorgias macros. We do not migrate FocalScope's wallboard configurations, SLA policy enforcement, or on-premises agent-pop call notes as code; we deliver a written inventory of these for the customer's admin to rebuild in Gorgias.

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

FocalScope logo

FocalScope

What's pushing teams away

  • The interface, while functional, is described as dated compared to newer helpdesk products; some teams feel the UX has not kept pace with modern design expectations.
  • Limited public documentation on API rate limits and REST endpoints makes it difficult for development teams to build and maintain integrations without direct vendor support.
  • Advanced automation and workflow features require higher tiers or custom configuration, leading some customers to seek platforms with more powerful rule-building out of the box.
  • Scalability concerns arise for very large contact centers — the platform is better suited to mid-market operations than to enterprise-scale deployments with hundreds of simultaneous agents.

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

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

FocalScope

Ticket

maps to

Gorgias

Ticket

1:1
Fully supported

FocalScope Tickets map to Gorgias Tickets with the full email thread history, internal notes, and status preserved. The FocalScope ticket number becomes the external_id field in Gorgias for cross-referencing. We import ticket attachments separately and re-associate them using Gorgias' attachment handling. Ticket priority (Normal, High, Urgent) maps to Gorgias priority values. Any FocalScope Categories assigned to the ticket become Gorgias tags or custom fields depending on whether the Category uses dynamic or static values.

FocalScope

Contact

maps to

Gorgias

Customer

1:1
Fully supported

FocalScope Contacts map to Gorgias Customers. Email, phone, name, and language fields migrate directly. Any FocalScope Contact custom fields map to Gorgias Customer custom fields, which we pre-create in the destination workspace before import. The customer's email address serves as the primary dedupe key.

FocalScope

Agent

maps to

Gorgias

Agent

1:1
Fully supported

FocalScope Agents map to Gorgias Agents by email match. Agent names, emails, and active/inactive status transfer directly. We extract any FocalScope agent-to-queue assignments and reproduce them in Gorgias as team memberships. If a FocalScope agent email does not have a corresponding Gorgias agent account, we hold those tickets in a reconciliation queue for the customer's admin to provision the account before record import completes.

FocalScope

Queue

maps to

Gorgias

Team + Rule

lossy
Fully supported

FocalScope Queues define ticket routing, maximum agent limits, and queue-level SLA policies. In Gorgias, we reproduce queue-based routing by creating Teams (matching the FocalScope queue name) and configuring Rules that assign incoming tickets to the appropriate Team based on channel, subject, or custom field conditions. Queue workload limits do not have a direct Gorgias equivalent; we document the original limits for the customer's admin to enforce manually or via a Gorgias Rule.

FocalScope

Standard Response

maps to

Gorgias

Macro

1:1
Fully supported

FocalScope Standard Responses (canned reply templates scoped to queues or categories) map to Gorgias Macros. The template body, variable placeholders, and queue/category scope all transfer. Macro variables in FocalScope (such as {{customer.name}} or {{ticket.id}}) are translated to Gorgias variable syntax ({{ticket.customer.name}}). We flag any Standard Response that references FocalScope-specific fields or Categories that may not exist in the Gorgias workspace as template arguments requiring admin review.

FocalScope

Category

maps to

Gorgias

Custom Field or Tag

lossy
Fully supported

FocalScope Categories serve as custom fields on tickets and can use dynamic values (skip-prompt) or static value lists. Dynamic-value Categories (documented in FocalScope's KB for use with SOAP reports) map to Gorgias text custom fields on the Ticket object. Static-value Categories with controlled vocabularies map to Gorgias multi-select or single-select picklist custom fields. We create the custom field schema in Gorgias before ticket import, preserving the Category name and value set. If Categories are used primarily for segmentation rather than routing, we offer tag-based migration as a lighter alternative.

FocalScope

Channel

maps to

Gorgias

Channel (via Ticket channel field)

lossy
Fully supported

FocalScope Channels (Email, Voice, Live Chat, Facebook, WhatsApp, Telegram, SMS) each create tickets with distinct metadata and routing behaviors. Voice tickets include call logs and recording references. We preserve the channel origin on each migrated ticket using Gorgias' channel field and add a custom field (src_channel__c) to preserve the original FocalScope channel name for reporting continuity. WhatsApp and Telegram tickets migrate as messages and comments on the ticket, with channel metadata preserved.

FocalScope

SLA Policy

maps to

Gorgias

Rule (manual rebuild inventory)

1:1
Fully supported

FocalScope SLA Policies define response and resolution time windows tied to ticket priority or queue. These are configuration records, not data records. We extract the full SLA policy definitions (priority thresholds, time windows, escalation actions) and deliver them as a written inventory document. The customer's admin rebuilds them in Gorgias using Rules and timetriggered automations or the Gorgias Automate add-on. SLA performance data (wallboard metrics) does not migrate as data because Gorgias uses a different reporting schema.

FocalScope

Attachment

maps to

Gorgias

Attachment (via Ticket)

1:1
Fully supported

File attachments stored within FocalScope tickets are extracted during the migration export phase and re-associated in Gorgias using the available attachment handling on the Ticket object. We map attachments by ticket external_id (the FocalScope ticket number) to ensure each file lands on the correct Gorgias ticket. Inline images embedded in email thread messages are handled separately as content documents.

FocalScope

Knowledge Base Article

maps to

Gorgias

Help Center Article

1:1
Fully supported

FocalScope Knowledge Base articles and their category assignments are exported and migrated to Gorgias Help Center articles. We preserve article title, body content, category assignments, and publication status. Article URL slugs are recreated in Gorgias format. Links between articles and FocalScope ticket categories are not preserved automatically; we flag these for the customer's admin to reconnect through Gorgias' article-tag-to-ticket-tag linkage.

FocalScope

Report

maps to

Gorgias

Report (CSV export + rebuild inventory)

1:1
Fully supported

FocalScope reports with their metrics, filters, and output formats cannot transfer 1:1 to Gorgias because Gorgias uses a different reporting data model. We export the report data as structured CSV or Excel from FocalScope (FocalScope supports direct export to server, NAS, or FTP storage) and deliver it alongside a written inventory of report definitions. The customer's admin rebuilds the equivalent reports in Gorgias using the Support Performance Statistics and Live Statistics dashboards.

FocalScope

Call Log (Voice)

maps to

Gorgias

Comment on Ticket

1:1
Fully supported

FocalScope Voice tickets include call logs with duration, disposition, and recording URL references. We extract call metadata and import it as a private comment on the corresponding Gorgias ticket, tagging the entry with a call_log__c type indicator and including duration and disposition. Call recording URLs are stored as a text field; the actual recordings do not migrate unless they are stored as accessible file URLs that can be re-hosted.

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.

FocalScope logo

FocalScope gotchas

High

Email account recreation breaks FocalScope mail routing

Medium

SOAP API is the primary integration method, not REST

Medium

Incoming email delays are a documented FocalScope behavior

Low

API rate limits are not publicly documented

Low

On-premises deployments require network access verification

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

  • SOAP API requires translation layer for FocalScope data extraction

    FocalScope's primary API is SOAP-based, not REST. Migration scripts must use a SOAP client library, generate XML payloads for requests, and parse XML responses before any data can enter the migration pipeline. We build a SOAP-to-JSON translation layer that handles the FocalScope WSDL, maps SOAP envelope structures to JSON objects, and manages SOAP authentication headers. This translation step adds complexity and is a common point of failure if the WSDL changes between scoping and migration. We pin the WSDL version during scoping and validate that the translation layer produces structurally identical output at migration time.

  • FocalScope Categories as custom fields require pre-migration schema setup in Gorgias

    FocalScope Categories are linked to tickets as custom fields with either dynamic or static values. Dynamic-value Categories (those with the 'skip-prompt' flag enabled) store freeform text on tickets; static-value Categories enforce a controlled vocabulary. Before any ticket data migrates, we must create the equivalent custom fields in Gorgias (text, single-select, or multi-select depending on the Category type). If the custom field schema is not pre-created, ticket imports will silently drop Category values or fail validation. We coordinate custom field creation with the customer during the scoping phase, before any migration scripts run.

  • FocalScope email channel recreation breaks mail routing silently

    If a FocalScope mail server account has been compromised or recreated, the underlying email address configuration changes but FocalScope retains the old account binding. Incoming email routing breaks silently — tickets stop being created from inbound emails and historical thread continuity breaks for existing tickets. We detect this during scoping by validating FocalScope channel account configurations against current DNS and MX records. We flag any stale email channel bindings and coordinate with the customer's IT team to update mail account bindings before migration begins. This is one of the most common causes of gaps in email thread history after migration.

  • Gorgias REST API rate limits constrain batch migration throughput

    Gorgias publishes API rate limits that vary by plan tier. High-volume migrations must respect these limits through throttling and batch sizing. We implement exponential backoff on 429 responses, chunk ticket batches to sizes appropriate for the destination plan, and run migration jobs during off-peak hours where available. For customers on lower Gorgias tiers, migration time scales with the rate limit rather than with raw record count. We size the migration job concurrency during the scoping phase by testing against a staging workspace.

  • FocalScope Standard Response queue scoping has no direct Gorgias macro equivalent

    FocalScope Standard Responses can be scoped to specific queues or Categories, meaning an agent sees a subset of templates based on the current queue assignment. Gorgias Macros do not have native queue-scoped visibility by default; all macros are available to all agents unless the customer's workspace enforces scoping through a naming convention or workflow. We map Standard Response queue assignments and deliver a written note recommending macro folder naming or Rule-based macro recommendations to reproduce queue-scoped access control. The customer's admin implements this post-migration.

Migration approach

Six steps for a successful FocalScope to Gorgias data migration

  1. Technical scoping and SOAP endpoint validation

    We audit the source FocalScope instance across all active channels (Email, Voice, Live Chat, Facebook, WhatsApp, Telegram), document the SOAP endpoint and authentication method, and validate WSDL availability. We export a sample of 50-100 tickets to confirm the SOAP response structure, validate Category definitions and dynamic-value flags, and confirm Standard Response template count and variable syntax. We also verify the FocalScope instance's network accessibility (cloud-hosted or on-premises) and coordinate any required self-hosted migration agent deployment if the instance is behind a firewall.

  2. Gorgias workspace configuration and custom field schema creation

    We create the destination Gorgias workspace structure before any data migration begins. This includes provisioning Agents, creating Teams that map to FocalScope Queues, configuring the email channel and any additional channel integrations (Facebook, Instagram, WhatsApp, Telegram), and creating all custom fields needed to receive FocalScope Category values. Custom fields are created via the Gorgias REST API using the POST /api/custom-fields endpoint with the correct object_type (Ticket or Customer), label, managed_type, and definition. We also create any Customer custom fields needed to receive FocalScope Contact custom field values.

  3. SOAP-to-JSON pipeline build and data extraction

    We build the migration extraction layer using a SOAP client that authenticates against the FocalScope instance, generates requests for Tickets, Contacts, Agents, Standard Responses, and KB articles, and translates the XML responses into JSON-compatible structures for downstream processing. We run a full export of all objects and validate record counts against what the FocalScope admin console reports. We also export channel metadata, queue-to-agent assignments, and SLA policy definitions. Any gaps in thread history (due to FocalScope's documented incoming email delay behavior) are flagged and reported to the customer before the mapping phase begins.

  4. Mapping design and Standard Response-to-Macro conversion

    We design the full mapping specification: FocalScope Tickets to Gorgias Tickets with channel and priority preserved; FocalScope Contacts to Gorgias Customers with custom fields mapped; FocalScope Agents to Gorgias Agents by email; FocalScope Queues to Gorgias Teams with Rule-based routing; FocalScope Standard Responses to Gorgias Macros with variable syntax translated; FocalScope Categories to Gorgias custom fields or tags depending on dynamic/static type. The mapping spec is reviewed by the customer and signed off before any data is written to the Gorgias destination. We also produce the SLA policy inventory and the Report definition inventory at this stage.

  5. Sandbox migration and reconciliation

    We run a full migration into a Gorgias staging environment (not the production workspace) using the production-like data volume extracted in Step 3. The customer reconciles record counts, spot-checks 25-50 random tickets against the FocalScope source for field accuracy, verifies that Standard Response templates appear correctly in Gorgias Macros, and confirms that channel metadata is preserved on tickets. Any mapping corrections and custom field schema adjustments are made in this phase. Migration does not proceed to production until the customer signs off the sandbox reconciliation report.

  6. Production migration and cutover

    We run the production migration in dependency order: Agents (validated against provisioned accounts), Customers (with custom fields pre-created), Tickets (with external_id, channel, priority, and Category values resolved), Macros (from Standard Responses), and Help Center articles. Each phase emits a row-count reconciliation report. We freeze FocalScope writes during the cutover window, run a final delta migration of any records modified during migration, then enable Gorgias as the system of record. We deliver the SLA policy inventory, Report definition inventory, and Standard Response queue-scoping recommendations to the customer's admin. We support a one-week hypercare window for reconciliation issues; we do not rebuild SLA policies, Reports, or queue-scoped macro access as part of the migration scope.

Platform deep dives

Context on both ends of the pair

FocalScope logo

FocalScope

Source

Strengths

  • Unified omnichannel inbox spanning email, voice, live chat, SMS, Facebook, WhatsApp, and Telegram in a single application.
  • Built-in SLA monitoring with wallboards and reporting for team-level performance visibility against service targets.
  • Both cloud-hosted and on-premises deployment options accommodate regulated industry requirements.
  • Agent pop-up window during calls lets agents attach text notes inline without switching screens.
  • Queue-based ticket routing with configurable maximum limits per queue to balance agent workload.

Weaknesses

  • Publicly available API documentation is limited; no publicly documented rate limits make automated migration planning harder.
  • The SOAP API is older than modern REST APIs and may require additional tooling or transformation in migration scripts.
  • Interface design is described as dated by some reviewers compared to newer helpdesk platforms with more modern UX patterns.
  • Suitable primarily for mid-market teams; very large contact centers may encounter scalability or feature ceilings.
  • Limited third-party integration marketplace compared to platforms like Zendesk or Freshdesk.
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 FocalScope 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

    FocalScope: Not publicly documented as a hard ceiling — confirmed with FocalScope support for high-volume integrations..

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

Walk through your FocalScope to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most FocalScope to Gorgias migrations land between three and five weeks for accounts under 10,000 tickets, a single channel configuration, and fewer than 100 Standard Response templates. Migrations with multi-channel FocalScope setups (Voice, WhatsApp, Telegram, Facebook), more than 25,000 tickets, or more than 300 Standard Response templates requiring manual variable translation move to seven to twelve weeks because of SOAP-to-REST translation work, multi-channel routing reproduction, and custom field schema creation in Gorgias.

Adjacent paths

Related migrations to explore

Ready when you are

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