Migrate from Rooftop to Salesforce Service Cloud

Rooftop customer records (contact name, email, phone, and custom properties) map directly to Salesforce Contact. The contact's email address serves as the dedupe key during import. We preserve any Rooftop customer-level custom properties as Salesforce Contact custom fields, pre-created during the schema design phase. Rooftop customer metadata (created date, last updated) migrates to Contact system fields for audit trail.

Rooftop customers may belong to a company (Company object). If the destination Salesforce org uses Account records for organizational tracking, we link each Contact to an Account resolved by the customer's company name field. Customers without a Rooftop company assignment receive a Person Account record type if the destination org licenses it, otherwise a standalone Contact without an AccountId.

Rooftop tickets map to Salesforce Case. The ticket subject becomes Case Subject; ticket description becomes Case Description. Rooftop ticket status (open, pending, resolved, closed) maps to Salesforce Case Status values, which we configure during schema design to match the customer's status vocabulary. Ticket priority migrates to Case Priority. The ticket created date maps to Case CreatedDate.

We inventory every distinct Rooftop ticket status value and map each to a Salesforce Case Status picklist entry. Status order and default values are preserved. If Rooftop uses custom status labels (escalated, waiting on customer, etc.), we create matching Status values and include them in the relevant Case Status picklist valueset for the chosen Record Type.

Rooftop conversation threads are flat, ordered message lists. We split them into Salesforce EmailMessage records (for customer-facing emails and outbound replies) and CaseComment records (for internal notes and agent-only messages). Each message's sender, timestamp, and direction (inbound/outbound) determine the Salesforce record type. Messages exceeding 4,000 characters are split across multiple CaseComment entries with a continuation flag because Salesforce enforces that limit per CaseComment row.

Rooftop agent profiles (name, email, role, team assignment) map to Salesforce User records. We extract every distinct agent email referenced on tickets and conversations, create Salesforce Users in inactive status during migration, and flag the activation queue for the customer's admin to complete post-migration (assigning Profile, Role, and the appropriate Salesforce license tier). Agent-team assignments map to Salesforce Queue membership or Role hierarchy entries depending on the destination org structure.

Rooftop custom ticket fields vary by deployment. We inventory every custom field name, data type, and value set during discovery, then map each to an equivalent Salesforce custom field on the Case object (for ticket-level fields) or Contact/Account (for customer-level fields). We pre-create Salesforce custom fields before data import so that the import job can write directly into typed fields rather than working around missing schema.

Rooftop tags applied to tickets for categorization have no native Salesforce equivalent. We discuss two options during scoping: migrate tags as a Salesforce text custom field (single line, comma-separated) or as a multi-select picklist if the tag count stays within Salesforce's 500-value picklist limit. The customer chooses the strategy; multi-select picklist is preferred for filtering and reporting.

File attachments on Rooftop tickets are migrated as URL references in a custom Salesforce field (Attachment_URL__c) pointing to the original storage location, or re-uploaded as Salesforce ContentDocument records via the Chatter API if the customer has attachment re-upload in scope. Re-upload requires the customer's admin to provision storage and is priced as an add-on migration task. Attachment file type and size limits must be validated against Salesforce's ContentDocument constraints before migration.

Rooftop knowledge base articles migrate to Salesforce Knowledge if the destination Service Cloud edition includes it. We export article body content, title, summary, and category assignments. Salesforce Knowledge requires article types to be configured before import; we work with the customer's admin to define article types matching the Rooftop KB category structure. Published status, view counts, and feedback ratings from Rooftop migrate to Salesforce Knowledge custom fields. Knowledge Base enablement requires a System Administrator to activate the feature in Salesforce setup before we can begin article migration.