Migrate from Stames to Zendesk

Stames Tickets represent the core unit of work and map directly to Zendesk Tickets. We preserve status (open, pending, resolved, closed), priority, assignee, and requester references. The original Stames ticket ID is stored in a Zendesk custom field (stames_original_id__c) as a string so historical references and cross-system audit trails remain searchable after migration. Channel attribution on each ticket is stored from the Stames conversation channel field and mapped to the Zendesk via_id or a custom field for reporting.

Stames Customer records contain contact details and metadata that map to Zendesk End Users. We resolve the Customer-to-User mapping by email as the dedupe key. If a Zendesk User with the same email already exists (from a previous import or test run), we flag a reconciliation entry rather than duplicate the record. Organization assignments from Stames map to Zendesk Organizations if that entity type is in use at the destination.

Stames Conversations are threaded message records attached to Tickets. We export full conversation history including agent and customer messages, timestamps, and channel attribution. Threading order is preserved by setting the Zendesk Ticket Comment created_at timestamp to the original Stames message timestamp. Public-facing messages become public Zendesk comments; internal notes become private Zendesk comments based on Stames message visibility settings. Channel attribution (Facebook, Instagram, WhatsApp, Email, API, Contact Form) is stored in a custom field on each comment for reporting.

Stames aggregates from Facebook, Instagram, WhatsApp, Email, API, and Contact Forms. Each channel source is stored as a field on the Conversation record. We map channel attribution explicitly to Zendesk's native via_id where possible and fall back to a custom field (channel_source__c) with the channel name string. This enables post-migration reporting by channel without requiring manual data reconciliation.

Stames User and Agent accounts with roles and permissions are exportable. We map agents to Zendesk User records, matching by email address. Role mapping requires explicit customer confirmation because Stames role definitions may not map 1:1 to Zendesk's Agent, Admin, and End User roles. We flag any permission gaps where the Zendesk schema does not support an equivalent role and document them for the customer's admin to resolve post-migration.

Tags applied to Tickets for categorization in Stames export as label fields. We map tag values directly to Zendesk Tags and apply them to the corresponding Ticket records. Value mapping handles any naming inconsistencies (spaces, casing) so tag-based reporting functions correctly in Zendesk. If tags are used to encode structured data (for example, product category or ticket type), we discuss converting them to Zendesk custom fields during scoping.

File attachments on Tickets and Conversations are downloaded from Stames storage and re-uploaded to Zendesk. Media URL references are updated to point to the new Zendesk storage location. Attachment metadata including filename, file type, and size is preserved. We flag any attachments exceeding Zendesk's file size limits for customer-directed handling (compress, hosted link, or exclusion).

Reminder and notification settings attached to Tickets in Stames are stored as metadata. We export these as custom fields on the Ticket record (for example, sla_due_date__c, notification_trigger__c) for post-migration review. Customers must manually validate and rebuild SLA policy enforcement in Zendesk because notification triggers and SLA rules are not migrated as code. SMS and Email notification triggers require explicit confirmation of the customer's intended rebuild strategy in Zendesk.

Stames self-service portal configurations, including portal access settings, custom forms, and portal-facing content, are not part of the API-accessible data model. We do not migrate portal configurations automatically. Customers must manually recreate portal settings in Zendesk Guide post-migration. We deliver a written inventory of all identified portal configurations (form fields, access controls, branding settings) as a checklist for the customer's admin to reference during Zendesk Guide setup.

Stames ticket-level custom fields (for example, product category, department, escalation tier) map to Zendesk Ticket custom fields of equivalent data type. We use the Zendesk Ticket Fields API to create destination fields before migration, then map values during data load. Drop-down, multi-select, and checkbox fields from Stames generate corresponding Zendesk field types with option lists preserved. Numeric fields map to Zendesk integer fields without length restriction.

If Stames Customer records include company or organization affiliations, these map to Zendesk Organizations. Organization names become the Organization Name field, and domain-based matching is enabled where applicable. If no organization data exists in Stames, we discuss with the customer whether to create Organizations from ticket requester domains or to skip Organization creation entirely.