Migrating from Freshdesk: what changes, what breaks, what to do first

Migrating off Freshdesk is mostly a data-export and email-routing exercise, not a rebuild. Export your tickets, contacts, tags and macros; stand up DKIM so replies sign as your own domain; forward a copy of inbound mail to the new tool and run both side by side for a day or two; then flip your MX or forwarding once threading and deliverability check out. The single step that decides whether day one is smooth is email authentication, so do that first.

Do this first: email

Sort out deliverability before you flip anything. Publish your DKIM key and a custom return-path so replies are signed as your domain from message one. This is the step that decides whether day one is smooth — get it wrong and the first morning is a wave of "why is support landing in spam" tickets.

Cherryrise uses BYODKIM: you bring your own DKIM key and send through your own AWS SES, so outbound mail is signed as your domain rather than a shared vendor sender. That matters more on a migration than at any other time, because your reply addresses and sending infrastructure are changing at once. If you're new to the mechanics, the DKIM explainer and the SPF/DKIM/DMARC difference are worth ten minutes before you touch DNS.

Export your Freshdesk data

Freshdesk gives you a few ways to get data out, and you'll usually want more than one:

• Ticket and contact exports — Freshdesk admins can export tickets and contacts to CSV from the admin area. CSV is fine for contacts and metadata, but it flattens conversations.
• The API — for full conversation history (every reply and private note with timestamps and authors), the Freshdesk REST API is the reliable path. Page through tickets and pull each conversation thread rather than trusting a flat export.
• Attachments — pull these deliberately; they're often referenced by URL and can expire when the old account closes.

Keep the original Freshdesk account live and read-only during the move. You want to be able to re-pull and re-import as many times as it takes while you verify the result.

Import via email, not magic

There's no one-click "suck Freshdesk into Cherryrise" button, and you should be suspicious of any tool that claims one. Realistically you have two import paths, and most teams use both:

• Live mail via IMAP / forwarding — point a forwarding rule (or an IMAP connection on your support mailbox) at Cherryrise so new conversations land in the shared inbox immediately. This is what actually carries your day-to-day traffic during cutover.
• Historical tickets via import — load the exported tickets and contacts as a snapshot so agents have searchable history. Treat this as reference data, not live threads.

The pragmatic split: forwarding/IMAP handles everything from cutover forward; the historical import gives you the back-catalog for context and search. Don't block go-live on a perfect history import — get live mail flowing first.

What changes conceptually

Most concepts map cleanly: tickets, contacts, tags, macros and saved views all have equivalents. A few things shift:

• Macros become canned replies and rules — Freshdesk macros and dispatcher rules map to Cherryrise canned responses plus automation you can test before shipping.
• Agents and roles — re-create your team with RBAC, and decide who's full-access versus an assigned-only agent who sees only their own tickets.
• SLAs — re-map your SLA tiers deliberately rather than importing them blindly; see how to set SLAs.
• Pricing model — Cherryrise is per-agent, with no per-resolution or deflection fees, so you don't have to police agent counts the way some plans push you to.

What tends to break

Two things break most often:

• Threading on forwarded chains. When you forward old mail or import history, replies and CC'd messages can land as orphaned tickets instead of one conversation. Verify a few old threads read as a single conversation before you trust the import.
• SLA clocks that ignored business hours. If your Freshdesk SLAs ran on calendar time, recreate them against your actual support hours — otherwise first response time targets will look wrong the moment you cut over.

DNS and DKIM cutover

The DNS work is small but unforgiving — get the records right and stage them before go-live:

• DKIM — publish the CNAME/TXT records for your signing key so the new sender's signature validates against your domain.
• SPF — make sure your SPF record authorizes the new sending path (SES) so receivers don't soft-fail. SPF is a single record; don't create a second one.
• Return-Path — set a custom return-path on your own subdomain so bounces and alignment work in your favor.
• DMARC — if you publish DMARC, confirm DKIM or SPF aligns with the visible From domain before tightening the policy.

Lower DNS TTLs a day ahead so changes propagate fast, and verify with a test send from the new tool before any customer mail flows through it. The why replies go to spam post covers the failure modes.

Help center and redirects

If you publish a Freshdesk knowledge base or portal, plan the URL move so you don't lose existing links and search ranking:

• Export your articles and re-publish them in the Cherryrise white-label help center.
• Put 301 redirects from old Freshdesk article URLs to the new ones wherever you control the domain.
• If your old portal lived on a Freshdesk subdomain you don't keep, prioritize redirecting the handful of articles that actually get traffic and external links.

The Cherryrise portal is passwordless via magic link, so you're not asking customers to migrate accounts — they just click a link to see their tickets.

Run in parallel, then flip

Forward a copy of new mail to Cherryrise while Freshdesk still receives it. Agents work in the new tool; Freshdesk stays read-only as a safety net. After 48 clean hours — threading holding, replies authenticating, SLAs counting correctly — flip forwarding (or your MX) fully and set the old account read-only. Running both at once for a couple of days is cheap insurance against a one-way cutover that goes wrong at 9am.

The full checklist

• Export tickets, contacts, tags and macros (CSV for metadata, API for full conversations).
• Stage DKIM, SPF, return-path and DMARC alignment; lower DNS TTLs ahead of time.
• Re-create agents, roles and SLA tiers against real business hours.
• Rebuild macros as canned replies and automation; recreate your saved views.
• Connect live mail via forwarding/IMAP and import historical tickets as reference.
• Verify threading on sample old conversations and run a test send.
• Migrate help-center articles and add 301 redirects.
• Run both tools in parallel 48 hours, then flip forwarding and archive Freshdesk read-only.

The same sequence works for Zendesk, and if you're weighing the broader trade-offs, the middle-ground comparison and the vs Freshdesk page lay them out.

Frequently asked questions

Can I import my full Freshdesk ticket history?

Yes, but plan for it as a separate, lower-priority track. CSV exports cover contacts and metadata; for complete conversation history with every reply and note, pull from the Freshdesk API and import that as searchable reference data. Get live mail flowing via forwarding first, then backfill history.

Will moving help desks hurt my email deliverability?

Only if you skip authentication. Because your sending infrastructure changes during a migration, publish DKIM, fix SPF, set a custom return-path and confirm DMARC alignment before any customer mail routes through the new tool. With BYODKIM you send signed as your own domain through your own SES, which is the safest path.

How do I avoid downtime during cutover?

Run both systems in parallel. Forward a copy of inbound mail to Cherryrise while Freshdesk keeps receiving, let agents work in the new tool, and only flip forwarding or MX after 48 clean hours. The old account stays read-only as a fallback.

What happens to my Freshdesk help-center URLs?

Re-publish the articles in the Cherryrise help center and add 301 redirects from the old Freshdesk URLs wherever you control the domain. Prioritize the articles with real traffic and external links so you don't lose search ranking.