---
title: "How to Migrate from Re:amaze to Zendesk: The Complete Technical Guide"
slug: how-to-migrate-from-reamaze-to-zendesk-the-complete-technical-guide
date: 2026-07-16
author: Nachi
categories: [Migration Guide, "Re:amaze", Zendesk]
excerpt: "Step-by-step technical guide to migrating Re:amaze to Zendesk. Covers API rate limits, object mapping, attachment edge cases, and Ticket Import API usage."
tldr: "Use Zendesk's Ticket Import API to preserve timestamps. Files over 50MB need external hosting. Plan 5 to 12 business days for a single-brand Re:amaze migration."
canonical: https://clonepartner.com/blog/how-to-migrate-from-reamaze-to-zendesk-the-complete-technical-guide/
---

# How to Migrate from Re:amaze to Zendesk: The Complete Technical Guide


## What Is a Re:amaze to Zendesk Migration?

A Re:amaze to Zendesk migration extracts Conversations, Messages, Contacts, Staff, Channels, Tags, Articles, Response Templates, Notes, and Custom Data Attributes from Re:amaze and loads them into Zendesk as Tickets, Comments, Users, Organizations, Groups, Tags, Help Center Articles, Macros, Custom Fields, and Attachments. It is a data model translation, not a CSV swap.

### Why Teams Move from Re:amaze to Zendesk

Teams leave Re:amaze for platform-specific reasons:

- **Integration ecosystem.** Zendesk's marketplace lists 1,500+ pre-built integrations. Re:amaze lists roughly 40 native integrations. Teams needing deep connections to Salesforce, Jira, or BI tools outgrow Re:amaze's ecosystem quickly.
- **Enterprise reporting and SLA management.** Zendesk Explore offers native SLA policies, custom dashboards, and granular CSAT/NPS analytics. Re:amaze's built-in reporting covers volume and response time but lacks the depth required for enterprise compliance.
- **Multi-channel scale.** Zendesk's omnichannel routing engine, Answer Bot, and AI-powered Intelligent Triage are architecturally more mature for teams handling 50,000+ conversations per month.
- **HIPAA and compliance posture.** Zendesk offers a HIPAA-eligible environment (Business Associate Agreement on Enterprise plans). Re:amaze does not offer a comparable compliance tier.
- **Ticket lifecycle governance.** Re:amaze centers on conversations with Shopify order data, draft orders, refunds, and Liquid variables inside the support workflow. Zendesk gives you first-class ticket lifecycle states, multi-brand governance, Guide permissioning, and a dedicated historical Ticket Import API.

### Core Architectural Differences That Make This Migration Non-Trivial

1. **Conversation vs. Ticket model.** Re:amaze Conversations are continuous, reopenable threads. Zendesk Tickets have a discrete lifecycle (New → Open → Pending → On-hold → Solved → Closed) and cannot be reopened once Closed.
2. **Recipients vs. CCs.** Re:amaze does not use traditional CCs. It adds recipients to the conversation who receive future correspondences. Zendesk has a structured CC and Follower model that must be explicitly mapped. Zendesk caps `email_ccs` at 48 recipients and may truncate silently if that limit is exceeded.
3. **Custom data model.** Re:amaze stores custom fields as a freeform `data` hash on both Conversations and Contacts. Zendesk requires pre-defined Custom Fields with explicit field types (text, dropdown, checkbox, numeric, regex).
4. **Brand vs. account scoping.** Re:amaze API requests are brand-scoped, but contacts are account-scoped. This creates duplicate and ownership edge cases in multi-brand migrations.

## How Do Re:amaze Objects Map to Zendesk?

The fastest way to break this migration is to map by label instead of behavior. Map by thread ownership, message visibility, participant model, and destination lifecycle rules.

