Migrate from Rooftop to Zendesk

Rooftop Customer records map to Zendesk End Users (the requester on a ticket). We extract name, email, phone, and any custom contact properties from the CSV export and map them to Zendesk user fields. Rooftop customers who are also agents in the system require disambiguation: we hold these records in a reconciliation queue for the admin to confirm whether each person should be imported as an end user, an agent, or both.

Rooftop Company records map directly to Zendesk Organizations. The company name, domain, and any custom company fields migrate to Organization fields in Zendesk. We resolve the user-to-organization lookup during user import: when a Rooftop Customer is associated with a Company, we match the organization by name during the Zendesk Organization import phase, then reference the Organization ID when importing users so that user.organization_id is set correctly.

Rooftop Tickets map to Zendesk Tickets. Each ticket inherits the requester (from the Customer record), the assignee (from the Agent record), status mapping (open/pending/resolved/closed from Rooftop to equivalent Zendesk status values), priority, and any custom ticket field values. We preserve the original ticket ID as a custom field legacy_ticket_id__c for cross-reference during reconciliation. Ticket creation timestamps migrate to Zendesk's created_at to preserve the original date.

Rooftop Conversation messages map to Zendesk Ticket Comments. We preserve message ordering by setting Zendesk comment.created_at to the original Rooftop timestamp. Sender attribution resolves to the Zendesk User imported from the Rooftop Agent record. HTML-formatted messages are normalized to plain text or preserved as HTML depending on the customer's preference. Internal notes flag migrates to the Zendesk public=true/false comment attribute.

Rooftop Agent profiles (name, email, role, team assignment) map to Zendesk Agents. We match by email against the Zendesk destination's agent list. Any Rooftop Agent without a matching Zendesk agent goes to a reconciliation queue: the customer's Zendesk admin provisions the missing agent account before record import resumes because OwnerId references on tickets must resolve at import time. Team and role assignments map to Zendesk Groups and Agent Roles respectively.

Rooftop custom ticket fields vary by deployment. We inventory all custom field names and data types during scoping, then create equivalent Zendesk ticket fields before migration. Dropdown fields in Rooftop map to Zendesk dropdown or tag fields; text fields map to text fields; numeric fields map to integer or decimal fields. Note that Zendesk copies dropdown custom field values to Tags automatically, which may expand the tag set beyond what Rooftop used.

Tags from Rooftop tickets migrate to Zendesk tags. We extract all distinct tag values from the Rooftop export and map them as-is to Zendesk tags. If the customer used Rooftop tags for categorization (severity, product line, channel), these values are preserved in Zendesk's tag system and are available for filtering in views and reports.

File attachments associated with Rooftop tickets or conversations migrate as Zendesk ticket attachments. We extract attachment URLs from the Rooftop export, re-upload to Zendesk, and attach them to the corresponding ticket comment. Attachment size limits and supported file types may constrain migration: Zendesk's 50 MB per attachment limit is the upper bound. We flag any Rooftop attachment exceeding this threshold during scoping.

KB articles and categories from Rooftop migrate to Zendesk Guide. Zendesk Guide must be activated and configured before migration begins; we flag this as a pre-migration admin task. Articles migrate with body content preserved, title mapped to the Zendesk article title, and category/section placement mapped to Zendesk Guide sections and categories. Article internal ID references are remapped to destination Zendesk article IDs. For Enterprise-tier Zendesk destinations, up to 5 levels of subsection hierarchy are supported; for lower tiers, we flatten to a 2-level structure.

This is a Zendesk-specific behavior to plan for: when a custom field in Zendesk is a dropdown type, Zendesk automatically copies the selected value into the ticket's tag list. If the customer used Rooftop custom fields for ticket categorization, this Zendesk behavior may increase the tag volume post-migration. We document this behavior during scoping so the customer can decide whether to use dropdown or text custom fields in Zendesk to control tag expansion.