---
title: "How to Merge Two Zendesk Accounts: The Technical Migration Guide"
slug: how-to-merge-two-zendesk-accounts-the-technical-migration-guide
date: 2026-04-21
author: Raaj
categories: [Zendesk]
excerpt: "Zendesk has no native merge button. Learn the three methods to consolidate Zendesk accounts — APIs, tools, managed services — plus what breaks and how to fix it."
tldr: "Merging Zendesk accounts requires API-level migration. Side conversations, macros, inline images, and SLA metrics all need special handling — there is no built-in merge feature."
canonical: https://clonepartner.com/blog/how-to-merge-two-zendesk-accounts-the-technical-migration-guide/
---

# How to Merge Two Zendesk Accounts: The Technical Migration Guide


Zendesk does not offer a native "merge accounts" button. If you have multiple Zendesk Support instances and need to consolidate them into one, you are looking at a data migration project: extracting tickets, users, organizations, and business rules from one or more source accounts and importing them into a single target account using APIs, third-party tools, or a managed service.

This guide covers the technical methods, API constraints, data-loss risks, and preparation steps for a Zendesk-to-Zendesk migration — so you can pick the approach that matches your volume, timeline, and risk tolerance.

If you are consolidating more than just two Zendesk instances, see [How to Migrate Multiple Help Desks Into One](https://clonepartner.com/blog/blog/how-to-migrate-multiple-help-desks-into-one/). For a broader pre-migration planning framework, see the [Zendesk Migration Checklist](https://clonepartner.com/blog/blog/zendesk-migration-checklist/).

> [!NOTE]
> If you only need two live accounts to collaborate temporarily, Zendesk ticket sharing supports cross-account commenting and optional status sync — but it does not consolidate identities, reporting, or workflow configuration. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408893967514?utm_source=openai))

## Why consolidate Zendesk accounts?

Most Zendesk consolidations happen for one of three reasons:

- **Mergers and acquisitions.** Two companies become one, and their support teams need a single view of all customer history. Running parallel instances means fragmented reporting, duplicated workflows, and agents switching between dashboards.
- **Zendesk's Multibrand feature makes separate accounts unnecessary.** Suite Growth and Professional plans support up to 5 brands; Enterprise supports up to 300. Each brand gets its own Help Center, email addresses, and web widgets — all managed from one account. If your separate instances exist only to serve different brands, consolidation into a single multibrand instance eliminates redundant licensing and administration. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408829476378-Setting-up-multiple-brands))
- **Cost reduction and unified reporting.** Every Zendesk instance carries its own per-agent licensing, app subscriptions, and integration maintenance. Zendesk Explore dashboards are scoped to a single instance — separate accounts mean no cross-instance CSAT comparisons, no unified SLA tracking, no combined volume trends.

**Multibrand is not always a drop-in replacement.** Zendesk documents that end users and organizations belong to the account rather than the brand, request visibility can span brands depending on configuration, and the email template is shared across brands. Zendesk-created support addresses cannot be reassigned to another brand without deletion and recreation. If the current split exists because of identity isolation, different auth models, or strict operational boundaries, merging may create new admin and governance work rather than eliminating it. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408829476378-Setting-up-multiple-brands))

## What breaks during a Zendesk-to-Zendesk migration

A Zendesk instance merge rarely fails catastrophically. It fails quietly. Tickets transfer, but the context surrounding them disappears. The data models between two Zendesk accounts are identical in structure, but every record carries instance-specific internal IDs. Ticket IDs, user IDs, organization IDs, custom field IDs, group IDs — none of these transfer. The target instance assigns new IDs on import, which creates a cascade of problems. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_import/))

