The Complete Guide to Migrating from Kustomer to Trengo

Moving your customer support operations from Kustomer to Trengo is a significant transition that requires a thoughtful strategy to preserve your valuable data history.

This guide covers the process of moving your team, your customers, and your entire knowledge base into your new workspace — including the edge cases and failure modes that trip up most migrations.

Pre-migration readiness checklist

Before writing a single line of migration code, verify each item below. Treat this as a binary pass/fail gate.

• Kustomer data export completed and format confirmed (JSON via API or CSV via bulk export)
• All KObject types inventoried — list every object schema and decide: Custom Field, Note-append, or discard
• Trengo workspace provisioned in the correct data region
• DPAs confirmed with both Kustomer and Trengo covering the transfer
• Cross-border transfer mechanism confirmed if Kustomer is EU-hosted and Trengo workspace is not
• Trengo Custom Fields defined for all migrating metadata and flattened KObject data
• Labels library created to match Kustomer Tags
• Users invited and assigned to Teams before any ticket migration begins
• External ID custom field created in Trengo (stores originating Kustomer ID for idempotent re-runs)
• Rate limit headroom confirmed — Kustomer allows approximately 120 creation events per minute per customer object
• Rollback plan documented and tested on staging

Define your migration scope

Before you begin moving data, you must understand how different types of information will travel between platforms. Not everything fits into a simple automated process, so categorizing your data is the first step toward a successful transition.

What should be migrated via the API

Most of your core support data can be transferred using automated scripts. This includes the fundamental building blocks of your workspace such as your Users and Teams, as well as the Identity data found in your Customer records.

You will also want to move the actual work history, which consists of Conversations, Messages, and internal Notes.

To keep everything organized, your existing Tags and Shortcuts should also be moved through the API to match their new counterparts: Labels and Quick Replies.

Finally, your Knowledge Base, including all Categories and Articles, is best handled through automated import to maintain formatting and hierarchy.

What has to be configured manually

Some elements of Kustomer are governed by logic that does not have a direct digital bridge to Trengo.

Your Business Schedules, for instance, define when your team is available to help customers and must be recreated in the settings of your new workspace.

Similarly, the complex logic used for Queues and Routing rules needs to be rebuilt by hand to ensure that incoming requests are funneled to the correct Inboxes and Teams according to Trengo's specific workflow engine.

Snoozes and Sub-statuses are also Kustomer-specific modifiers that do not have an identical twin in Trengo. The mapping to Labels shown in the table below is a lossy transformation — you lose the temporal dimension of Snoozes and the structured hierarchy of Sub-statuses. An alternative approach is to append the original status history to internal Notes on each ticket, preserving the information even though it can no longer drive automation. Evaluate which approach matters more for your reporting and agent workflows before committing.

What has to be archived

Kustomer uses a unique data entity known as KObjects, or Custom Objects, to store specialized data like order histories or loyalty points. Trengo does not have a direct equivalent for these standalone objects.

To preserve this information, you flatten KObject data into Custom Fields on the Contact or Ticket. The transformation is non-trivial. Here is a concrete example:

Source: Kustomer KObject (order history)

{
  "type": "order",
  "externalId": "ORD-9821",
  "attributes": {
    "orderTotal": 149.99,
    "status": "shipped",
    "items": ["SKU-001", "SKU-002"]
  }
}

Target: Trengo Contact Custom Field value

order_id: ORD-9821 | total: 149.99 | status: shipped | items: SKU-001, SKU-002

Decide upfront which KObject fields are worth preserving, choose a consistent delimiter format, and handle nested or multi-value fields explicitly. Undocumented serialization choices will create inconsistencies that are expensive to clean up later.

Feature gap analysis

Several Kustomer capabilities have no direct Trengo equivalent. Understanding these gaps before migration lets you make deliberate decisions rather than discovering them mid-project.

For each gap, make an explicit decision before migration starts: accept the loss, find a workaround, or block migration until a solution is defined.

Prepare Trengo for data import

