Helpdesk migration
Field-level mapping, validation, and rollback between Re:Desk and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
Re:Desk
Source
Gorgias
Destination
Compatibility
2 of 12
objects map 1:1 between Re:Desk and Gorgias.
Complexity
CModerate
Timeline
1-2 weeks
Overview
Re:Desk is a recreation management platform for parks and recreation departments, not a helpdesk, so there is no natural one-to-one object mapping to Gorgias. We resolve this by transforming the source schema: Re:Desk Members become Gorgias Customer profiles, Programs and Facilities become Tickets with structured notes and tags, Reservations become Ticket notes with date ranges, and Staff accounts become Gorgias Agent users. POS transaction histories, attendance records, and invoice metadata migrate as text blocks attached to the relevant Customer or Ticket record since Gorgias has no native accounting or attendance object. The migration uses Gorgias REST API endpoints for customer and ticket creation, with batch processing and parent-record lookup for tag and note associations. Workflows, automations, and Forms do not migrate; we deliver a written inventory of any active Re:Desk automation logic 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 Re:Desk 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.
Re:Desk
Member
Gorgias
Customer
1:1Re:Desk Members map to Gorgias Customer profiles. The Member's first name, last name, email address, phone number, and address fields migrate to the corresponding Customer fields. Membership type, expiration date, and membership status migrate as custom Customer attributes. Member notes and custom field values (such as emergency contact, waiver status, or season pass tier) migrate as text to the Customer's private note field since Gorgias has no native membership lifecycle field. Email addresses serve as the dedupe key; Members without emails go to a reconciliation queue for the customer's admin to resolve before migration proceeds.
Re:Desk
Program
Gorgias
Ticket (tagged by program)
1:manyEach Re:Desk Program (class, league, or activity) becomes a set of Gorgias Tickets, one per enrolled Member, with program metadata encoded in tags and Ticket notes. The program name, schedule, instructor, and registration limit migrate as tag values on each Ticket. If the customer uses Re:Desk's program waitlist feature, waitlisted Members receive Tickets with a 'Waitlist' tag and a note referencing their waitlist position. The Program description and registration fee migrate as a standard note on the first Ticket for that program to serve as a reference copy.
Re:Desk
Facility
Gorgias
Ticket (tagged by facility)
1:manyRe:Desk Facilities (courts, fields, rooms, pools) map to Gorgias Tickets tagged by facility name and facility type. Each facility receives a 'Facility' tag; a sub-tag carries the specific facility name. Facility notes, capacity, and availability rules migrate as Ticket notes. If the customer's Re:Desk contains facility incident records (damage reports, maintenance requests), these become Tickets with 'Incident' tags for triage by the receiving team.
Re:Desk
Reservation
Gorgias
Ticket Note
1:manyRe:Desk Reservations for facilities or equipment rentals merge into the relevant Customer Ticket as structured notes. Each Reservation contributes a note block containing the facility name, rental date range, time slot, and associated fee. Cancelled and past reservations include a status note. If a Member has multiple reservations, all reservation note blocks attach to a single summary Ticket for that Customer rather than creating separate Tickets per reservation.
Re:Desk
Point-of-Sale Transaction
Gorgias
Customer Note
1:manyRe:Desk POS transaction records—covering concessions, registration fees, and equipment rentals—attach as a transaction history block to the relevant Customer's profile. Each transaction contributes a line item noting the date, amount, payment method, and item description. Since Gorgias has no native accounting or invoicing object, the transaction block is text-formatted for readability. Refund records note the original transaction ID, refund amount, and reason. Customers with high transaction volumes receive a summary note with total spend rather than individual line items.
Re:Desk
Check-in / Attendance
Gorgias
Customer Note
lossyRe:Desk attendance records (where available, noting that Re:Desk lacks real-time check-in/out functionality) migrate as attendance history notes on the Customer profile. Each check-in contributes a date-stamped note with the program or facility name. Because Re:Desk attendance data may be incomplete or aggregated by program rather than by visit, we flag any gaps during scoping and apply a date-range filter so only confirmed attendance records migrate. Incomplete attendance data is noted in the migration validation report.
Re:Desk
Invoice / Billing Record
Gorgias
Customer Note
lossyRe:Desk invoices for program registrations, facility rentals, and POS purchases attach to the relevant Customer as invoice reference notes. Each note includes the invoice number, date, line items, total amount, and payment status (paid, pending, refunded, cancelled). Invoice PDFs attach as files to the Customer record via Gorgias attachment handling. Since Gorgias does not have a billing or accounts receivable object, invoice reconciliation is a manual or external process post-migration.
Re:Desk
User / Staff
Gorgias
Agent
1:1Re:Desk staff accounts (Administrator, Staff, Front Desk roles) map to Gorgias Agent users. We map the staff email address, first name, and last name directly. Role mapping applies Re:Desk role distinctions as Gorgias Agent permissions: Administrators map to Agents with admin access, Staff maps to Agents with standard access, and Front Desk maps to Agents with limited access appropriate for reception workflows. Any Re:Desk staff without an email address go to a reconciliation queue for the customer's admin to assign before migration.
Re:Desk
Custom Fields
Gorgias
Customer Attributes
lossyRe:Desk custom fields on Members and Programs (such as waiver version, emergency contact, season pass type, or league division) migrate as custom Customer attributes or as tagged note content. We discover all active custom field definitions during scoping, apply a type assessment (text, date, number, multi-select, checkbox), and map accordingly. Multi-select custom fields become comma-separated text values in Customer notes since Gorgias has no native multi-select attribute on Customer.
Re:Desk
Documents / Attachments
Gorgias
Customer or Ticket Attachment
lossyRe:Desk documents attached to Member records, Programs, and Reservations (such as signed waivers, program brochures, or facility use agreements) migrate as file attachments linked to the corresponding Customer or Ticket record in Gorgias. We preserve the original filename and attach it to the relevant record with a note indicating the source object. File size is subject to Gorgias plan attachment limits (typically 10-25 MB per file depending on plan). Very large file sets may require the customer's admin to migrate attachments separately via Gorgias API or bulk upload.
Re:Desk
Workflows / Automation Settings
Gorgias
None (written inventory only)
lossyRe:Desk automation settings for member registration confirmations, facility booking notifications, and program waitlist alerts do not migrate as code. We deliver a written inventory of each active automation, noting its trigger (e.g., registration submitted, reservation confirmed, payment received), conditions, and actions. The customer's admin rebuilds these as Gorgias Rules, Macros, or Automate flows post-migration using the inventory as a specification document.
Re:Desk
Reports / Dashboards
Gorgias
None (written inventory only)
lossyRe:Desk reports for facility utilization, program enrollment, revenue by facility, and member check-in rates do not migrate. We deliver a written inventory of each report with its filters, groupings, and date ranges so the customer's admin can recreate them in Gorgias's reporting module or export to a BI tool. Gorgias's native reporting covers ticket volume, response time, CSAT, and agent productivity but not recreation-specific metrics.
| Re:Desk | Gorgias | Compatibility | |
|---|---|---|---|
| Member | Customer1:1 | Fully supported | |
| Program | Ticket (tagged by program)1:many | Fully supported | |
| Facility | Ticket (tagged by facility)1:many | Fully supported | |
| Reservation | Ticket Note1:many | Fully supported | |
| Point-of-Sale Transaction | Customer Note1:many | Fully supported | |
| Check-in / Attendance | Customer Notelossy | Fully supported | |
| Invoice / Billing Record | Customer Notelossy | Fully supported | |
| User / Staff | Agent1:1 | Fully supported | |
| Custom Fields | Customer Attributeslossy | Mapping required | |
| Documents / Attachments | Customer or Ticket Attachmentlossy | Mapping required | |
| Workflows / Automation Settings | None (written inventory only)lossy | Fully supported | |
| Reports / Dashboards | None (written inventory only)lossy | 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.
Re:Desk gotchas
Mismatched product category in migration tooling
Annual subscription billing with no pro-rata adjustments
Limited public export and API documentation
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
Export feasibility assessment and scoping call
We run a scoping call with the customer's Re:Desk administrator to assess the data export path. We review which Re:Desk modules are active (Members, Programs, Facilities, Reservations, POS, Invoices, Check-ins), estimate record volumes per object, identify any custom fields, and confirm which staff accounts are active. We also review the Re:Desk export capabilities available—CSV from the UI, support-requested bulk export, or manual record extraction—and document any modules that cannot be exported programmatically. The output is a written migration scope with record counts per object and a Re:Desk export checklist for the customer's admin.
Gorgias plan selection and API credentials
We confirm the customer's Gorgias plan selection based on the ticket volume estimate from scoping. We guide the customer to select a plan whose monthly ticket allowance covers the migrated ticket volume plus expected monthly new tickets. We collect the Gorgias API credentials (OAuth2 or API token) and confirm access to the correct Gorgias subdomain. We verify that the customer's Gorgias plan supports the API endpoints required (Customer, Ticket, Tag, Note, Attachment endpoints are available on all paid plans).
Schema design and mapping specification
We design the mapping specification for the cross-category transformation. This includes: the Member-to-Customer mapping (field-by-field), the Program-to-Ticket-with-tags mapping (which fields become tags, which become notes), the Facility-to-Ticket-with-tags mapping, the Reservation-to-Note mapping (formatting, date range representation), the POS transaction-to-Note mapping (line item format), and the Staff-to-Agent mapping (role permission mapping). The specification also includes any custom field handling decisions and a list of Re:Desk objects that have no Gorgias equivalent (documented as notes-only or excluded). The customer reviews and approves the mapping specification before migration begins.
Test migration and validation
We run a test migration using a subset of the source data (typically 100-500 records per object) into a designated Gorgias test environment or a clean production org with a test tag applied to all imported records. We validate record counts, spot-check field mappings for 25-50 records, verify tag structure on Tickets, confirm Customer-Ticket associations, and check attachment file integrity. The customer reviews the test output and identifies any mapping corrections. We apply corrections to the migration script and re-run the test subset until validation passes. This step prevents data integrity issues from propagating to the full migration.
Full production migration
We execute the full migration in dependency order: first Gorgias Agents (staff accounts), then Customers (Members), then Tickets (Programs and Facilities with tags and notes), then Notes and Attachments. POS transactions, invoices, and attendance records attach to the relevant Customer during or after the Customer phase. Each phase emits a row-count reconciliation report comparing source record count to destination record count. Any records that fail validation (missing required fields, dedupe conflicts, attachment size exceeds plan limit) route to a resolution queue for the customer's admin to address before the next phase begins.
Cutover, final reconciliation, and automation handoff
We freeze Re:Desk write access during cutover and run a final delta migration of any records modified during the migration window. We deliver a migration validation report covering: record counts per object in source and destination, mismatch counts and resolutions, list of any records that could not be migrated with reason codes, and a list of Re:Desk objects with no Gorgias equivalent and how they were handled. We deliver the automation and workflow inventory document to the customer's admin for rebuild in Gorgias Rules, Macros, or Automate. We offer a one-week hypercare window for reconciliation issues. Post-migration admin support, training, and workflow rebuild are outside standard scope and available as a separate engagement.
Platform deep dives
Re:Desk
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 Re:Desk 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
Re:Desk: Not publicly documented in summary form..
Data volume sensitivity
Re:Desk 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 Re:Desk to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your Re:Desk 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 Re:Desk
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.