Zendesk to Pylon Migration Weekend Checklist (2026)

Migrating from Zendesk to Pylon over a weekend means coordinating a historical data import, a live delta sync, Slack channel mapping, and a trigger shutdown — all without spamming customers with stale ticket notifications or dropping a single open conversation.

This is the day-of execution plan for the 48 hours around cutover. It assumes you have already done the architectural planning. For API evaluation, data mapping, and strategic decisions, start with Zendesk to Pylon Migration: The CTO's Technical Guide. For handling automations and macros across platforms, read Your Helpdesk Migration's Secret Saboteur: Automations, Macros, and Workflows.

Three terms appear throughout this runbook:

• Historical sync: the bulk load of tickets, users, organizations, comments, and attachments created before your cutover watermark — everything up to a specific timestamp, moved during the week before the weekend.
• Delta sync: the replay of tickets created or changed after that watermark, run during the weekend window.
• Cutover watermark: the exact timestamp or cursor that separates "already migrated" from "still needs to move."

The weekend is reserved for the delta sync, system validation, and the final routing switch. Not the full data lift.

The 48-Hour Cutover: Why You Cannot Move Everything Over the Weekend

The most common failure mode in a helpdesk migration is assuming you can move all historical data during the cutover window. You cannot.

Zendesk's Incremental Export API is capped at 10 requests per minute (30 with the High Volume API add-on), returning up to 1,000 tickets per page. Ticket comments are not included in the incremental ticket export — you must fetch them separately via the Ticket Comments API, which consumes your general rate limit (200–700 requests per minute depending on plan). (developer.zendesk.com)

In practice, accounting for pagination, comment fetching, user side-loading, and attachment downloads, a standard extraction yields roughly 2,000 tickets per hour. If you have 150,000 historical tickets, extraction alone takes 50–75 hours. A weekend is 48 hours.

To execute a weekend cutover, split the migration into phases:

The historical sync is the longest phase. The delta migration is the most dangerous — conversations get dropped here if your process has gaps. Go-live is where sloppy Slack mapping turns into customer-facing chaos.

Use this timing sequence for the cutover window:

• T-48h: Finish the last dry run of your historical sync. In Pylon, create or confirm the triage channel(s) for Internal Threads and verify ownership routing. For small teams, one shared triage channel works. For larger teams, split by owner or book of business. (docs.usepylon.com)
• T-24h: Freeze your mapping sheet: Zendesk org ID, CRM account, Pylon account, Slack channel, triage destination, owner.
• T-60m: Announce the agent freeze window. After this point, no one edits macros, triggers, fields, or channel links in either system.
• T-15m: Reroute inbound support traffic away from Zendesk and stop agents from sending public replies.
• T-0: Deactivate customer-facing Zendesk notification triggers and start the delta replay from the saved watermark.
• T+30m: Run the Pylon-Slack round-trip tests.
• T+2h: Complete attachment, inline image, and ticket integrity QA.

Pre-Migration: Disabling Zendesk Triggers and Automations

This is the single highest-risk step. Get it wrong, and your migration process fires thousands of email notifications to customers about tickets resolved months ago.

Why triggers fire during migration