| Re:amaze Object | Zendesk Object | Notes / Caveats |
|---|---|---|
| Conversation | Ticket | One Conversation = one Ticket. Use Re:amaze `slug` as Zendesk `external_id` for idempotent reruns and reconciliation. |
| Message (`visibility: 0`) | Public Comment | Request `include=original_body` and map HTML to `html_body`. Re:amaze `/messages` returns newest first—reverse before import. |
| Message (`visibility: 1`) | Internal Note | Map to Zendesk comment with `public: false`. |
| Message (`visibility: 2`) | Skip or audit note | Collision-detected system message, not ordinary customer history. Fold into a private note or skip entirely. |
| Contact | User (end-user) | Contacts can hold multiple identities (email, phone, social). Map primary email first, then add identities. Contacts are account-scoped, not brand-scoped. |
| Staff | User (agent) | Must be created before ticket import so `assignee_id` resolves. Re:amaze staff `role` is informational only in the public API. Zendesk tickets cannot be assigned to an agent without a group. |
| Channel | Group | Re:amaze Channels (e.g., "support", "sales") map to Zendesk Groups. No single Zendesk field preserves all Re:amaze channel meaning—preserve category slug and origin in custom fields or tags. |
| Brand | Brand | Direct 1:1 mapping if using Zendesk multi-brand. Must exist before ticket import. |
| Tag | Tag | Direct 1:1 transfer. Zendesk tags are lowercase and do not support spaces (spaces become underscores). Verify formatting before import. |
| Article (FAQ) | Help Center Article | Requires separate Help Center API calls. HTML body transfers, but Re:amaze-specific embeds do not. Map Re:amaze Topics to Zendesk Sections. |
| Response Template | Macro | Must be manually rebuilt. Re:amaze exposes templates via API, but Shopify Liquid variables do not transfer. No automated migration path. |
| Workflow | Trigger/Automation | Must be manually rebuilt. No programmatic migration path. |
| Note (Contact Note) | User internal note | Zendesk User API supports `notes` field (text only). |
| Custom Data (`data` hash) | Custom Ticket/User Field | Freeform key-value pairs must be mapped to pre-created Zendesk Custom Fields with defined types. |
| Recipients | CCs / Followers | Re:amaze recipients array must be split into Zendesk `collaborator_ids` (CCs) or `follower_ids`. Zendesk caps CCs at 48. |
| Satisfaction Rating | Satisfaction Rating | Historical ratings can be imported but require custom handling. Zendesk has its own CSAT system. |
| Shopify/BigCommerce context | Zendesk Shopify App sidebar | Live e-commerce context does not migrate. Reconnect via Zendesk's Shopify integration post-migration. |

### Conversation Status Mapping

| Re:amaze Status | Integer | Zendesk Status |
|---|---|---|
| Open | 0 | open |
| Responded | 1 | pending |
| Done | 2 | solved |
| Spam | 3 | (exclude from migration) |
| Archived | 4 | closed (with `archive_immediately`) |
| On Hold | 5 | on-hold |
| Auto-Resolved | 6 | solved |
| Chatbot Resolved | 7 | solved |

Use `solved` rather than `closed` for any thread that might need a future reply. Zendesk closed tickets cannot be reopened.

### What Has No Clean Equivalent on Zendesk?

- **Re:amaze Cues (proactive messages).** No import path. Rebuild as Zendesk proactive messaging triggers.
- **Re:amaze Peek (live visitor activity).** Zendesk does not have a native equivalent.
- **E-commerce sidebar data (Shopify order context, BigCommerce data).** This is a live integration, not stored data. Reinstall the Zendesk Shopify app post-migration. Decide which parts should become Zendesk fields, tags, or rebuilt integrations.
- **Co-browsing sessions.** Session data is not exportable.
- **Unlisted FAQ articles.** Re:amaze supports unlisted articles in help content, but the public article API documents only published, draft, and internal states. Unlisted articles need explicit testing and manual handling.
- **Staff permissions.** Re:amaze exposes a staff role hash, but its own docs indicate this is not a stable permissions API. Rebuild permissions in Zendesk manually.
- **Voice conversations (origin code 10).** Re:amaze tracks voice as message origin 10. Zendesk Talk is a separate product with its own data model. Voice conversation records migrate as standard tickets with an `origin-voice` tag, not as Zendesk Talk call records.
- **Webhooks and third-party integrations.** Re:amaze webhook configurations and non-Shopify integrations do not transfer. Audit active webhooks in Re:amaze and recreate them as Zendesk webhook subscriptions or third-party app installations.

## What Are the Migration Approaches for Re:amaze to Zendesk?

### Approach 1: API-Based Custom Migration Script

Write a script that calls Re:amaze's REST API to extract data as JSON, transforms it, and loads it into Zendesk via the Ticket Import API.

**When to use:** Teams with engineering capacity who need full control over field mapping and transformation logic.

- **Pros:** Full control over edge cases, preserves timestamps via Import API, no per-record fees.
- **Cons:** Requires 40 to 80 hours of engineering time. Rate limit handling, retry logic, and attachment re-upload logic add complexity.
- **Scalability:** Works for any volume with proper batching.
- **Complexity:** Medium to High.

**Note on Re:amaze CSV exports:** Re:amaze does not offer a self-service bulk data export in its admin UI. Some teams have obtained database-level exports by contacting Re:amaze support directly. If available, a CSV or database dump can supplement API extraction and reduce rate-limit pressure during the extraction phase, though the data still requires transformation before Zendesk import.

