Migrate from Re:Desk to Zoho Desk

Re:Desk Members map to Zoho Desk Contacts. The member record contains first name, last name, email, phone, address, membership type, membership status, expiration date, and custom fields. We map membership type to a Contact custom field (member_type__c) and expiration date to a custom date field. Membership status (active, expired, suspended) maps to a custom picklist rather than Zoho's built-in lifecycle stage. We use email as the primary deduplication key and preserve the original Re:Desk member ID in contactExtId for audit trails.

Re:Desk Programs (classes, leagues, activities) map to Zoho Desk Products if the program has a fee, or to a Zoho Desk custom object (recdesk_program__c) if program metadata (schedule, instructor, location, capacity) needs to be preserved structurally. Program registration limits map to a custom field (registration_limit__c). Programs with zero fee map to a custom object to avoid creating unnecessary Product records in Zoho. We coordinate with the customer during scoping to determine which programs are fee-based and which are free community programming.

Re:Desk Facilities (courts, fields, rooms, pools) have no direct Zoho Desk equivalent since Zoho Desk is ticketing-focused rather than asset-reservation-focused. We map Facilities to a Zoho Desk custom object (facility__c) with custom fields for facility type, capacity, amenities, and status. Availability rules and facility-specific constraints are preserved as custom fields or encoded in a separate facility_rules__c custom object linked via lookup relationship.

Re:Desk Reservations (facility bookings, rentals, program slots) map to Zoho Desk Tasks. The task subject encodes the facility name and program name, start and end times map to Task due date and custom datetime fields, and the associated member maps via the Zoho Contact lookup. Reservation status (confirmed, cancelled, completed) maps to Task status. We create a custom picklist field (reservation_status__c) to preserve the full Re:Desk status vocabulary beyond the standard Zoho Task status values.

Re:Desk POS Transactions map to a Zoho Desk custom object (pos_transaction__c) because Zoho Desk does not include native invoicing. The transaction object carries line items (via a custom related list object), payment method, timestamp, total amount, and attending staff member linked to the Zoho User record. Transaction records are linked to the associated Contact (member) and optionally to a Facility or Program custom object depending on transaction type.

Re:Desk attendance records map to a Zoho Desk custom object (attendance__c) linked to both the Contact (member) and the Program custom object. Check-in time and check-out time are custom datetime fields. We flag gaps in attendance data noted during scoping (Re:Desk reviews indicate limitations in real-time check-in/out functionality) and document any partial records in the migration handoff.

Re:Desk invoices map to a Zoho Desk custom object (invoice__c) with invoice number, invoice date, due date, line items, subtotal, tax, total amount, payment status, and associated Contact. Payment status mapping covers paid, pending, refunded, and voided. The invoice custom object is linked to the Contact and optionally to a Program or Reservation custom object depending on what generated the charge.

Re:Desk staff accounts (Administrator, Staff, Front Desk roles) map to Zoho Desk Agents. We map by email match and preserve the role assignment in a custom picklist field (redesk_role__c). The department structure in Re:Desk (if used) maps to Zoho Desk Departments, which control ticket routing and agent visibility. Active and inactive staff status maps directly to Zoho Agent active/inactive.

Re:Desk custom fields on Members are discovered during scoping and mapped to Zoho Desk Contact custom fields of equivalent type (text, number, date, picklist, checkbox). We preserve the original Re:Desk custom field label in the field description for admin reference. Custom field values migrate as literal data at the Contact level with no transformation beyond type compatibility checks.

Re:Desk custom fields on Programs are discovered during scoping and mapped to the equivalent custom fields on the Zoho Product or recdesk_program__c custom object depending on the mapping decision made during scoping. Custom field types are preserved directly. Fields with picklist values map to Zoho picklist fields with the same value set.

Documents attached to Member records, Programs, Facilities, or Reservations export as binary blobs and attach to the corresponding Zoho Desk custom object record via theAttachments standard related list. We preserve filenames, original upload timestamps, and association metadata. File size limits in Zoho Desk (attachment storage quota per plan tier) are verified against the customer's plan before migration to avoid quota exceeded errors.

Re:Desk subscription tier (Standard, Plus, Enterprise) and contract renewal dates are documented as custom fields on the migration summary record rather than migrated as operational data. We flag the renewal date during scoping to ensure the customer does not renew the annual subscription before migration cutover, as Re:Desk does not offer pro-rata refunds for mid-contract departures.