Zendesk triggers execute immediately after a ticket is created or updated — including via API. The default trigger "Notify requester and CCs of received request" fires on every ticket creation. If any part of your migration creates or modifies tickets in Zendesk (for example, Pylon's webhook-based seamless migration adds a CC comment to open tickets), each modification triggers outbound email. (support.zendesk.com)

Zendesk's own documentation acknowledges this behavior can "result in an infinite mail loop" between systems. Changes made by automations can also cause triggers to run, creating cascading effects. (support.zendesk.com)

Exactly which triggers to deactivate

Deactivate all notification triggers before the migration window opens:

• Notify requester and CCs of received request — fires on ticket creation (support.zendesk.com)
• Notify requester and CCs of comment update — fires on public comment addition
• Notify assignee of assignment — fires on group/agent assignment
• Notify all agents of received request — fires on unassigned ticket creation
• Notify requester of new proactive ticket — fires if tickets are created on behalf of customers during the freeze
• Any custom rule that sends email, calls a webhook, or posts into a customer-visible system

If a rule can turn a migration-side update into outbound communication, it belongs in the shutdown set.

How to deactivate in bulk

In Admin Center → Objects and rules → Business rules → Triggers → Tickets tab, select multiple triggers using checkboxes and click Deactivate. Deactivated triggers move to the Inactive tab and can be reactivated after migration.

Don't forget automations

Zendesk automations (time-based rules) also send notifications. The automation that closes solved tickets after 28 days and sends a CSAT survey will fire on freshly imported tickets if their timestamps trigger the automation cycle. Deactivate all automations at Admin Center → Objects and rules → Business rules → Automations before the migration window opens.

Screenshot your active triggers and automations before deactivating. You need the exact list to reactivate post-migration.

What to keep running until the freeze starts

• Internal assignee or group notifications that help the team finish the last live tickets.
• Purely internal field-normalization rules that do not add public comments or send outbound mail.
• Any automation your team relies on for the final hour of live support. Once the freeze starts, turn it off — Zendesk automations can cascade into trigger execution. (support.zendesk.com)

Mapping Zendesk Organizations to Pylon Slack Channels

This is where the architectural shift between Zendesk and Pylon hits hardest. Zendesk routes support through email domains and organizations. Pylon routes support through Slack Connect channels and Accounts. If you don't map this correctly, tickets land in the wrong customer context — or in no context at all.

The mapping model

In Zendesk, a customer belongs to an Organization tied to an email domain. Tickets from alice@acme.com route to the "Acme" organization. In Pylon, that customer's conversations happen in a dedicated Slack Connect channel (e.g., #ext-acme) and are tied to a Pylon Account.

Pylon tracks messages across public channels, private channels, and Slack Connect channels. It supports multiple Slack workspaces and expects you to configure Internal Threads plus customer channel links ahead of time. Customer channels can be enabled from the Accounts dashboard, manually with /invite @Pylon, or via autolink naming conventions like ext-. Private customer channels must be enabled directly in Slack. (docs.usepylon.com)

Your migration needs a mapping file that connects:

Zendesk Org ID → CRM Account ID → Pylon Account ID → Slack Channel ID

The minimum mapping sheet:

Do not assume one Zendesk organization equals one Slack channel. Some customers have multiple Slack Connect channels by product line, region, or escalation path. Some should land in a Community Channel, not a dedicated customer channel. Some may still be email-first and should not be cut over to Slack routing this weekend. Pylon treats these channel types differently, so your cutover sheet needs an explicit destination for every org. (docs.usepylon.com)

Edge cases that break mapping

• Customers without a Zendesk organization. These tickets become orphans in Pylon if you don't assign a default Account.
• Shared organizations. Zendesk's shared organization feature (where users in the same org see each other's tickets) has no direct equivalent in Pylon. Document which orgs use this and plan the Pylon access model separately.
• Multi-domain organizations. Zendesk allows multiple email domains per org. Ensure all domains are associated with the correct Pylon Account.
• Slack channels that don't exist yet. If a Zendesk org maps to a customer you haven't onboarded to Slack Connect, create placeholder Accounts in Pylon and backfill the Slack association after go-live.
• Private channels. Pylon can connect private customer channels, but they must be enabled directly in Slack — not from the Pylon dashboard. (docs.usepylon.com)

If you use a naming convention like #ext-acme, turn on Pylon autolinking before the weekend and create a throwaway channel to verify the pattern actually links the account correctly.

Freeze your mapping sheet at T-24h. After that point, no changes to org-to-channel associations.

Handling the Delta Migration: Catching Mid-Flight Tickets

The delta migration is the most technically demanding phase of the weekend. You must capture every ticket created, updated, commented on, or closed while the historical migration was running — and while agents finished their last shifts in Zendesk.

The Incremental Export API

Zendesk's Incremental Export API returns all tickets created or updated since a given timestamp. Use the cursor-based variant:

# Save a watermark at least two minutes in the past to avoid the blind spot
START_TIME=$(date +%s)
START_TIME=$((START_TIME - 120))
 
