Zendesk offers a robust platform for customer service operations, and transitioning from Trengo involves understanding how data models translate between the two environments.
While many objects like users and organizations map cleanly, complex historical data and system configurations require careful planning.
This guide outlines the key steps and considerations for migrating your data from Trengo to Zendesk, focusing on how different Trengo components map to Zendesk objects.
Define Your Migration Scope
The foundation of a successful migration is clearly defining what data needs automated transfer, what configuration must be built manually, and what legacy data can be archived.
API Migration
Most foundational data can and should be moved using API calls, leveraging bulk processing capabilities.
- Users, Contacts, and Profiles: Trengo Users map directly to Zendesk Users, managed via the Users API. Trengo Contacts and Profiles are generally consolidated into Zendesk Users, often using the Zendesk Profiles API if you utilize Sunshine functionality for multi-system identities.
- Teams and Contact Groups: Trengo Teams correspond directly to Zendesk Groups. Trengo Contact Groups translate to Zendesk Organizations.
- Custom Fields: The definitions of Trengo’s global Custom Field Definitions map to Zendesk's Ticket Fields, User Fields, or Organization Fields. The actual custom field Values attached to contacts, profiles, or tickets in Trengo must be explicitly mapped and set when creating or updating the corresponding Zendesk record.
- Knowledge Base Content: Trengo’s Help Center Categories, Sections, and Articles map to the hierarchical structure within Zendesk Guide.
- Tickets and Messages: Trengo Tickets correspond to Zendesk Tickets. Individual messages within a ticket must be imported as Ticket Comments or Audits in Zendesk.
Manual Configuration and Review
Some functional objects involve replicating business logic or complex configuration that is best done manually in the new environment or requires custom setup:
- Quick Replies (Macros): While Trengo supports `Create a quick reply`, migrating these to Zendesk Macros is typically done manually or requires analyzing the structure of the quick replies and rebuilding them within Zendesk's macro interface.
- Webhooks: Trengo manages Webhooks through API endpoints. These complex integrations must be rebuilt and tested manually in Zendesk to ensure proper triggering of external services or business systems.
- Boards/Cards: Trengo uses Boards and Cards (managed via `Create a new card`) for organizational purposes. This functionality generally lacks a direct 1:1 mapping to a single Zendesk object and may require custom app development or being mapped into specialized ticket workflows or custom objects.
Archiving and Historical Data
Reporting data and long-gone history should be carefully evaluated:
- Historical Data/Metrics: Detailed report data from Trengo is read-only and should be extracted into a separate data warehouse or archived outside of Zendesk.
- Deep History: For maximum fidelity of message history in Zendesk, use the specialized side conversation import endpoint for threads that cannot be recreated simply via the bulk ticket endpoint.
Prepare Zendesk for Data Import
Before commencing data migration, ensure that the target Zendesk environment is ready to receive and structure the incoming data.
- Map and Create Custom Fields: First, recreate the structure of Trengo’s Custom Field Definitions in Zendesk, mapping them to the corresponding fields (Ticket, User, or Organization). This step is critical because many subsequent objects (users, tickets) rely on these fields being present.
- Define Teams/Groups and Organizations: Next, create all necessary Groups (from Trengo Teams) and Organizations (from Trengo Contact Groups) using the respective creation APIs. This establishes the organizational backbone of your new support system.
- Configure Ticket Workflow Statuses: If Trengo used custom Ticket Results, mirror these in Zendesk using Custom Ticket Statuses. These custom statuses belong to underlying system categories like "new," "open," "pending," "hold," or "solved".
Migrate Objects
The data migration must follow a dependency chain to ensure child objects link correctly to parent objects.
- Users and Contacts
Migrate all agents and end users first. You can use the `Create Or Update User` or `Create Many Users` endpoints in Zendesk.
User Creation: For each user, migrate core identity data (name, email) and assign their initial Role (e.g., `agent`, `admin`, or `end-user`). Use the `email` or `external_id` for matching existing records.
Linking Organizations and Teams: Once users and organizations/groups exist, establish the relationships. Assign users to Organizations (Trengo Contact Groups) using Organization Memberships APIs, defining their default organization if they belong to multiple. Similarly, link agents to Groups (Trengo Teams) using the Group Memberships APIs.
Adding Profiles/Identifiers: Import additional user identities (like secondary emails or phone numbers) using the User Identities API, linking them to the main user record. - Knowledge Base Hierarchy and Content
This involves building the structure first, then populating the articles.
Categories and Sections: Create the parent container structures first: Categories and Sections using their respective APIs. Remember that deleting a Category in Zendesk automatically deletes all contained Sections and Articles.
Articles: Import the content for Articles into the relevant Sections. When creating articles, you must specify the target locale, permission group ID, and user segment ID.
Content Assets (Blocks): Trengo Blocks (reusable content) often translate to reusable assets, or may simply be embedded HTML within the Article body of a Zendesk Guide article. Complex assets might require the three-step Zendesk Guide Media process: request an upload URL, upload the file, and finally create the media object, specifying parameters like `guide_media_id` when creating attachments to link them.
Labels (Tags): Trengo Labels are utilized in Zendesk as Tags attached to articles, tickets, users, or organizations. Tags should be applied after the object creation where applicable. - Historical Ticket Data
Migrating ticket data is the most data intensive step, and it must account for message history, timestamps, and metadata integrity.
Ticket Creation: Create tickets, using bulk creation methods where possible (up to 100 tickets per call). The initial ticket creation uses the `comment` property to set the first conversation message.
Crucially, when importing tickets, the requester must be specified (`requester_id`). If the ticket originally came from a closed Trengo ticket, you could recreate it as a follow-up ticket in Zendesk by including the `via_followup_source_id` property, if appropriate.
All custom field values associated with the original Trengo ticket should be populated using the `custom_fields` array during creation or update.
Ticket Conversation History: For transferring subsequent messages within a conversation (Trengo Ticket Messages), utilize the Zendesk ticketing `Update Ticket` endpoint, including a `comment` object for each message in the historical thread.
Attachments: For files attached to historical messages (Trengo File uploads), the process requires multiple steps in Zendesk: first, upload the file using the Attachments API to get an upload token, and then pass this token within the `uploads` array inside the `comment` object when updating the relevant ticket.
Historical Threads (Side Conversations): Complex internal or external conversations tracked separately in Trengo, perhaps labeled uniquely, can be imported directly into Zendesk as historical Side Conversations or Side Conversation Events if they involve multi-party threads outside the main ticket flow.
Post Migration Configuration
Once the raw data is safely residing in Zendesk, focus shifts to rebuilding the functional and reporting layers. These processes typically involve configuration within the Zendesk Admin Center or using specific APIs that govern ongoing operations and compliance.
- Rebuild Automated Workflows: Any Trengo automations, including routing rules, triggers, and automations (actions executed on tickets or other objects), must be manually recreated within Zendesk Triggers and Automations.
- Redirects: To preserve SEO and link integrity for old Help Center content, implement Redirect Rules for deleted or relocated articles, sections, or categories. You can configure redirect rules using the Redirect Rules API.
- Setup Reporting Dashboards: While raw metrics were archived, the corresponding reporting views and dashboards need to be set up in Zendesk Explore or Analytics to utilize the new data structure for future performance analysis.
- Security and Compliance Cleanup: Review user identities to ensure primary emails are correctly verified, especially if migration bypassed standard verification flows.
Insider Secrets
Successfully migrating large volumes of support data demands forethought concerning technical nuances and organizational dependencies.
- The Golden Rule of IDs: While you cannot always preserve original IDs, ensuring every migrated object (User, Organization, Ticket) is tagged with its original Trengo ID as an External ID in Zendesk is vital. This correlation ID is essential for debugging post-migration sync issues, reconciling data, and quickly referencing legacy systems if necessary.
- Timestamp Integrity for History: When importing historical communication (messages/comments), ensure you use the correct API methods that allow the original `created_at` timestamp to be set. This preserves the narrative history of the ticket accurately in Zendesk’s audit log. Using a system user for the import process is often recommended to maintain the integrity of the original author and time of the customer-facing events.
- Bulk API Limits: Zendesk APIs, particularly for tickets and users, employ rate limits and bulk limits (often around 100 items per batch). For massive datasets, utilize the `create_many` and `update_many` endpoints and strictly adhere to the rate limit headers provided by Zendesk to prevent throttling or temporary blocks. For heavy ticket volume, explore Incremental Exports APIs, which can retrieve mass data efficiently for export purposes.
Summary
The migration from Trengo to Zendesk is primarily an API-driven project focused on data translation and integrity.
By sequentially importing administrative objects (Custom Fields, Groups, Organizations, Users) before transactional data (Tickets, Articles), you correctly build dependencies and ensure a functional environment from day one.
Post-migration tasks should immediately focus on setting up automation and validating redirected paths for historical content access.
If you’d rather focus on your revenue instead of wrestling with mapping sheets and pagination loops, ClonePartner can handle the full migration for you. Every project gets a dedicated engineer who understands the nuances of both APIs and ensures zero downtime.