Before the data starts flowing, your new environment needs a foundation. Every piece of information needs a clear place to land.

• Set up your Teams to mirror your organizational departments.
• Invite your Users and ensure they are assigned to the correct Teams so that historical tickets can be attributed to the right people.
• Define your Custom Fields for both Tickets and Contacts to accommodate any metadata or flattened KObject data you are bringing over.
• Create a library of Labels that corresponds to your Kustomer Tags so your reporting remains consistent.
• Build your Quick Replies to replace your Kustomer Shortcuts, ensuring your team has their canned responses ready to go.

Migrate objects

The order in which you move your data is crucial because many items rely on others already being in place. Here is the logical path you should follow to bring your history to life in Trengo.

Foundation and Identity: Start with your team structure. You will move your Teams first, followed by your Users. Once the people are in place, you can move your Customers into Trengo Profiles and Contacts.

This step is vital because every conversation you migrate later must be attached to an existing contact.

Trengo is quite accommodating here: if you attempt to create a contact that already exists based on an identifier like an email, the system will simply return the existing record instead of throwing an error.

Knowledge Base Structure: Next, you should move your self-service content. Migrate your Kustomer KB Categories into Trengo Categories.

Be aware that Trengo offers an additional organizational layer called Sections, which you can use to further refine your Help Center hierarchy.

After the categories are set, you can bring over your Articles and link them to the appropriate sections.

Relational Support Data: Now you are ready for the core support history — the Conversations, Messages, and Notes that make up the actual record of customer interactions. Move your Conversations as Trengo Tickets, ensuring they are linked to the correct Profiles and assigned to the right Users.

Inside those tickets, you will import your actual Messages. Trengo has specific processes for importing text-based messages versus email messages to ensure they are formatted correctly in the timeline.

Any internal team discussions found in Kustomer Notes should be added to the tickets or contacts as Trengo Notes to keep that context alive.

Handling Attachments: Attachments require a two-step process. You must first upload the file to Trengo's temporary storage to receive a secure link.

You then include that link when importing the message. Be careful with your timing here because the system will automatically remove unused file uploads, so you should send the message import request as soon as the file upload is complete.

Data Mapping:

Known failure modes

These are the most common points of failure in a Kustomer-to-Trengo migration and how to mitigate them.

1. Rate limit exhaustion. Kustomer allows approximately 120 creation events per minute per customer object. Exceeding this returns an error. Implement exponential backoff with jitter in your migration script and monitor for 429 responses.
2. Orphaned tickets. If a contact creation fails silently and you attempt to import a ticket referencing that contact, the ticket import will fail or produce an unlinked record. Validate contact creation responses before proceeding to ticket import.
3. Attachment expiry. Trengo clears unused file uploads from temporary storage automatically. If your script uploads a file but fails to link it to a message before the TTL expires, the attachment is lost. Keep upload and message-link operations in the same atomic step in your script.
4. Pre-signed URL expiry. Draft attachment handling returns a pre-signed S3 URL valid for a limited duration. If your script queues the URL for later use rather than consuming it immediately, it will be expired by the time you attempt to use it. Consume pre-signed URLs within the same execution block.
5. KObject schema drift. If different KObject records of the same type have inconsistent field sets (a common occurrence in live systems), your serialization logic will produce inconsistent Custom Field values. Audit KObject schemas before migration and normalize them.
6. Encoding and character set issues. Messages containing non-UTF-8 characters, emoji sequences, or right-to-left text may fail on import or display incorrectly. Run a character set audit on exported message content before import.
7. Merged contact collisions. Kustomer allows contact merging. If a merged contact in Kustomer maps to two separate email addresses, Trengo's deduplication logic may create two separate profiles. Audit merged contacts before migration and decide on canonical identifiers.
8. Automation conflicts. If Trengo automations are active during migration, imported tickets may trigger workflows unintentionally (e.g., auto-reply to migrated historical tickets). Disable all Trengo automations before starting ticket import and re-enable after validation.

Post-migration validation