curl -u $ZENDESK_EMAIL/token:$ZENDESK_TOKEN \
  "https://$SUBDOMAIN.zendesk.com/api/v2/incremental/tickets/cursor.json?start_time=$START_TIME"

Key constraints from the official docs (developer.zendesk.com):

• 10 requests per minute to incremental export endpoints (30 with the High Volume API add-on)
• Up to 1,000 tickets per page with cursor-based pagination
• The API will not return data for the most recent minute to prevent race conditions
• Ticket comments are not included — fetch them separately via the Ticket Comments API, which consumes your general rate limit
• Time-based exports compare start_time to generated_timestamp, not updated_at — a ticket can appear even if its visible updated_at looks older than your watermark
• last_audits sideloads are not supported on incremental endpoints — design for selective follow-up calls, not full re-hydration

The delta sequence

1. Set the watermark two minutes before you begin the first delta pass, not at the exact second of cutover.
2. Persist the cursor from every successful incremental response. If your script crashes, restart from the cursor, not from memory.
3. Upsert tickets by stable source ID so reruns are idempotent.
4. Fetch comment and audit detail only for changed tickets. Incremental exports don't give you audit sideloads, so design for selective follow-up calls.
5. Run a second pass after agent activity stops Saturday evening.
6. Wait two to five minutes and run the final gap pass to cover the most-recent-minute exclusion.
7. Lock the source-to-target ID map before agents start replying from Pylon.
8. Validate counts. Compare total tickets in Zendesk (by status) against Pylon. Any mismatch means the delta missed something.

The closed ticket trap

Zendesk enforces strict status rules. Once a ticket moves to Closed, it is immutable — it cannot be updated, commented on, or reopened via the UI or API.

If a ticket was migrated to Pylon as Solved during the historical sync, and later moved to Closed automatically in Zendesk, your delta script will detect the status change. If your script attempts a bidirectional write-back to Zendesk, the API returns a 422 Unprocessable Entity error.

Your delta logic needs an explicit rule: If Zendesk status == Closed, skip bidirectional write-backs. Map the status to Pylon's equivalent resolved state, but do not push data back into the closed record.

A related gotcha: in Zendesk, a reply to a solved ticket reopens it, while a reply to a closed ticket creates a new follow-up ticket that references the original. If your delta logic filters only to open tickets, you will miss both scenarios. Pylon, by contrast, can reopen a closed Issue when new Slack activity appears. (support.zendesk.com)

Why standard tools fail here

Automated SaaS migration tools like Help Desk Migration restrict delta migration to premium tiers and explicitly state the delta phase cannot be tested separately from the full migration. You discover delta-related data gaps during the live cutover — exactly when you cannot afford surprises. Zendesk's own incremental sample endpoint exists so you can test the export format on smaller responses before the real window. (help-desk-migration.com)

For a deeper playbook on zero-downtime sequencing, see Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move.

Testing the Pylon-Slack Sync Before Go-Live

Pylon's value proposition is Slack-native support. If the bidirectional sync between Pylon and Slack doesn't work on go-live morning, your agents are blind and your customers are talking into a void.

Pylon recommends setting up Internal Threads before connecting customer channels. Once Pylon is active in a customer channel, Slack messages are tracked in Pylon, and Issues can be created from those channels. (docs.usepylon.com)

Run these tests in a sacrificial customer channel before switching DNS or email forwarding:

1. Customer message → Pylon Issue creation

Post a message in a Slack Connect channel mapped to a Pylon Account. Verify a new Issue appears in Pylon within seconds, is assigned to the correct Account, and the message body, author, and timestamp are accurate. Check that attached files render correctly. (docs.usepylon.com)

2. Agent reply → Slack thread response

Reply to the test Issue from within Pylon using Reply. Verify the reply appears in the original Slack thread (not as a new channel message), the agent name displays correctly, and formatting renders in Slack. (docs.usepylon.com)

3. Internal note isolation

Add an internal note in Pylon. Verify that nothing appears in the customer-facing Slack channel. Internal notes leaking into Slack is a trust-destroying bug.

4. Issue lifecycle

Close the Issue in Pylon. Send a new customer message in the same channel. Verify the Issue reopens or creates a follow-up per your configured workflow. (docs.usepylon.com)