| Data area | What Zendesk gives you | What still goes wrong |
|---|---|---|
| Tickets, comments, attachments | Ticket Import API supports historical timestamps, comments, and attachments | Metrics and SLAs are not preserved; CC notifications are not sent; open imported tickets participate in triggers after their next update |
| Side conversations | Separate Side Conversations API for reading | Not modeled in Ticket Import — requires a conversion strategy |
| Voice and call recordings | Voice comments support `recording_url` | Zendesk stores the link, not the audio file |
| Inline images | Ticket Comments API can expose them when requested | Must be explicitly fetched, re-uploaded, and rewritten in HTML |
| Users and organizations | CSV tools and APIs exist | Dedupe, external IDs, default-org behavior, and account-level ownership are easy to get wrong |
| Macros, triggers, automations | APIs exist for all three | Order, categories, attachments, field-option tags, and brand scoping need explicit rebuilding |

### Side conversations are not importable

The Zendesk Ticket Import API does not support creating side conversations. You can **read** side conversations from the source account via the [Side Conversations API](https://developer.zendesk.com/api-reference/ticketing/side_conversation/side_conversation/), but there is no way to write them as side conversations in the target. The only workaround is converting each side conversation thread into a private comment on the imported ticket with preserved timestamps and author attribution. Context is preserved, but the threaded structure is lost. Note that side conversations are only available on Suite Professional and higher. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/side_conversation/side_conversation/?utm_source=openai))

### Macros and triggers require explicit transfer

Business rules — macros, triggers, automations, views — do not travel with ticket data. They must be exported separately via the [Macros API](https://developer.zendesk.com/api-reference/ticketing/business-rules/macros/) and [Triggers API](https://developer.zendesk.com/api-reference/ticketing/business-rules/triggers/) and recreated in the target. Any rule that references a specific group ID, custom field ID, or brand ID needs those references remapped to the target's equivalents.

Zendesk evaluates triggers from first to last, so order matters. Brands do not create separate trigger sets — you still have one trigger set with brand conditions layered in. If you move tickets but leave the automations behind, your target instance will not know how to route or escalate the imported data and your automations will silently fail on day one.

For a deep dive on this risk, see [Your Helpdesk Migration's Secret Saboteur: Automations, Macros, and Workflows](https://clonepartner.com/blog/blog/how-to-migrate-automations-macros-workflows/).

### Inline images need re-hosting

Inline images in ticket comments reference URLs on the source instance's CDN. After migration, those URLs still point to the old account. If the source account is decommissioned, every inline image breaks.

Zendesk's Ticket Comments API does not list inline images as attachments by default — you must request them with `include_inline_images=true`. Attachments must be downloaded from the source, uploaded to the target via the [Attachments API](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket-attachments/), and their upload tokens embedded in the imported comment's payload. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_comments/?utm_source=openai))

### SLA metrics and Explore reports do not migrate

Zendesk explicitly states that metrics and SLAs are not supported for imported tickets. Running SLAs on imported tickets produces incomplete, inaccurate data. The recommended approach is tagging imported tickets (e.g., `imported_from_source`) and excluding them from active SLA policies and reports. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_import/))

### Merged and linked ticket references break

You cannot reserve ticket IDs in Zendesk. When two tickets in the source reference each other — a ticket merged into another, or a follow-up linked to a parent — you cannot guarantee their new IDs in the target until both are created. Cross-references need a second pass: import all tickets, build an old-ID → new-ID lookup table, then update references as tags or custom field values.

### Suspended users and empty comments block the import

The Ticket Import API requires that the `requester_id` and any `author_id` on comments reference **active** users. If a user has been suspended in the source (e.g., a former employee), you must either unsuspend them temporarily, create a placeholder user, or remap those tickets to a generic "Former Employee" user.

> [!WARNING]
> **Edge case:** The Ticket Import API also rejects comments with empty bodies. Tickets where a customer sent only an attachment with no text will fail unless you inject a placeholder body like `[Attachment only — no message body]`.

## Method 1: DIY migration using Zendesk APIs

This is the most flexible approach and the most engineering-intensive. You coordinate two sets of APIs: the Incremental Export APIs to extract data from the source, and the Ticket Import API plus Create/Update APIs to write data into the target.

### The export side