### Approach 2: Third-Party Migration Tool

SaaS tools like Help Desk Migration offer a visual mapping interface with per-record pricing (typically $2–$10 per 100 records depending on volume tier, plus per-attachment fees). Commslayer positions itself as a self-serve "1-click migration tool" between helpdesks.

**When to use:** Small teams (under 5,000 conversations) who want a faster path without writing code.

- **Pros:** No engineering required, visual mapping, preview before committing.
- **Cons:** Per-record pricing can reach $1,000–$3,000+ for datasets above 20,000 conversations. Limited control over edge cases. Custom field and attachment handling may be incomplete. Test recipient overflow, attachment sizes, and knowledge base visibility before committing.
- **Scalability:** Good for small to mid-size. Less flexible for enterprise volumes or complex custom fields.
- **Complexity:** Low.

### Approach 3: Managed Migration Service

A dedicated migration team handles extraction, transformation, loading, validation, and cutover. The service owns the outcome.

**When to use:** Teams with 10,000+ conversations, complex custom fields, large attachments, or zero-downtime requirements.

- **Pros:** Risk transfer. Handles edge cases (attachment oversizing, duplicate contacts, broken threading, recipient splitting). Post-migration validation included.
- **Cons:** Higher upfront cost than DIY (typically $3,000–$15,000+ depending on volume and complexity).
- **Scalability:** Built for enterprise volume.
- **Complexity:** Low (for the customer).

### Approach Comparison

| Factor | Custom API Script | Third-Party Tool | Managed Service |
|---|---|---|---|
| Engineering effort | 40 to 80+ hours | None | None |
| Cost model | Internal eng time | Per-record fee | Fixed project fee |
| Custom field handling | Full control | Partial | Full control |
| Attachment handling | Manual (re-upload) | Varies by tool | Handled |
| Timestamp preservation | Yes (Import API) | Depends on tool | Yes |
| Zero-downtime cutover | Requires custom sync | Not typically | Included |
| Best for | Dev teams, <10K records | Small teams, <5K records | Mid-market+, 10K+ records |

