Helpdesk migration
Field-level mapping, validation, and rollback between FocalScope and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
FocalScope
Source
Gorgias
Destination
Compatibility
9 of 12
objects map 1:1 between FocalScope and Gorgias.
Complexity
CModerate
Timeline
3-5 weeks
Overview
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.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
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
Gorgias
Ticket
1:1FocalScope 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
Gorgias
Customer
1:1FocalScope 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
Gorgias
Agent
1:1FocalScope 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
Gorgias
Team + Rule
lossyFocalScope 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
Gorgias
Macro
1:1FocalScope 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
Gorgias
Custom Field or Tag
lossyFocalScope 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
Gorgias
Channel (via Ticket channel field)
lossyFocalScope 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
Gorgias
Rule (manual rebuild inventory)
1:1FocalScope 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
Gorgias
Attachment (via Ticket)
1:1File 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
Gorgias
Help Center Article
1:1FocalScope 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
Gorgias
Report (CSV export + rebuild inventory)
1:1FocalScope 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)
Gorgias
Comment on Ticket
1:1FocalScope 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.
| FocalScope | Gorgias | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Contact | Customer1:1 | Fully supported | |
| Agent | Agent1:1 | Fully supported | |
| Queue | Team + Rulelossy | Fully supported | |
| Standard Response | Macro1:1 | Fully supported | |
| Category | Custom Field or Taglossy | Fully supported | |
| Channel | Channel (via Ticket channel field)lossy | Fully supported | |
| SLA Policy | Rule (manual rebuild inventory)1:1 | Fully supported | |
| Attachment | Attachment (via Ticket)1:1 | Fully supported | |
| Knowledge Base Article | Help Center Article1:1 | Fully supported | |
| Report | Report (CSV export + rebuild inventory)1:1 | Fully supported | |
| Call Log (Voice) | Comment on Ticket1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
FocalScope gotchas
Email account recreation breaks FocalScope mail routing
SOAP API is the primary integration method, not REST
Incoming email delays are a documented FocalScope behavior
API rate limits are not publicly documented
On-premises deployments require network access verification
Gorgias gotchas
AI Agent adds outcome-based fees on top of billable ticket costs
Overage billing for tickets scales nonlinearly
API rate limits restrict bulk export throughput
Agent data visibility cannot be restricted by role for GDPR use cases
Knowledge Base translations require separate API calls per locale
Pair-specific challenges
Migration approach
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.
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.
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.
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.
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.
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
FocalScope
Source
Strengths
Weaknesses
Gorgias
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across FocalScope and Gorgias.
Object compatibility
3 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
FocalScope: Not publicly documented as a hard ceiling — confirmed with FocalScope support for high-volume integrations..
Data volume sensitivity
FocalScope doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during FocalScope to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your FocalScope to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave FocalScope
Other ways to arrive at Gorgias
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.