Skip to main content

Tejas Mondeeri

·8 min read

The Complete Guide to Migrating from Help Scout to Trengo

Migrate from Help Scout to Trengo with precision. Learn how to map API objects, import historical conversation threads, and transfer Docs content seamlessly.

ClonePartner Help Scout to Trengo migration

Moving your customer service operations to a new platform is a major undertaking, but transitioning from Help Scout to Trengo can unlock new possibilities in communication efficiency.

This guide outlines a structured, object-by-object approach to ensure a smooth transition of your valuable data, leveraging Trengo’s robust API capabilities for maximum efficiency.

We will cover everything from setting up your foundation to moving historical conversations and configuring your final environment.

Define Your Migration Scope

Successful migration hinges on clearly defining what data will be moved via automation, what requires manual setup, and what old data can be archived entirely.

API Migration:

The majority of structural and historical data can be efficiently migrated using APIs, minimizing downtime and human error.

This includes core team structures, customer data, historical conversations, and knowledge base content.

Objects designated for API migration include: Users, Teams, Tags (as Labels), Custom Field Definitions, Customers (as Contacts), Contact Groups, Organizations (as Profiles), Saved Replies (as Quick Replies), Help Center Sites, Help Center Collections (as Categories), Help Center Categories (as Sections), Help Center Articles, and all associated data like Customer Notes, Custom Field Values for customers and conversations, and Conversation Threads (history and attachments).

Manual Configuration:

Certain functional settings and complex configurations need to be manually rebuilt within Trengo because they lack direct API migration paths or are system-dependent.

For instance, processes related to thread schedules, such as Snooze/Thread Schedules, must be configured manually within the new Trengo environment.

Similarly, complex knowledge base linking features like Docs Redirects often require manual reconstruction since no specific API endpoint for this function is apparent in the Trengo API references provided.

Data Archiving:

Historical reports, especially metric aggregates like New Tickets or Assigned Tickets counts, may not need to be migrated directly as data objects, since Trengo calculates its own reporting based on the imported conversational history.

While Trengo allows you to retrieve report summaries, such as agent performance reports and ticket details reports, using its Reporting v2 endpoints, the underlying Help Scout metrics themselves should be treated as historical records for archival purposes on the original platform.

Prepare Trengo for Data Import

Before attempting to push historical data, you must establish the organizational structure in Trengo. This foundational phase is critical because later migration steps depend on the unique identifiers created during this initial setup.

  1. Establish User and Team Structure: Begin by migrating your staff. You can create the necessary Users (agents) in Trengo. Immediately afterward, recreate the corresponding Teams that structure your support operation. This ensures that when tickets and assignments are imported later, there are valid users and teams to link them to.
  2. Define Custom Fields and Labels: Next, replicate your Help Scout custom data structures. Migrate your Custom Field Definitions to Trengo’s Custom Fields, creating the necessary fields before data arrives. Likewise, migrate your Tags as Labels using Trengo’s dedicated Label creation function. These definitions are essential for carrying over metadata attached to contacts and conversations.

Migrate Objects