If you are choosing between moving all history or archiving part of it, the [Help Desk Data Migration Playbook](https://clonepartner.com/blog/blog/help-desk-data-migration-playbook/) covers the decision framework. One key architectural decision: whether to import all historical conversations into Zendesk or archive older data to a data warehouse (e.g., BigQuery, Snowflake) and import only the last 6–12 months. Archiving reduces migration time, Zendesk storage costs, and API call volume, but requires agents to access a separate system for older history.

## How Do API Rate Limits Affect Migration Throughput?

Design the migration architecture around three facts: Re:amaze is brand-scoped and 429-driven, Zendesk import is batch-oriented, and attachments create far more API load than tickets.

### Re:amaze Extraction Limits

The Re:amaze API is a REST interface at `https://{brand}.reamaze.io/api/v1/`. All requests use HTTP Basic Auth with your login email and API token. Because each token acts on behalf of a user, use an admin or full-visibility service account for extraction.

Re:amaze does not publish a specific numeric rate limit. The official documentation states only that the API is "rate limited to a certain number per minute per API Token" and returns HTTP 429 when exceeded. In practice, expect throttling around 60 to 120 requests per minute depending on endpoint and account tier. This estimate is based on observed behavior during migrations, not official documentation—your mileage will vary. Your extractor needs checkpointing and adaptive backoff instead of hard-coded throughput assumptions.

Key extraction endpoints:

- `GET /api/v1/conversations` — paginated results (default `page_size: 30`), filterable with `filter=all` and `sort=changed`
- `GET /api/v1/conversations/{slug}` — single conversation with metadata
- `GET /api/v1/conversations/{slug}/messages` — messages scoped to a conversation
- `GET /api/v1/messages` — all messages across conversations (filterable by `staff` or `customer`), supports `include=original_body`
- `GET /api/v1/contacts` — paginated contacts
- `GET /api/v1/articles` — FAQ articles
- `GET /api/v1/staff` — staff members
- `GET /api/v1/response_templates` — response templates

> [!WARNING]
> **Undocumented pagination behavior:** Re:amaze's conversation listing paginates with `page` and `page_size` parameters but does not guarantee consistent ordering during active support operations. Extract during low-traffic hours to avoid missed or duplicated records.

### Zendesk Load Limits

Zendesk API rate limits vary by plan:

| Zendesk Plan | Requests per Minute |
|---|---|
| Team | 200 |
| Growth | 400 |
| Professional | 400 |
| Enterprise | 700 |
| Enterprise Plus | 2,500 |
| High Volume API Add-on | 2,500 (replaces plan limit) |

The Ticket Import API (`POST /api/v2/imports/tickets`) counts against these account-wide limits. The bulk variant (`POST /api/v2/imports/tickets/create_many`) accepts up to **100 tickets per request**, which is the most efficient path for large migrations.

Help Center API calls use the same rate limit pool as Support API calls on most plans. However, Help Center content can be migrated in a separate time window to avoid competing with ticket import throughput.

Note that bulk user import via `POST /api/v2/users/create_many` is not enabled by default on all Zendesk instances—confirm access before relying on it.

### Throughput Math

On a Zendesk Professional plan (400 req/min) using the bulk import endpoint:

- 1 bulk request = up to 100 tickets
- 400 requests/min = up to 40,000 tickets/min theoretical maximum
- Practical throughput with attachment uploads and retry overhead: **2,000 to 5,000 tickets per hour**

Attachments are the real bottleneck. Each file requires a separate upload call (`POST /api/v2/uploads`), and upload tokens are single-use. A 50,000-conversation migration with an average of 1.5 attachments per conversation consumes roughly 125,000 API calls for attachments alone. At 400 requests per minute, that upload phase alone is over 5 hours before retries and source-side throttling.

## What Is the Step-by-Step Migration Process?

The order of operations prevents broken relationships. Import dependent objects first—Zendesk assignment and visibility rules depend on pre-created groups, users, brands, and Guide structures.

### Step 0: Update DNS Records for Email Deliverability

Before cutover, update your SPF, DKIM, and DMARC records to authorize Zendesk's sending infrastructure. Re:amaze and Zendesk use different mail servers. If you skip this step, post-migration emails from Zendesk may land in spam or fail DMARC alignment checks.

- **SPF:** Add Zendesk's include directive (`include:mail.zendesk.com`) to your domain's SPF record.
- **DKIM:** Generate and publish the DKIM key pair through Zendesk Admin → Channels → Email. Zendesk provides the DNS TXT record value.
- **DMARC:** If you enforce `p=reject` or `p=quarantine`, verify that Zendesk-sent emails pass alignment before switching live traffic. Send test emails from your Zendesk sandbox to confirm.

Failure to update DNS records is one of the most common causes of post-migration email deliverability issues. Plan for 24–48 hours of DNS propagation before cutover.

### Step 1: Inventory and Scope

Decide which brands, channels, date ranges, tags, and FAQ articles are in scope. For cutover planning, the [Zero-Downtime Help Desk Data Migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/) guide covers the delta-sync approach.

### Step 2: Provision a Zendesk Sandbox

Run the full migration against a Zendesk sandbox before touching production. Sandbox availability depends on your Zendesk plan:

- **Professional and above:** One sandbox included. Request via Zendesk Admin Center → Account → Sandbox.
- **Team and Growth:** No sandbox included. Use a separate trial Zendesk instance as a test target, or request a temporary sandbox from Zendesk support.

The sandbox should mirror your production Zendesk configuration: same custom fields, groups, brands, and trigger/automation rules. After the test migration, validate data integrity in the sandbox before proceeding to production.

### Step 3: Extract and Stage Re:amaze Data

Pull all data from Re:amaze's API and store it in a local staging database or JSON files.

```python
import requests
import time

BRAND = "yourbrand"
EMAIL = "admin@example.com"
TOKEN = "your-api-token"
BASE = f"https://{BRAND}.reamaze.io/api/v1"

def fetch_all_conversations():
    page = 1
    all_convos = []
    while True:
        resp = requests.get(
            f"{BASE}/conversations",
            auth=(EMAIL, TOKEN),
            headers={"Accept": "application/json"},
            params={"page": page, "filter": "all", "sort": "changed"}
        )
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            time.sleep(retry_after)
            continue
        data = resp.json()
        all_convos.extend(data.get("conversations", []))
        if page >= data.get("page_count", 1):
            break
        page += 1
        time.sleep(1)  # respect rate limits
    return all_convos
```

```bash
# Example extraction calls
curl 'https://{brand}.reamaze.io/api/v1/conversations?filter=all&sort=changed&page=1' \
  -u '{login_email}:{reamaze_api_token}' \
  -H 'Accept: application/json'

curl 'https://{brand}.reamaze.io/api/v1/messages?include=original_body&page=1' \
  -u '{login_email}:{reamaze_api_token}' \
  -H 'Accept: application/json'
```

### Step 4: Normalize Contacts and Recipients

De-duplicate contacts by primary email before import. Re:amaze allows merging customer profiles but retains ghost records of merged profiles. Split staff observers from customer-visible recipients—Re:amaze `followers` includes both active participants and CC recipients, which must be separated before mapping to Zendesk's distinct `follower_ids` and `collaborator_ids`.

> [!WARNING]
> **Zendesk rejects tickets where the requester is suspended.** If any Re:amaze contacts were archived or blocked, you must either skip their conversations or temporarily create them as active users in Zendesk.

> [!WARNING]
> **GDPR and data privacy:** Migrating customer PII between platforms requires a lawful basis under GDPR (typically legitimate interest or contract performance). Ensure you have a Data Processing Agreement (DPA) with both Re:amaze and Zendesk. If any contacts have exercised right-to-erasure requests in Re:amaze, do not migrate their data. For EU-based teams, document the migration in your Records of Processing Activities (ROPA).

### Step 5: Create Zendesk Organizations, Groups, and Brands

Map Re:amaze Brands to Zendesk Brands (if multi-brand) and Re:amaze Channels to Zendesk Groups. Create these first because Users and Tickets reference them by ID.

### Step 6: Import Users (Contacts and Staff)

Use Zendesk's `POST /api/v2/users/create_many` endpoint (100 users per batch). Import staff as agents and contacts as end-users. Store the Re:amaze email → Zendesk `user_id` mapping for ticket import. Zendesk will reject user creation if a user with that email already exists (it updates instead).

### Step 7: Upload Attachments

Download each file from Re:amaze's attachment URL and upload to Zendesk using `POST /api/v2/uploads`. Store the returned `token` for use in the ticket comment payload.

Re:amaze allows attachments up to 100MB. Zendesk's per-file limit is 50MB. Files between 50MB and 100MB cannot be imported to Zendesk and must be hosted externally (e.g., S3, Google Drive) with a download link placed in the comment body.

### Step 8: Import Tickets via the Ticket Import API

Use `POST /api/v2/imports/tickets` (single) or `POST /api/v2/imports/tickets/create_many` (batch of up to 100). This endpoint preserves `created_at`, `updated_at`, and `solved_at` timestamps. For closed/archived conversations, pass `archive_immediately=true` to bypass the normal ticket lifecycle and keep closed history out of the active queue.

```python
import requests

ZD_SUBDOMAIN = "yourcompany"
ZD_EMAIL = "admin@example.com"
ZD_TOKEN = "zendesk-api-token"

def import_ticket(conversation, user_map, attachment_tokens):
    # Re:amaze returns messages newest-first — reverse for correct ordering
    messages = sorted(conversation["messages"], key=lambda m: m["created_at"])

    comments = []
    for msg in messages:
        # Skip collision-detected system messages (visibility=2)
        if msg.get("visibility") == 2:
            continue

        comment = {
            "author_id": user_map.get(msg["user"]["email"]),
            "created_at": msg["created_at"],
            "public": msg["visibility"] == 0
        }

        # Prefer original HTML body when available
        if msg.get("original_body"):
            comment["html_body"] = msg["original_body"]
        else:
            comment["value"] = msg["body"]

        # Handle attachment-only messages (empty body causes rejection)
        if not comment.get("html_body") and not comment.get("value"):
            comment["value"] = "(Attachment only)"

        if msg.get("slug") in attachment_tokens:
            comment["uploads"] = attachment_tokens[msg["slug"]]
        comments.append(comment)

    payload = {
        "ticket": {
            "subject": conversation["subject"],
            "comments": comments,
            "requester_id": user_map.get(
                conversation["author"]["email"]
            ),
            "external_id": conversation["slug"],  # enables idempotent reruns
            "status": map_status(conversation["status"]),
            "tags": conversation.get("tag_list", []) + ["migrated-from-reamaze"],
            "created_at": conversation["created_at"],
            "custom_fields": map_custom_fields(
                conversation.get("data", {})
            )
        }
    }

    resp = requests.post(
        f"https://{ZD_SUBDOMAIN}.zendesk.com/api/v2/imports/tickets",
        json=payload,
        auth=(f"{ZD_EMAIL}/token", ZD_TOKEN),
        headers={"Content-Type": "application/json"},
        params={"archive_immediately": "true"}
    )
    return resp.json()
```

> [!TIP]
> **Always tag imported tickets.** Add a tag like `migrated-from-reamaze` to imported tickets and exclude them from SLA reports. Zendesk metrics and SLAs are not supported for imported tickets and will produce inaccurate data if included.

> [!WARNING]
> **Empty comment bodies will fail.** Zendesk's Ticket Import API rejects comments with empty bodies. Re:amaze messages that contain only an attachment and no text body need placeholder text like "(Attachment only)" to prevent rejection.

### Step 9: Import Help Center Articles

Extract Re:amaze FAQ articles via `GET /api/v1/articles` and load into Zendesk Guide via `POST /api/v2/help_center/sections/{id}/articles`. Map Re:amaze Topics to Zendesk Sections—create sections first, then articles. If your Re:amaze instance uses Zendesk multi-brand, Help Center API calls must use the brand-specific subdomain. Re:amaze help articles support unlisted visibility, which has no direct Zendesk equivalent—test these explicitly.

### Step 10: Run Delta Sync and Validate

Re-pull changed conversations from the last checkpoint and import them using the `external_id` (Re:amaze slug) to avoid duplicates. For the validation phase, Zendesk's Incremental Exports API (`GET /api/v2/incremental/tickets?start_time={unix_timestamp}`) is useful for pulling all tickets created or updated since a given timestamp, enabling efficient reconciliation between source and target.

```bash
# Final bulk import with archive
curl 'https://{subdomain}.zendesk.com/api/v2/imports/tickets/create_many?archive_immediately=true' \
  -u '{zendesk_email}/token:{zendesk_api_token}' \
  -H 'Content-Type: application/json' \
  -d @tickets.json
```

## How Long Does a Re:amaze to Zendesk Migration Take?

Realistic timeline for a mid-size instance (10,000 to 50,000 conversations):

| Phase | Duration | Dependencies |
|---|---|---|
| Discovery and data audit | 1 to 2 days | Access to Re:amaze admin |
| DNS/email deliverability prep | 1 to 2 days | Domain DNS access, 24–48h propagation |
| Field mapping and custom field setup | 1 to 2 days | Zendesk admin access |
| Script development or tool configuration | 2 to 3 days | Staging environment |
| Test migration (sandbox) | 1 to 2 days | Zendesk sandbox |
| Production migration | 1 to 2 days | Maintenance window |
| Validation and UAT | 1 to 2 days | QA team |
| **Total** | **8 to 15 business days** | |

For smaller instances (under 5,000 conversations), this compresses to 5 to 7 days. Multi-brand routing, large attachment sets, and knowledge base restructuring can push larger instances into the 2 to 3 week range.

### Risk Register

| Risk | Likelihood | Mitigation |
|---|---|---|
| Re:amaze 429 throttling extends timeline | High | Implement exponential backoff, extract during off-hours, checkpoint progress |
| Attachments over 50MB dropped | Medium | Pre-scan for oversized files, host externally with links |
| Duplicate contacts in Zendesk | Medium | De-duplicate Re:amaze contacts by primary email before import |
| Broken threading (messages out of order) | Low | Sort messages by `created_at` before import (Re:amaze returns newest first) |
| Staff users not pre-created | High | Import all agents and groups before ticket import |
| Recipient truncation | Low to Medium | Preserve overflow recipients in a private note when CC count exceeds 48 |
| Assignment failures | Medium | Pre-create groups and validate agent-group memberships before import |
| Email deliverability failure post-cutover | Medium | Update SPF/DKIM/DMARC 48+ hours before cutover, send test emails |
| GDPR right-to-erasure violation | Low | Audit Re:amaze for erasure requests before exporting PII |
| Zendesk sandbox not available on plan | Low | Provision a trial instance as a test target |

### Rollback Plan

Zendesk does not offer a one-click rollback for imported data. If the migration fails:

1. Use Zendesk's bulk delete to remove imported tickets (filter by the `migrated-from-reamaze` tag).
2. Delete imported users who have no new activity.
3. Re-run the migration after fixing the root cause.

Keep Re:amaze active as the system of record until validation is complete. A parallel-run period of 3 to 5 days is standard practice.

## What Do Customers and Agents Notice During Migration?

If executed correctly, customers notice exactly one thing: the support email sender domain may change if your Re:amaze forwarding address differs from your Zendesk support address. If DNS records (SPF/DKIM/DMARC) are not updated before cutover, emails from Zendesk may land in spam—this is the most visible failure mode for customers.

**History preservation matters.** When a returning customer contacts support on Zendesk, agents need access to the full conversation history from Re:amaze. Using the Ticket Import API preserves original timestamps, so agents see the correct chronological order of past interactions. This directly affects customer trust and agent efficiency.

**What agents will notice immediately:**

- Old Re:amaze conversation references become Zendesk ticket IDs.
- Historical imported tickets do not carry Zendesk SLA metrics—new tickets created after go-live follow your Zendesk SLA policies. Plan your SLA configuration before cutover, not after.
- Re:amaze-specific Shopify context (draft order tools, Liquid variables, live order sidebar) does not migrate as native Zendesk features. Preserve order IDs, storefront IDs, and high-value Shopify markers in Zendesk ticket or user custom fields before retraining the team.
- Imported non-closed tickets do not run Zendesk triggers until a later update. Test active open tickets after cutover.

**What to communicate:**

- Send a brief notice 48 hours before cutover: "We're upgrading our support system. You may see a slightly different email format. Your history is preserved."
- Update your help center URL if it changes.
- Monitor CSAT closely for the first 2 weeks post-migration.
- Ensure all Zendesk macros and triggers are active before routing live customer emails to the new platform.

For a zero-downtime approach during the cutover window, see the [Zero-Downtime Help Desk Data Migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/) guide. Read the [Help Desk Data Migration Playbook](https://clonepartner.com/blog/blog/help-desk-data-migration-playbook/) to determine what historical data actually needs to move.

## What Are the Edge Cases and Known Limitations?

If you only test happy-path email threads, you will miss the real work. These are the failure modes that break migrations.

### Attachments Over 50MB

Re:amaze supports file uploads up to 100MB. Zendesk caps ticket attachments at 50MB per file. Files between 50MB and 100MB will fail on Zendesk's Uploads API. The workaround: upload these files to external storage and insert a download link in the comment body.

### Re:amaze Recipients to Zendesk CCs

Re:amaze does not use traditional CCs. Agents include additional recipients by entering email addresses, stored in a `recipients` array on each message. During migration, map each unique recipient email to a Zendesk user and add them as `collaborator_ids` (CCs) on the ticket. Zendesk caps `email_ccs` at 48 recipients and may truncate silently. For threads exceeding this limit, store overflow recipients in a private note or custom field.

### Message Ordering

Re:amaze's `/messages` endpoint returns messages newest first. You must reverse the order before building Zendesk ticket comments, or the conversation history will appear in reverse chronological order.

### Empty Comment Bodies

Zendesk's Ticket Import API rejects comments with empty bodies. Re:amaze messages that contain only an attachment and no text body will fail. Add placeholder text like "(Attachment only)" to prevent rejection.

### Message Origin Mapping

Re:amaze tracks message origin with numeric codes: Chat (0), Email (1), Twitter (2), Facebook (3), SMS (9), Voice (10), WhatsApp (15), and others. Zendesk tracks channel via the `via` object but does not allow setting it on import. Store the Re:amaze origin as a tag (e.g., `origin-email`, `origin-chat`) to preserve channel context.

### Duplicate Contacts

Re:amaze allows merging customer profiles but retains ghost records of merged profiles. De-duplicate by primary email before importing contacts into Zendesk. Zendesk will reject user creation if a user with that email already exists (it updates instead).

### Workflows and Automations

Re:amaze Workflows, Response Templates, and Cues have no programmatic migration path to Zendesk Triggers, Automations, and Macros. Audit your active Workflows in Re:amaze and document each rule's conditions and actions before cutover. See [how to migrate automations, macros, and workflows](https://clonepartner.com/blog/blog/how-to-migrate-automations-macros-workflows/) for a detailed breakdown.

### Shopify and E-Commerce Integration Context

Re:amaze's Shopify integration surfaces order data, tracking info, and customer metafields directly in the conversation sidebar. This data is fetched live from Shopify and is not stored in Re:amaze's database. It does not migrate. After moving to Zendesk, install the Zendesk Shopify app and re-authenticate to restore order context.

### Unlisted FAQ Articles

Re:amaze supports unlisted articles in help content, but the public article API documents only published, draft, and internal states. Unlisted articles need explicit testing and manual handling during migration.

### Side Conversations and Internal Collaboration

Zendesk's Side Conversations feature (available on Enterprise plans) has no Re:amaze equivalent. If you plan to use Side Conversations post-migration, note that historical Re:amaze internal notes import as standard private comments, not as Side Conversations.

## How Do You Validate a Re:amaze to Zendesk Migration?

Never assume a successful API response means accurate data. Run these five checks every migration.

### 1. Record-Count Reconciliation

Compare totals at every level:

| Object | Re:amaze Count (source) | Zendesk Count (target) | Match? |
|---|---|---|---|
| Conversations / Tickets | X | X | Y/N |
| Messages / Comments | X | X | Y/N |
| Contacts / Users | X | X | Y/N |
| Articles | X | X | Y/N |
| Tags | X | X | Y/N |

Use Zendesk's Incremental Exports API (`GET /api/v2/incremental/tickets?start_time={migration_start_unix}`) to pull all tickets created during the migration window for count verification.

### 2. Field-Level Spot Checks

Sample 2% to 5% of migrated tickets (minimum 50 records). For each sampled ticket, verify:

- Subject line matches
- All comments are present and in correct chronological order
- Internal notes are marked as internal (not visible to customers)
- Tags transferred correctly
- Custom field values match source data
- Attachments are accessible and downloadable
- Requester and assignee are correct
- `created_at` timestamp matches the original Re:amaze conversation creation date

### 3. Attachment Audit

Pre-scan all files near the 50MB threshold. Verify that migrated attachments are downloadable in Zendesk and that oversized files have been handled with external hosting and links.

### 4. Recipient Audit

Check threads with multiple staff and customer participants. Verify CCs and followers mapped correctly and that no recipients were silently truncated past the 48-CC limit.

### 5. UAT Protocol

1. Have 3 agents use Zendesk for 2 days alongside Re:amaze (parallel run).
2. Each agent opens 10 to 15 migrated tickets and verifies history.
3. Test new ticket creation, response, and closure workflows.
4. Confirm SLA policies fire correctly on new (non-imported) tickets.
5. Test one open imported ticket—imported non-closed tickets do not run triggers until a later update.
6. Send a test email to your support address and verify it arrives in Zendesk (not Re:amaze) with correct SPF/DKIM alignment.

For a comprehensive post-migration QA process, see the [Post-Migration QA Checklist](https://clonepartner.com/blog/blog/help-desk-data-migration-qa-checklist/). Use the [Zendesk Migration Checklist](https://clonepartner.com/blog/blog/zendesk-migration-checklist/) as your go-live worksheet.

## Should You Build In-House or Use a Managed Service?

### When In-House Makes Sense

- Fewer than 5,000 conversations with minimal custom fields
- No attachments or all attachments under 50MB
- A developer available for 40+ hours of focused work
- No hard deadline pressure
- Single brand with straightforward channel mapping

### When a Managed Service Adds Value

- 10,000+ conversations with complex threading
- Custom fields using Re:amaze's freeform `data` hash that require type conversion
- Attachments between 50MB and 100MB that need external hosting workarounds
- Multi-brand routing with account-scoped contacts
- Zero-downtime cutover required (needs a delta-sync strategy)
- GDPR compliance requirements that need documented data handling
- Re-migration risk if the first attempt surfaces unanticipated edge cases

The primary risk of in-house migration is not the first attempt—it is the second attempt after the first one surfaces edge cases like broken relationships, recipient truncation, or reversed message order. Re-migration consumes double the API calls, double the engineering time, and often happens under deadline pressure.

## Frequently asked questions

### Can I migrate Re:amaze to Zendesk without losing data?

Yes, with the correct approach. Using Zendesk's Ticket Import API preserves original timestamps and comment ordering. The primary data-loss risk is attachments between 50MB and 100MB, which exceed Zendesk's 50MB per-file limit and must be hosted externally. Workflows, Cues, and live e-commerce sidebar data (Shopify/BigCommerce) do not migrate and must be rebuilt.

### How long does a Re:amaze to Zendesk migration take?

A typical mid-size migration (10,000 to 50,000 conversations) takes 7 to 13 business days. Small instances under 5,000 conversations can complete in 5 to 7 days. Multi-brand instances with 100,000+ conversations and complex attachments may require 2 to 3 weeks.

### What data cannot be migrated from Re:amaze to Zendesk?

Re:amaze Workflows, Cues (proactive messages), Peek (live visitor monitoring), co-browsing sessions, staff permissions, unlisted article visibility, and live e-commerce sidebar data cannot be migrated programmatically. Response Templates must be manually recreated as Zendesk Macros.

### Does the Zendesk Ticket Import API trigger automations or SLA timers?

No. Tickets created via the Import API do not trigger Zendesk Triggers or Automations on initial import. If an imported ticket is later updated, triggers will resume. Zendesk metrics and SLAs are not supported for imported tickets and will produce inaccurate data.

### How much does a Re:amaze to Zendesk migration cost?

Costs vary by approach. A DIY API migration costs 40 to 80+ hours of internal engineering time. Third-party tools like Help Desk Migration charge per-record fees that can exceed $1,000 for large datasets. Managed migration services typically charge a fixed project fee based on volume and complexity.