5. Emoji-based ticket creation

If you're using Pylon's ticket emoji feature, verify that adding the configured emoji to a Slack thread creates a tracked Issue. Confirm the Pylon bot is present in every relevant customer channel.

6. Email fallback

For customers not on Slack Connect, verify that emails to your support address create Issues in Pylon and that agent replies deliver to the customer's inbox.

7. Private channel test

Repeat the same tests in any private customer channel you rely on. Private channels must be enabled directly in Slack, not from the Pylon dashboard. (docs.usepylon.com)

A channel is not tested because the app installed cleanly. It is tested when you have verified customer message in, agent reply out, internal note isolation, and reopen behavior.

Post-Migration QA: Validating Attachments, Images, and Ticket Integrity

Once the delta is complete and go-live is triggered, run structured validation before declaring success.

Attachment and inline image checks

This is where a migration can look fine in ticket counts and still be broken in practice. Two problems hide here.

Problem 1: Inline images are excluded from the standard attachment list. Zendesk's audit reference documents that comment events do not include inline images in the attachments array by default. When inline=true, the file is excluded from the normal attachment list and referenced only inside the comment HTML. If your migration only counted visible attachments and ignored html_body, you can pass row-count QA while shipping broken screenshots and empty image placeholders into Pylon. (developer.zendesk.com)

Problem 2: Zendesk attachment URLs expire. When you export tickets, the API returns URLs for attachments — not the binary files. These URLs are authenticated and bound by expiring tokens. If your migration script copied Zendesk URLs into Pylon instead of re-hosting the files, images render correctly on Saturday but return 404 errors by Monday.

During QA, open a sample of migrated tickets in Pylon. Right-click inline images and inspect the URL. It must point to Pylon's domain or its storage infrastructure. If the URL still references zendesk.com/attachments/..., the attachment phase needs to be re-run.

Ticket integrity checks

Sample at least these ticket types: one old ticket with file attachments, one with inline screenshots in agent comments, one solved ticket that was later reopened, one closed ticket that received a follow-up reply, one Slack-routed customer with internal threads, and one ticket with interleaved private notes and public replies.

For a complete QA framework, see Post-Migration QA: 20 Tests to Run After Your Helpdesk Migration.

Go-Live: DNS and Email Forwarding

The final step is routing new inbound support traffic to Pylon instead of Zendesk.

1. Update email forwarding. Your support email (e.g., support@yourcompany.com) should now forward to your Pylon support address.
2. Update web forms and help center links that submit to Zendesk's ticket creation endpoint. Point them to Pylon's ticket form or API.
3. Verify MX records if your support email routes through a custom domain. Misconfigured DNS means emails disappear silently.
4. Monitor for 2 hours. Watch both Zendesk and Pylon after go-live. Any ticket that lands in Zendesk after the cutover is a routing leak.

Reactivate Zendesk triggers (if keeping Zendesk temporarily)

If you're running Zendesk in parallel during a transition period, reactivate the notification triggers you deactivated pre-migration. Use the screenshots you took earlier as your checklist: Admin Center → Triggers → Inactive tab, select the triggers, and click Activate.

If Zendesk is being decommissioned immediately, leave triggers off — but keep the account active for at least 30 days so attachment URLs remain accessible while you validate the migration.

What a Clean Weekend Cutover Looks Like

A clean Zendesk-to-Pylon weekend is not the one that moved the most records fastest. It is the one that shut down the right Zendesk behaviors at the right minute, replayed the last moving tickets without gaps, and proved that Slack is the new source of truth before customers noticed the change.

The hard parts — rehearsable deltas, rate-limit math, trigger shutdown sequencing, and org-to-channel mapping — are exactly where generic SaaS tools fall short. Help Desk Migration says its delta phase cannot be tested separately. Zendesk's own migration guidance for complex imports points toward Professional Services or partners.

At ClonePartner, we script the trigger state, persist the delta cursor, test Slack with a real external user, and run one more gap pass than you think you need. We handle the Zendesk API rate-limit math, the attachment re-hosting, and the 3 AM edge cases so your team gets a boring weekend. Boring is the right outcome.