Before you declare the migration complete, verify the data actually made it across intact:

• Record count comparison: Export total counts for Contacts, Tickets, Messages, and Notes from both Kustomer and Trengo. The numbers should match. If they don't, use the external ID mapping to identify which records are missing.
• Spot-check samples: Pick 10–20 tickets across different time ranges and agents. Open them in Trengo and compare against the originals in Kustomer. Verify that messages appear in the correct order, attachments are accessible and not returning 404s, and internal notes are present.
• Attachment URL lifespan check: Confirm that attachment URLs embedded in migrated messages resolve correctly 24–48 hours after migration completes, not just immediately after import.
• Contact integrity: Confirm that merged or deduplicated contacts in Kustomer resolved correctly in Trengo. Check that email addresses and phone numbers are linked to the right profiles.
• Label and field audit: Verify that Tags mapped to the correct Labels and that Custom Field values populated as expected.
• Feature gap verification: For each item in the feature gap table above, confirm the agreed workaround is in place and agents have been briefed.

Rollback and cutover strategy

No migration goes to plan in every edge case. Define your rollback criteria before go-live, not after.

Parallel running period: Keep your Kustomer instance active and readable for a minimum period after go-live — at least two weeks is a practical baseline for support teams. Do not cancel the Kustomer contract until agents have confirmed they no longer need to reference historical records there.

Rollback triggers: Define explicit conditions that would trigger a rollback or halt. Examples: more than 5% of spot-checked tickets show data discrepancies; attachment retrieval failure rate exceeds a defined threshold; contact count in Trengo is more than 1% lower than Kustomer export.

Webhook and live event redirection: If your Kustomer instance receives live events via webhooks during migration, those events need to be drained or redirected before cutover. Migrating data while new tickets are being created in Kustomer creates a moving target. Freeze new ticket creation in Kustomer (maintenance window) or redirect inbound channels to Trengo before the final data sync.

Partial rollback: If validation fails on a specific object type (e.g., attachments) but passes on others, you may be able to re-run only the failing object type using the external ID mapping to skip already-migrated records rather than rolling back the entire migration.

Post-migration configuration

Once the data transfer is validated, there are several live elements you must configure to get your team back to full productivity.

• Rebuild your automation Workflows to handle actions like auto-replies, tagging, and ticket assignments.
• Configure your Inboxes and connect your various communication channels like Email, SMS, and WhatsApp.
• Manually set your Business Hours for each channel to manage customer expectations.
• Set up your SLA policies to ensure your team meets its response time goals.
• Test your routing rules to confirm that new tickets are flowing to the correct teams as expected.

Operational tips

1. Use external IDs for idempotent re-runs. When you migrate objects from Kustomer, store the original Kustomer ID in a Custom Field in Trengo. On restart after a script failure, query Trengo for records that already have a Kustomer external ID and skip them. This prevents duplicate records without requiring a full restart.
2. Leverage Trengo's profile deduplication. Trengo returns the existing contact record rather than an error when a creation request matches an existing identifier (e.g., email). This means you can safely re-run contact migration without corrupting your database.
3. Disable automations during ticket import. Re-enable only after the validation phase is complete.
4. Drain Kustomer webhooks before final cutover. Any live event streams pointing at Kustomer need to be redirected before you cut over inbound channels to Trengo.

Summary

Migrating from Kustomer to Trengo is a manageable process when you break it down into logical steps.

By establishing your team structure first, followed by customer identities, and finally the conversation data (Tickets, Messages, Notes, and Attachments), you can build a complete picture of your support history in your new workspace.

Items like routing rules, business hours, and Snooze/Sub-status mappings require manual decisions and configuration. Several Kustomer capabilities — sentiment scoring, KObjects, and timeline views — have no direct Trengo equivalent; treat the feature gap table as a required decision log, not optional reading. The result is a clean, organized workspace — but plan for a transition period where agents may need to reference Kustomer exports for historical reporting that doesn't carry over natively.

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:

• Kustomer API Reference
• Trengo API Reference