Zendesk's [Incremental Export API](https://developer.zendesk.com/api-reference/ticketing/ticket-management/incremental_exports/) returns records that changed since a given timestamp. Cursor-based pagination is preferred — it eliminates duplicates and returns up to 1,000 items per page.

**Rate limits on the Incremental Export API:**

| Resource | Default limit | With High Volume API add-on |
|---|---|---|
| Tickets (cursor) | 10 requests/min | 30 requests/min |
| Users (cursor) | 20 requests/min | 60 requests/min |
| Organizations (time-based) | 10 requests/min | 10 requests/min |

At 1,000 tickets per page and 10 requests per minute, you can export roughly 10,000 tickets per minute in the best case. For a 500,000-ticket account, the ticket metadata export alone takes close to an hour — before you fetch comments, attachments, or side conversation data.

The incremental export gives you ticket metadata, but not ticket comments. To get the actual conversation history, your script must iterate through every ticket and call the Ticket Comments API (`GET /api/v2/tickets/{ticket_id}/comments`). This hits your global rate limit. For an instance with 100,000 tickets, extracting comments and downloading attachments can take days of continuous, carefully throttled API calls.

For a complete walkthrough of export options, see [How to Export Tickets from Zendesk](https://clonepartner.com/blog/blog/how-to-export-tickets-from-zendesk/).

### The import side

The [Ticket Import API](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_import/) (`POST /api/v2/imports/tickets/create_many`) is purpose-built for migrations. It lets you:

- Set historical `created_at`, `updated_at`, and `solved_at` timestamps on imported tickets and their comments.
- Bypass active triggers and automations. (Triggers do not fire on import, but they resume if the ticket is subsequently updated.)
- Suppress email notifications so customers do not receive a flood of "Ticket Created" emails.
- Send closed tickets directly to the archive with `archive_immediately: true` — Zendesk recommends this for imports exceeding 750,000 tickets to avoid performance impact on active tickets. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_import/))

Key constraints:

- **Users must exist before tickets reference them.** Import organizations first, then users (via the [Create Many Users](https://developer.zendesk.com/api-reference/ticketing/users/users/#create-many-users) endpoint — up to 100 per request), then tickets.
- **Attachments require a two-step process:** upload the file first to get an upload token, then include the token in the comment payload.
- **The import accepts up to 100 tickets per request** and returns a background `job_status` object. Job-based endpoints are capped at 30 queued or running jobs.

```python
# Simplified import flow (pseudocode)

# 1. Export and create organizations
for org in source_orgs:
    target_api.create_organization(org)

# 2. Export and create users (batches of 100)
for batch in chunk(source_users, 100):
    target_api.create_many_users(batch)

# 3. Build user ID mapping: source_user_id → target_user_id
id_map = build_user_id_map(source_users, target_users)

# 4. For each ticket: remap IDs, upload attachments, import
for ticket in source_tickets:
    ticket['requester_id'] = id_map[ticket['requester_id']]
    ticket['assignee_id'] = id_map.get(ticket['assignee_id'])
    for comment in ticket['comments']:
        comment['author_id'] = id_map[comment['author_id']]
        for attachment in comment['attachments']:
            token = target_api.upload(attachment)
            comment['uploads'] = [token]
    target_api.import_ticket(ticket)
```

> [!NOTE]
> **API rate limits:** Zendesk's Support API limits range from 200 to 700 requests per minute depending on plan tier, or 2,500 with the High Volume API add-on. The Incremental Export endpoints have their own separate, stricter limits on top of these. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/introduction/rate-limits/))

> [!WARNING]
> **Rate limit trap:** If your payloads include large attachments or extensive comment histories, Zendesk may return 429 (Too Many Requests) errors or timeout failures. Your script must include robust exponential backoff and retry logic.

### Engineering cost

A DIY migration for a moderately complex account (100K+ tickets, custom fields, side conversations, multiple brands) typically takes a senior engineer 2–4 weeks to build, test, and execute — including edge-case handling, ID remapping, and attachment re-hosting. That is before you account for a delta migration to catch tickets created during the migration window. DIY is usually the cheapest vendor line item and the most expensive internal attention sink.

## Method 2: Zendesk Professional Services

Zendesk offers professional services positioned as **Suite transition** work, not a lightweight account-merge utility. The official data sheet lists Starter at **$8,000** for launching up to one channel, Pro at **$15,000** for up to two channels, and Premium at **$25,000** for up to three channels. Premium includes data migration services, custom applications or integrations, live training, theme work, and additional customizations. ([web-assets.zendesk.com](https://web-assets.zendesk.com/pdf/suite-transition-services.pdf))

**When this makes sense:**

- You are restructuring your entire Zendesk configuration (new groups, brands, routing logic) alongside the data move.
- You need Zendesk's direct involvement for compliance or contractual reasons.
- You have budget but no internal engineering capacity.

**When it does not:**

- Your primary need is moving historical ticket data. Professional services teams are optimized for implementation and configuration — not necessarily high-fidelity data migration with edge-case handling.
- You need granular control over what gets migrated and how (e.g., converting side conversations, remapping custom fields, splitting merged tickets).

## Method 3: Self-serve migration tools vs. managed migration services

Self-serve SaaS tools (like Help Desk Migration) provide a wizard-based interface that connects to both Zendesk instances and transfers data automatically. You map fields, run a demo migration with a small sample, and execute the full transfer. ([help-desk-migration.com](https://help-desk-migration.com/pricing/))

**Advantages:**

- Fast setup — connect accounts, map fields, run.
- Per-record pricing (approximately $100 for 1,000 records, scaling up with volume).
- Good for straightforward consolidations with standard fields.

**Limitations:**

- Inline images are frequently stripped or broken — most tools import the HTML body but do not re-host embedded images.
- Large attachments (15–20 MB+) may be silently skipped.
- Custom field mapping is limited to what the tool's UI exposes.
- Rate limit handling is opaque — you cannot control retry logic or concurrency.
- Edge cases like side conversations, call recordings, and merged ticket references often require manual workarounds or are dropped entirely.

**Managed migration services** (like ClonePartner) take full engineering ownership. We build custom scripts specific to your account's data model, handle edge cases programmatically, and run a delta sync to capture changes made during the migration window — so your team never has to stop working.

The key difference: with a self-serve tool, your team owns mapping accuracy, troubleshooting failures, and validating results. With a managed service, the engineering team owns the outcome.

### Method comparison

| Factor | DIY API Scripts | Self-Serve Tool | Zendesk Pro Services | Managed Service (ClonePartner) |
|---|---|---|---|---|
| **Best for** | Engineers with time | Simple, small moves | Full Zendesk reconfigs | Complex consolidations |
| **Ticket volume** | Any (with patience) | <200K practical | Varies | Any |
| **Side conversations** | Manual conversion | Often dropped | Case-by-case | Converted to notes |
| **Macros/triggers** | Manual rebuild | Partial mapping | Included in config | Full remapping |
| **Inline images** | Must re-host manually | Often broken | Case-by-case | Re-hosted automatically |
| **Downtime risk** | High (without delta sync) | Moderate | Low–moderate | Zero |
| **Timeline** | 2–6 weeks | Days | Weeks–months | Days |
| **Engineering effort** | High | Low | Low (but slow) | None for your team |

## Step by step: how to merge two Zendesk accounts

### 1. Decide whether multibrand can replace multiple accounts

If branding is the only reason for the split, solve the architecture first. Confirm the target plan supports the number of brands you need, confirm side-conversation availability if you rely on it, and verify that account-level users, shared email templates, and support-address rules are acceptable. If you use host-mapped help centers, Zendesk requires SSL certificate regeneration when you add host-mapped brands. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408829476378-Setting-up-multiple-brands))

### 2. Pick the surviving instance and freeze admin changes

Choose the target account early and declare a config freeze. From that point on, ticket fields, forms, macros, triggers, support addresses, and Guide structure should only change through the migration plan. Zendesk warns that dropdown-option updates can remove omitted options and strip their values from tickets or macros. A moving config target is how "correct mapping" becomes "wrong by go-live." ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_fields/?utm_source=openai))

### 3. Audit and inventory the source instance

Do a full inventory before moving a single ticket:

- **Custom fields:** Export all custom ticket fields, user fields, and organization fields. Note field types (dropdown, text, checkbox, regex) and all dropdown option values. The target instance must have matching fields before import.
- **Business rules:** Document every trigger, automation, macro, and view. Note which are active vs. inactive. Record any rule that references a specific group, brand, or custom field by ID.
- **Agents and groups:** List all agents, their groups, roles, and brand memberships. Agents must exist in the target before tickets can be assigned to them.
- **Apps and integrations:** Catalog every installed app and third-party integration (Slack, Jira, Salesforce, etc.). Each must be reinstalled and configured in the target.

### 4. Clean and deduplicate before migration

- **Deduplicate users.** Search for duplicate email addresses across both instances. Decide which record is authoritative and merge or archive the rest. Zendesk limits duplicate-account merges to end users with 10,000 tickets or fewer in each account, merges cannot be undone, and users with external IDs must be cleaned up first. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408893496218-Bulk-importing-user-data-with-the-data-importer?utm_source=openai))
- **Purge dead data.** Delete spam tickets, test tickets, inactive agents, outdated macros, and suspended accounts you do not need. Every record you skip is time and cost saved.
- **Standardize tags and field values.** If the source uses `priority:high` and the target uses `priority_high`, normalize before migration — not after.

