Migrate from Pylon to Zendesk

Pylon Issues map directly to Zendesk Tickets. The Pylon issue ID becomes the Zendesk ticket ID in a custom field pylon_original_id__c for audit traceability. Pylon status (open, resolved, closed) maps to Zendesk ticket Status with a default of New at import time. Priority from Pylon (if set as a structured field rather than a routing rule) maps to Zendesk Priority. Custom fields on Issues migrate as name-value pairs once the destination Zendesk custom fields are created.

Pylon Accounts map to Zendesk Organizations. The Account name becomes the Organization name, and Pylon's Account-level custom fields (including any Account Intelligence properties like health score) migrate as custom fields on the Zendesk Organization record. Organization is created in Zendesk before Contact import so that the Lookup relationship is satisfied at the moment of Contact insert.

Pylon Contacts map to Zendesk End Users (the user type representing customers). Contact properties (name, email, phone, custom fields) migrate directly. Where Pylon stores the customer role or account association, that maps to the End User's organization field and role field in Zendesk.

Pylon Users (agents) map to Zendesk Agent accounts. User profiles, permissions, and assignment history migrate as custom fields on the Zendesk User record because Zendesk Agent permissions are controlled by role-based security, not migrated as data. We reconcile Pylon agent IDs against Zendesk agent User IDs by email match. Any Pylon agent without a matching Zendesk user is held in a reconciliation queue for the customer's admin to provision before record import.

Pylon Teams map to Zendesk Groups. Team membership and routing rule assignments migrate as Zendesk Group membership. Where Pylon routing logic is encoded as conditional rules rather than static team assignments, we represent those rules in the migration inventory as Zendesk Views and routing conditions to be rebuilt post-migration.

Pylon separates internal notes (agent-only) and external comments (customer-visible) on an Issue thread. These map to Zendesk's Private Comment (visible to agents only) and Public Comment (visible to the end user) respectively. The Pylon comment body, author, and timestamp are preserved. This is one of the most critical mappings for maintaining conversation integrity during migration.

Pylon Issues originating in Slack or Microsoft Teams threads do not have a direct Zendesk equivalent because Zendesk does not store thread parent references. We map the thread to a linear ticket comment history, but thread metadata (Slack channel name, Slack thread timestamp, original Slack message author) cannot be backfilled post-migration. This is documented as a known limitation during scoping and included in the pre-migration customer communication plan.

Pylon's Account Intelligence layer (Notebooks, Tasks, Projects, Activities) has no native Zendesk equivalent in standard Service Cloud or Suite. We migrate these as custom fields on the Organization record (for account-level health data) or as separate Zendesk Custom Objects if the customer holds a Suite Professional or higher plan that supports them. Tasks and Projects may require customer confirmation on whether they want these as separate objects or consolidated into existing records.

Pylon Knowledge Base Articles migrate to Zendesk Help Center Articles. Article content, author, and creation timestamp migrate directly. HTML content is sanitized during import. Pylon Collections (categories) map to Zendesk Help Center Sections with nested sub-collections preserved. Article-to-collection assignments migrate as section placement in Zendesk. Section permissions in Pylon map to Zendesk Help Center audience restrictions.

Pylon Collections migrate as Zendesk Help Center Sections. Nested sub-collections are preserved as nested sections in Zendesk. Section-level permissions and access restrictions migrate to Zendesk's Help Center audience model. If a Collection has no equivalent Section in the Zendesk destination, we create one during schema configuration.

Pylon Feature Requests migrate as tags on the related Ticket or as structured custom fields (original requester, vote count, status) depending on the customer's Zendesk plan and preferences. We preserve the original requester, vote count, and status. Zendesk's native Feedback object is available on certain plans; we confirm eligibility during scoping and use it when present.

Pylon Broadcasts are outbound messaging objects with analytics that do not map to any standard Zendesk object. We do not migrate Broadcasts; we document them as an exclusion in the migration inventory and provide a full list of active Broadcast records for the customer's records.

Integration configuration in Pylon (connected apps, webhook endpoints, API credentials) is not migratable across systems. We document which integrations the customer has active in Pylon so they can reconfigure them in Zendesk post-migration. Common integrations (Slack, Microsoft Teams, Salesforce, HubSpot) have known Zendesk equivalents that we include in the handoff documentation.