This section details the necessary sequencing and data modeling transformations to migrate objects successfully via API.

  1. Customers and Groups

    Begin the core data migration with customer records, as they form the backbone for conversation history.

    • Customers (Contacts): Every Help Scout Customer maps directly to a Contact in Trengo, which can be created individually. Customer-level metadata, such as Customer Custom Field Values, can then be attached to the respective contacts after they are created. Customer Notes also transfer directly using the note creation endpoint associated with contacts.

    • Organizations (Profiles): Help Scout Organizations must be modeled as Profiles in Trengo. Once a Profile is created, its corresponding Customer Contacts must be linked to it using the function to attach a contact to a profile. Any organization-level attributes (Organization Custom Field Values) can be assigned to the Profile object. Contact Groups (Groups of Contacts) can also be created to maintain audience segmentation from Help Scout.

  2. Knowledge Base (Help Center)

    The Help Scout Docs structure maps neatly into Trengo’s Help Center structure and must be migrated hierarchically.

    • Help Center Sites: These form the top layer, migrating directly as Help Centers.

    • Collections: Help Scout Collections should be mapped and created as Categories within the corresponding Help Center.

    • Categories: The next layer, Help Scout Categories, map to Sections within the Trengo Categories.

    • Articles: Finally, migrate the core content as Articles. Ensure all associated content elements, like Help Scout Blocks, are correctly recreated as Blocks within Trengo Articles to maintain document formatting and structure.

  3. Conversations and History

    This is the most complex stage, requiring sequential import of the ticket container, followed by its historical content and metadata.

    • Conversations (Tickets): Start by creating the ticket container in Trengo for every conversation in Help Scout. This establishes the primary record.

    • Conversation Threads (History): Historical thread content must be imported in pieces. For email-based history, use the import email message tool. For pure textual exchanges, use the import text message tool. A rate limit constrains these messages, so plan for appropriate timing and chunking.

    • Conversation Attachments: Files associated with threads must first be uploaded using Trengo’s file upload mechanisms. The returned file identifier is then used when importing the message/thread associated with that media file.

    • Metadata Application: Once the ticket is created and history imported, apply the remaining data:

      • Conversation Custom Field Values: Use the custom data function to set the appropriate values on the migrated tickets.

      • Conversation Tags: Apply migrated tags (now Labels) to the ticket.

    • Final Status and Assignment: Update the status of the migrated ticket (e.g., closing resolved tickets) and ensure the historical assignment is correctly noted on the record. You may also mark tickets as favorited to replicate historical preferences.

Post Migration Configuration

After all data is successfully migrated, the final layer of business logic and non-API configurations must be set up manually in Trengo.

  • Workflow Recreation: Trengo requires manual configuration for workflows, which automate ticket handling based on specific triggers and conditions. Any complex routing logic, auto-replies, or assignment rules defined in Help Scout must be meticulously rebuilt within the Trengo interface.

  • Channel Integration Setup: Reconnect live channels (email inboxes, chat widgets, social channels) to Trengo, ensuring they route incoming traffic to the correct migrated teams and channels.

  • Reporting Verification: Although conversation data is migrated, the Trengo reporting dashboard relies on real-time data processing. Validate that historical data is reflected accurately in the new Trengo reports, focusing on metrics such as average resolution time and user performance, which Trengo can report on for both new and existing ticket details.

Insider Secrets

Having successfully executed migrations, we know that success often lies in handling subtle data transformation issues and leveraging the platform constraints.

  • Rate Limit Management for History: Trengo enforces a rate limit on importing historical messages (60 per minute for imported messages). This is the biggest constraint for rapid migration. You should build in queuing and exponential backoff mechanisms to manage API calls, prioritizing recent or open conversations first, and then handling older, closed history during off-peak hours.

  • Handling User Roles and Permissions: When migrating Users, ensure that the Trengo roles and permissions match the capabilities granted in Help Scout. Improper mapping can lead to agents lacking access to necessary channels or functions upon go-live.

  • The Attachment Workflow: The process for attaching files is a multi-step API process: you must upload the file first to receive an identifier, and then create the message referencing that identifier. This sequence is crucial for migrating media attachments accurately, especially for historical messages. For email, file uploads must be followed immediately by sending the email that references them.

  • Trengo’s Profile/Contact Split: Understand that the Help Scout concept of a single customer record is split in Trengo: Contacts are the individual people (like John Smith), while Profiles are typically the collective entity they belong to (like "Acme Corp"). Migrating an Organization means creating a Profile first and then linking existing Contacts to it using the Profile contact attachment endpoint. This separation is foundational to Trengo’s data model.

Summary

The Help Scout to Trengo migration is highly achievable using API automation for almost all key objects, provided you follow a strict, logical sequence.

By starting with structural elements like Users, Teams, and Custom Field Definitions, moving on to Contacts and Help Center organization, and finally tackling the intensive process of importing historical Tickets and their messages, you ensure data integrity and a smooth transition to your new communication platform.

Remember to allocate time for manual configuration of platform-specific settings like workflows and redirects once the data is settled.

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.

Further reading