### 5. Prepare the target instance

- Create all custom fields, groups, brands, and ticket forms before running any import.
- Create agent accounts with the correct roles and group memberships.
- Disable triggers and automations in the target during import to prevent unintended side effects (e.g., welcome emails, auto-replies).
- Add an `imported_legacy` tag and configure high-risk triggers to ignore it until cutover is complete — because open imported tickets will join normal trigger processing after later updates. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/business-rules/triggers/))

> [!CAUTION]
> Do not finalize ticket-field mappings after ticket import has started. Zendesk warns that omitting existing dropdown options in an update removes those options and can strip their values from tickets or macros. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_fields/?utm_source=openai))

### 6. Define handling for side conversations, call recordings, and inline images

Do not leave these as "we'll sort it out later." Decide up front:

- Whether side conversations stay in the source, become private notes, or are rebuilt in a target plan that supports them.
- Whether voice recording URLs remain valid long-term or whether you need to fetch and reattach the underlying audio files.
- Whether your extraction logic explicitly fetches inline images (with `include_inline_images=true`) and rewrites them as uploaded attachments.

### 7. Run a sample migration with ugly tickets, not easy ones

Your sample set should include old closed tickets, voice comments, image-heavy threads, duplicate users, tickets with custom statuses, tickets with side conversations, and anything brand-routed in a nontrivial way. Run the sample, compare source vs. target record by record, then fix the mapping. Easy tickets tell you nothing.

### 8. Import data in the correct order

Execute the migration in sequence:

