Helpdesk migration
Field-level mapping, validation, and rollback between FocalScope and Zendesk. We move data and schema; workflows are rebuilt natively in Zendesk.
FocalScope
Source
Zendesk
Destination
Compatibility
8 of 10
objects map 1:1 between FocalScope and Zendesk.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from FocalScope to Zendesk is a migration from a mid-market omnichannel helpdesk built on a SOAP API to the category-leading cloud helpdesk with a mature REST API and a 1,800-plus integration marketplace. The primary technical challenge is FocalScope's SOAP-centric integration model: we run a translation layer to convert FocalScope SOAP responses into JSON-compatible structures for Zendesk's Bulk API, and we validate email channel routing during scoping because FocalScope mail account recreation breaks inbound routing silently. We migrate tickets with full thread history, contacts with custom field values, queue-to-group mappings, SLA policy definitions, Standard Responses as Zendesk macros, and knowledge base articles. We do not migrate automations, routing rules, or reports as code; we deliver written inventories of these for the customer's admin to rebuild in Zendesk's admin center.
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 Zendesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
FocalScope
Ticket
Zendesk
Ticket
1:1FocalScope Tickets map directly to Zendesk Tickets. The full email thread history (public and private comments) migrates as Zendesk comments, with the FocalScope agent notes preserved as internal Zendesk comments. Ticket number is stored as a custom field focalscope_ticket_number__c for cross-reference since Zendesk assigns its own sequential IDs. Priority, status, and channel origin fields map to Zendesk equivalent fields.
FocalScope
Contact
Zendesk
End User (User)
1:1FocalScope Contacts map to Zendesk End Users. Standard fields (name, email, phone) migrate directly. Custom field values defined on FocalScope Contacts map to Zendesk user fields. Where FocalScope stores secondary email addresses or social handles, these migrate to custom user fields. FocalScope Contact categories that classify the contact (not tickets) map to Zendesk tags on the User record.
FocalScope
Channel
Zendesk
Ticket Field (via channel attribute)
1:1FocalScope channel types (Email, Voice, Live Chat, Facebook, WhatsApp, Telegram) each create tickets with channel metadata. We read the channel property via FocalScope's SOAP API and populate Zendesk's channel field using a custom ticket field that we create during migration setup. Voice tickets additionally carry call log metadata (duration, disposition, recording URL) that we store as custom ticket fields since Zendesk's native voice capabilities require Zendesk Talk.
FocalScope
Queue
Zendesk
Group
1:1FocalScope Queues map to Zendesk Groups. Queue names and routing rules are preserved as Group names. Agent assignments within queues map to Zendesk Group memberships. The maximum concurrent ticket limit per queue (a FocalScope configuration) has no direct Zendesk equivalent; we document it as a note for the customer's admin to evaluate via Zendesk's workload management or capacity-based routing if available in their Zendesk Suite tier.
FocalScope
Agent
Zendesk
Agent (User)
1:1FocalScope Agent profiles (name, email, queue assignments, role) map to Zendesk User records with Agent role. We resolve agents by email match. Agents without a matching Zendesk user go to a reconciliation queue before the ticket migration phase begins so that ticket ownership references are valid. FocalScope agent performance metrics (wallboard data) are extracted as reporting context but do not map to Zendesk standard user fields.
FocalScope
Standard Responses
Zendesk
Macros
1:1FocalScope Standard Responses (canned reply templates scoped to queues or categories) migrate to Zendesk Macros. The template body, subject line, and attachment references transfer directly. We map queue-scoped FocalScope Standard Responses to Zendesk Macros scoped to the equivalent Group. Category assignment in FocalScope becomes a Zendesk macro category name for organizational parity. Standard Responses attached to specific channel types are flagged in the inventory so the admin can evaluate Zendesk macro availability by channel form.
FocalScope
SLA Policy
Zendesk
SLA Policy
lossyFocalScope SLA configurations (response time and resolution time windows tied to ticket priority or queue) migrate as Zendesk SLA Policies. We extract each SLA policy definition including first response, next response, and resolution time thresholds, then reproduce them as Zendesk SLA Policy definitions scoped to the relevant ticket groups and ticket forms. SLA breach notifications require manual configuration in Zendesk Triggers post-migration; we document the equivalent trigger logic for the admin.
FocalScope
Category
Zendesk
Custom Ticket Field (dropdown or tag)
lossyFocalScope Categories function as ticket-level classification fields exposed via the SOAP API. Where Categories are used as multi-value labels, we map them to Zendesk tags on the ticket. Where they are used as single-select classification (product line, department, account tier), we create a Zendesk custom ticket field of type dropdown and populate the values from the FocalScope category list. The customer's admin chooses the preferred representation during scoping.
FocalScope
Knowledge Base Articles
Zendesk
Help Center Articles
1:1FocalScope knowledge base articles and their category hierarchy migrate to Zendesk Help Center sections and articles. Article content, author, and publication status transfer directly. FocalScope article attachments migrate as Zendesk article attachments. URL redirects from FocalScope article slugs require manual configuration in Zendesk Help Center redirect settings post-migration; we deliver a redirect map listing every source FocalScope URL and the recommended Zendesk Help Center equivalent.
FocalScope
Attachment
Zendesk
Ticket Attachment (via comments)
1:1FocalScope file attachments linked to tickets or knowledge base articles migrate as Zendesk attachments. In Zendesk, attachments are added only to comments (or article bodies), not directly to ticket records. We re-associate every attachment to the corresponding Zendesk comment that represents the original email or chat message. Attachments exceeding Zendesk's 50 MB per-file limit are flagged and documented for the customer to store in external object storage if needed.
| FocalScope | Zendesk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Contact | End User (User)1:1 | Fully supported | |
| Channel | Ticket Field (via channel attribute)1:1 | Fully supported | |
| Queue | Group1:1 | Fully supported | |
| Agent | Agent (User)1:1 | Fully supported | |
| Standard Responses | Macros1:1 | Mapping required | |
| SLA Policy | SLA Policylossy | Fully supported | |
| Category | Custom Ticket Field (dropdown or tag)lossy | Fully supported | |
| Knowledge Base Articles | Help Center Articles1:1 | Mapping required | |
| Attachment | Ticket Attachment (via comments)1: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
Zendesk gotchas
Data export requires API scripting on non-Enterprise plans
Automations cap at 500 active rules and 1,000 tickets per hour
Help Center has no native export feature
Custom Objects and full data export are Enterprise-only
Pair-specific challenges
Migration approach
Discovery and SOAP endpoint validation
We audit the FocalScope instance for ticket volume, contact count, active channels, queue count, agent headcount, Standard Responses, SLA policy definitions, and knowledge base article count. We validate SOAP endpoint availability and authentication method (API key or basic auth) during the pre-migration technical call. If the instance is on-premises, we coordinate network access and agent deployment. We also run MX record validation against FocalScope channel email accounts to detect any stale mail routing configuration that would cause gaps in imported ticket history. The discovery output is a written scope document with record counts per object, a channel audit, and a FocalScope Category inventory.
Zendesk admin center configuration
We create the Zendesk destination environment: agent groups (mapped from FocalScope queues), custom ticket fields (mapped from FocalScope categories), SLA policies (mirroring FocalScope SLA definitions), user fields (mapped from FocalScope contact fields), and a channel field capturing ticket origin. We configure the Help Center structure (sections and categories) to match FocalScope's knowledge base hierarchy before article migration begins. This work happens in the customer's Zendesk Sandbox or trial environment and is validated before production configuration.
SOAP-to-JSON translation pipeline and sandbox migration
We build and validate the SOAP-to-JSON translation layer against FocalScope's WSDL and confirmed endpoint. A sandbox migration runs into Zendesk using production-like data volume. The customer reconciles record counts (tickets in, contacts in, agents in, macros in, SLA policies in), spot-checks 25-50 tickets for thread completeness and attachment integrity, and reviews the knowledge base article structure in Zendesk. Any mapping corrections are made before production migration begins.
Agent and group reconciliation
We extract every distinct FocalScope agent and queue assignment, then resolve them against Zendesk users and groups. Agents without matching Zendesk user accounts go to a reconciliation queue. The customer's Zendesk admin provisions missing users before the production migration phase so that ticket ownership references (Assignee and Requester) are satisfied at insert time. Group membership is configured to match FocalScope queue assignments.
Production migration in dependency order
We run the production migration in dependency order: Users and Groups first, then Contacts (end users), then Tickets with thread history and channel metadata, then Standard Responses as Macros, then SLA policies, then knowledge base articles and attachments. The SOAP-to-JSON translation layer runs continuously, batching records and submitting to Zendesk's Bulk API 2.0 with rate-limit backoff. Each phase emits a row-count reconciliation report before the next phase begins. Any FocalScope email routing gaps identified during scoping are flagged in the reconciliation report for the corresponding tickets.
Cutover, validation, and automation inventory handoff
We freeze FocalScope writes at cutover, run a delta migration of any records modified during the migration window, then hand off to Zendesk as the system of record. We validate a final sample of tickets for thread completeness, attachment linkage, and SLA policy assignment. We deliver the routing rule inventory and SLA trigger configuration plan to the customer's Zendesk admin. We support a one-week hypercare window for reconciliation issues. We do not rebuild FocalScope routing rules as Zendesk Triggers or automations within the migration scope; that work is documented for the admin to implement post-migration.
Platform deep dives
FocalScope
Source
Strengths
Weaknesses
Zendesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across FocalScope and Zendesk.
Object compatibility
1 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 Zendesk migration scoping. Not seeing yours? Book a call.
Walk through your FocalScope to Zendesk 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 Zendesk
Same-Helpdesk migrations
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.