Migrate from eTicket to Salesforce Service Cloud

eTicket Tickets map to Salesforce Case records. Ticket subject becomes Case Subject, ticket description becomes Case Description, ticket status (Open, Pending, Resolved, Closed) maps to Case Status with a custom status value set matching eTicket's state machine. Priority (Low, Medium, High, Urgent) maps to Case Priority. Created timestamp preserves as Case.CreatedDate via Bulk API with explicit date mapping. Ticket ID is stored in a custom text field eticket_id__c for cross-reference during reconciliation.

eTicket Conversations (internal and external messages threaded on a ticket) map to Salesforce CaseComment records. The CommentBody, CreatedBy, and CreatedDate migrate for each conversation entry. Public/internal visibility on eTicket maps to a custom IsInternal__c flag on CaseComment to preserve agent-only notes. Threading order is preserved by sorting on the original eTicket conversation timestamp before insert.

eTicket Customers map to Salesforce Contact records. Email, FirstName, LastName (extracted from the name field if eTicket stores it as a single string), and phone migrate directly. If eTicket stores a company name on the customer, we resolve it to an Account lookup. Any customer without an email is flagged for manual review because Salesforce requires an email for Contact records by default.

If eTicket stores a company or organization field on the Customer record, we create a Salesforce Account record for each unique company value before Contact import and link the Contact to the Account via AccountId. The Account.Name maps from the eTicket company field. This creates the organizational hierarchy that Salesforce reporting relies on.

eTicket Agents map to Salesforce User records. We resolve agents by email match against the destination org's User table. Any eTicket Agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Active/inactive status on the User maps from eTicket's agent active flag.

eTicket's direct ticket-to-agent assignment maps to Salesforce Case.OwnerId. If the destination org uses Salesforce Queues for case distribution, we map agent-assigned tickets to the appropriate Queue by matching the agent's team in eTicket to a Queue with the same name. Omni-Channel routing can be enabled post-migration as a separate configuration step.

eTicket file attachments migrate to Salesforce ContentDocument records linked to the parent Case via ContentDocumentLink. Each attachment's filename, content type, and binary content map to ContentVersion (Title, FileType, VersionData) and then to ContentDocument via the Salesforce two-object attachment model. We chunk large attachment batches to stay within Salesforce's ContentDocument file size limits per upload.

eTicket tags stored on tickets migrate to a custom multi-select picklist field on Case. We extract the distinct tag values across all tickets, create the picklist entries during schema setup, and populate Tag__c during the Case import. Tags used for categorization rather than filtering migrate as-is; if tag cardinality exceeds picklist limits, we recommend splitting into multiple single-select custom fields.

eTicket custom fields on tickets require pre-creation in Salesforce before migration. We audit every eTicket custom field during discovery, map field types (text, number, date, dropdown) to equivalent Salesforce field types, and create the Salesforce custom fields (with __c suffix) in the destination org's Case object before data import. Fields with no direct Salesforce equivalent are flagged in the discovery report and resolved with the customer before schema finalization.

If eTicket has Knowledge Base articles and the destination org has Salesforce Knowledge enabled, we migrate articles to KnowledgeArticleVersion records. Article title, body content, and summary map to the Salesforce Knowledge data model. Article categories or topics map to Salesforce Data Category Group assignments. If Salesforce Knowledge is not enabled, we deliver a structured CSV export of the KB content for manual upload or a separate Knowledge enablement engagement.