1. Import organizations first. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408885980186-Bulk-importing-organizations))
2. Import users (up to 100 per API request), building a source-ID → target-ID mapping table. Bulk user import can associate a user with multiple organizations, but the default organization is set alphabetically during bulk import — not chosen manually. If identity mapping is complex, see [How to Migrate Users & Organizations Without Breaking History](https://clonepartner.com/blog/blog/migrate-users-organizations/).
3. Import tickets with remapped user IDs, re-hosted attachments, and converted side conversations using the Ticket Import API.
4. Run a second pass for cross-references: merged ticket links, follow-up references, and any other inter-ticket relationships that depend on knowing the new ticket IDs.

### 9. Run delta sync, validate, and cut over

After the initial bulk migration, run incremental exports to capture every ticket created or updated in the source since the migration started. Keep the delta loop running until the cutover window. ([developer.zendesk.com](https://developer.zendesk.com/documentation/api-basics/working-with-data/using-the-incremental-export-api/))

Before decommissioning the source:

- Compare ticket counts, comment counts, and attachment integrity between source and target.
- Open attachments and inline images to verify they render correctly.
- Verify requester, assignee, and organization relationships.
- Test brand routing, support-address behavior, macro output, and trigger order.
- Confirm imported legacy tickets are excluded from live SLA and reporting logic.

Switch agents to the target instance. Re-enable triggers and automations. Keep the source instance read-only for a defined period before decommissioning.

For more on the delta-sync approach, see [Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move](https://clonepartner.com/blog/blog/zero-downtime-helpdesk-migration/).

> [!TIP]
> If most of the source history is old and closed, use Zendesk's `archive_immediately` option on the Ticket Import API for the historical tranche. Zendesk calls it out specifically for very large imports (750,000+ tickets) to avoid inflating the active ticket set. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_import/))

## How ClonePartner merges Zendesk instances

We have handled Zendesk-to-Zendesk consolidations ranging from 50K to over 1M tickets. Here is what we do:

- **Side conversations → private notes.** We read every side conversation thread from the source, preserve the full message history with timestamps and author attribution, and write them as structured private comments on the imported ticket.
- **Call recordings → attachments.** Talk recordings are downloaded and attached to the corresponding ticket comment in the target.
- **Business rule migration.** We export macros, triggers, and automations from the source, remap all internal ID references (groups, fields, brands) to the target's equivalents, and recreate them with original actions, conditions, categories, and trigger order intact.
- **Continuous delta sync.** Our migration scripts run incremental exports on a schedule, capturing every ticket created or updated after the initial bulk migration. Your agents keep working in the source instance until the moment of cutover. Zero downtime.
- **Full validation.** We compare ticket counts, comment counts, and attachment checksums between source and target. If something does not match, we fix it before cutover — not after.

The difference between a managed service and a self-serve tool is accountability. We do not hand you a mapping wizard and wish you luck. We assign a dedicated engineer to own the outcome.

## What to do next

Pick the method that matches the mess, not just the budget. DIY works for clean accounts with engineering time. Zendesk Professional Services makes sense when the merge is part of a larger Suite rollout. Self-serve tools are effective for standard schemas and teams that can validate their own mappings. If you need one team to own identity mapping, business-rule rebuilds, and the delta-sync cutover, bring that team in early.

Start with the step-by-step checklist above. Document your source instances, identify your edge cases, and decide which approach fits your timeline and risk tolerance.

> Planning a Zendesk instance consolidation? Tell us about your instances and we'll scope the project in a 30-minute call — including edge cases, timeline, and a guaranteed migration plan.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Can I merge two Zendesk accounts natively?

There is no native merge feature in Zendesk. You must migrate data from one instance to the other using the Zendesk APIs (Incremental Export + Ticket Import), a self-serve migration tool, or a managed migration service. Every ticket, user, and organization must be extracted, remapped, and re-imported.

### What data is lost when merging Zendesk instances?

Side conversations cannot be imported as side conversations — they must be converted to private notes. SLA metrics and Explore reports do not transfer. Inline images break if not re-hosted. Merged ticket cross-references lose their links since new ticket IDs are assigned. Macros, triggers, and automations require explicit recreation with remapped internal IDs.

### Do imported Zendesk tickets keep SLA and reporting history?

No. Zendesk explicitly states that metrics and SLAs are not supported for imported tickets. Imported history should be tagged (e.g., imported_from_source) and excluded from active SLA policies and live reporting.

### Does the Zendesk Ticket Import API fire triggers on imported tickets?

No. Triggers do not run on tickets imported via the /api/v2/imports/tickets endpoint. However, if an imported ticket is updated after the import, triggers will resume firing. Tag imported tickets and exclude them from live automations until cutover is complete.

### How long does a Zendesk-to-Zendesk migration take?

A self-serve tool can complete a simple migration in 1–3 days. A DIY API approach takes 2–6 weeks of engineering work including testing. A managed service like ClonePartner typically completes even complex consolidations in days, with zero downtime via continuous delta sync.