The Go-Live Day Checklist: 15 Things to Do for a Smooth Help Desk Data Migration

Helpdesk migration is a monumental task. You've spent weeks, maybe even months, planning, preparing data, and configuring your new system. Now, the moment of truth has arrived: go-live day. This is the critical point where your new helpdesk becomes the primary system of record. A smooth cutover is not just a technical goal; it's a business necessity, impacting everything from customer satisfaction to agent productivity. A single misstep can lead to data loss, extended downtime, and chaos for your support team.

So, how do you ensure your helpdesk cutover is a seamless transition rather than a frantic scramble? The key is a meticulous, step-by-step checklist.

This checklist is built from direct experience running helpdesk migrations across Zendesk, Freshdesk, Intercom, and Jira Service Management. It covers the three phases of a cutover — pre-cutover, the cutover window itself, and the hypercare period — and flags the non-obvious failure modes at each step.

This isn't just a list of tasks; it's a strategic framework designed to help you avoid last-minute mistakes and navigate the complexities of go-live day with confidence.

Phase 1: The Final Countdown (24-48 Hours Before Go-Live)

The work you do in the days leading up to the cutover is just as important as the day itself. This phase is all about final confirmations and locking things down.

1. Announce a System-Wide Code and Configuration Freeze

Why it's critical: The last thing you need is an unexpected change to either the source or target system throwing a wrench in your plans. A developer pushing a minor update or an admin tweaking a workflow can have unforeseen consequences on the migration logic.

What to do:

• Communicate Clearly: Announce a hard freeze on all changes to both the old and new helpdesk platforms at least 48 hours before the go-live. This includes code deployments, app installations, workflow adjustments, and changes to user permissions.
• Enforce the Freeze: If possible, temporarily revoke admin or developer access in both systems to prevent accidental changes.
• Confirm with All Teams: Ensure that your IT, development, and support leadership teams are all aware of and have signed off on the freeze.

Blocking dependency: Steps 6 (delta migration) and 9 (automation re-enablement) both depend on this freeze being in place. A config change after the freeze window invalidates your delta baseline.

Estimated time: 15–30 minutes to communicate and enforce; 48-hour hold.

2. Is Your Final Go/No-Go Meeting Scheduled?

Why it's critical: This is your final checkpoint. It's the last opportunity for any stakeholder, from project managers to support team leads, to raise red flags or voice concerns before you pass the point of no return.

What to do:

• Gather Key Players: Invite project sponsors, IT leads, support managers, and the migration team.
• Review Readiness: Go through a final readiness checklist. Has all testing been completed? Are all resources (personnel) confirmed for go-live day? Is the communication plan ready?
• Make the Call: Secure a unanimous "Go" from all stakeholders. If there are any "No-Go" concerns, you must have a clear plan to resolve them before proceeding. Do not move forward with lingering doubts.

Rollback trigger: If any stakeholder cannot confirm that pre-migration QA passed — meaning record counts matched and a sample of tickets was manually verified — treat it as a No-Go.

Estimated time: 30–60 minutes.

3. Have You Performed a Final, Full Backup of Your Source Help Desk?

Why it's critical: This is your ultimate safety net. While the goal is a perfect migration, you must be prepared for a worst-case scenario. This final backup ensures you can restore your old system and roll back the entire process if a catastrophic failure occurs.

What to do:

• Initiate a Full Backup: Perform a complete backup of your entire source helpdesk database and all associated file attachments.
• Verify the Backup: Don't just run the backup; verify it. Attempt a partial restore to a separate, isolated environment to confirm the backup file is not corrupted and is fully usable. A backup that has never been tested is not a backup — it's a theory.
• Securely Store It: Store this backup in a secure, isolated location, separate from your production environment.

What to verify specifically: After the partial restore, confirm that: (a) ticket counts in the restored environment match the source within 0.1%, (b) at least one attachment opens without corruption, and (c) the most recent ticket timestamp matches what you expect. If any of these fail, do not proceed.

Estimated time: 1–4 hours depending on data volume; verification adds another 30–60 minutes.

4. Is Your Support Team Trained and Ready for the New System?

Why it's critical: Your new helpdesk can be the most powerful tool in the world, but it's useless if your team doesn't know how to use it. A lack of training leads to frustration, slow response times, and a dip in customer satisfaction right after launch.

What to do:

• Final Q&A Session: Hold one last office hours or Q&A session for the support team. Address any lingering questions about new workflows, ticket statuses, or UI navigation.
• Distribute Quick-Reference Guides: Have one-page cheat sheets or digital guides ready that cover the most common tasks in the new system.
• Confirm Login Access: Have every single agent log into the new system at least once before go-live to ensure their credentials and permissions are working correctly. True readiness comes from confirming your team is fully trained and ready.

Phase 2: The Cutover Window (Go-Live Day)

This is it. The migration is in motion. Precision and communication are paramount during this phase. The goal here is to execute your plan and achieve a smooth, zero-downtime cutover. These steps are non-negotiable.

5. Is Your Old Help Desk Placed in Read-Only Mode?

Why it's critical: You need to stop the flow of new data into the source system to prevent data loss. Once the final data migration begins, any new tickets or updates created in the old system will be left behind.

What to do:

• Disable Incoming Channels: Turn off email forwarding, close API endpoints, and disable customer portal access.
• Change User Permissions: If possible, change all user roles (including admins) to a "read-only" permission level to prevent manual edits.
• Post a Banner: Add a prominent banner in the old system's UI informing users that it is now read-only and directing them to the new platform.

Platform note: Zendesk does not have a native "read-only" mode for agents. You will need to manually remove ticket creation permissions from all non-admin roles, or use a trigger to immediately close any ticket created after the freeze timestamp. Freshdesk has a similar limitation — the cleanest approach is to disable the support email channel and suspend the customer portal before the delta run begins.

Blocking dependency: This step must be fully confirmed before Step 6 begins. Starting the delta migration while agents can still create tickets in the old system guarantees data gaps.

Estimated time: 15–30 minutes.

6. Are You Ready to Execute the Final "Delta" Data Migration for the Cutover?

Why it's critical: Since your last full data sync during the testing phase, new tickets and updates have been created. The delta migration moves only the data that has been created or changed since the last sync, ensuring the new system is up-to-date at the moment of cutover.

What a delta migration actually means technically: a delta sync queries the source system for all records with an updated_at or created_at timestamp after your last full sync cutoff. The script then upserts those records into the target — inserting new ones and overwriting changed ones — using a stable record identifier (usually the source ticket ID mapped to the target's external ID field) to avoid duplicates.

What makes delta migrations fail:

• Timestamp drift: If the source and target systems are in different timezones and your script doesn't normalize to UTC, you will miss or double-import records at the boundary.
• Missing external ID mapping: If your target system doesn't store the source ticket ID, your upsert logic has no reliable deduplication key and will create duplicate tickets.
• Attachment re-upload failures: Attachments are not covered by timestamp filtering — they reference URLs that may have already expired. Plan to re-fetch and re-upload attachments separately during the delta run.
• Custom field type mismatches: A field that is a free-text string in Zendesk may be mapped to a dropdown in Freshdesk. If the value doesn't match an existing option, the write will fail silently on some platforms.

What to do:

• Run the Delta Script: Initiate the migration script or tool configured to sync only the changes.
• Monitor Progress: Keep a close eye on the migration logs. Watch for any errors or slowdowns. Your technical team should be on high alert, ready to troubleshoot immediately.

Rollback trigger: If the delta run logs more than 1% record write failures, or if it completes but the target ticket count is more than 2% below what you expect based on source counts, pause and investigate before proceeding to DNS cutover.

Estimated time: 15 minutes to 2 hours depending on delta volume since last full sync.

7. How To Perform Post-Migration QA and Data Validation?

Why it's critical: Never assume the data moved perfectly. You must verify it. This step confirms that the data in the new system matches the data from the old system, both in quantity and quality. The go-live can only happen after all post-migration QA tests have passed.

What to do:

• Run Automated Record Count Checks: Compare ticket counts, contact counts, and organization counts between source and target. A count mismatch of more than 0.5% is a blocking issue. A mismatch above 2% should trigger a full rollback review.
• Conduct Manual Audits: Have a dedicated QA team open a predetermined list of tickets in both systems. They should verify that all fields, attachments, and timestamps match.
• Test Key Records: Check a few of your most complex or important customer tickets to ensure custom fields and intricate conversation histories have been preserved.

Data types that fail at the highest rate:

• Attachments are the most common failure point. They depend on the source system's file storage being accessible during migration, and individual file size limits differ by platform (Zendesk allows up to 50MB per attachment; Freshdesk caps at 20MB in most plans). Any attachment that exceeds the target's limit will fail silently unless your logs explicitly surface it.
• Custom fields fail when field types don't map cleanly. Boolean fields, multi-select dropdowns, and date fields are the most error-prone.
• Conversation threads can lose ordering if the source system doesn't expose a reliable per-comment timestamp and the target system's import API doesn't honor sort order.
• SLA timer data is almost never portable between platforms. Expect SLA state to reset on all open tickets after migration.

Validation vs. QA distinction: Automated record count checks are validation — they confirm completeness. Manual ticket audits are QA — they confirm correctness. Both are required. Passing one does not substitute for the other.

Estimated time: 30–90 minutes depending on dataset size and QA team size.

8. Re-Point Your DNS and Incoming Support Channels

Why it's critical: This is the official "flip the switch" moment. This is when you direct all your customers and incoming requests to the new helpdesk.

What to do:

• Update Your CNAME/MX Records: Change your DNS records (e.g., support.yourcompany.com) to point to the new helpdesk provider's servers.
• Redirect Email Forwarding: Update your support email address (e.g., support@yourcompany.com) to forward messages to the new system's intake address.
• Update Website Widgets: Update any "Contact Us" forms, chat widgets, or help center links on your website to point to the new platform.

DNS propagation caveat: TTL values on your DNS records determine how long cached records persist. If your TTL is set to 3600 (1 hour) or higher, some customers and mail servers will continue routing to the old system for up to that duration after you make the change. Lower your TTL to 300 seconds (5 minutes) at least 24 hours before go-live so the change takes effect quickly when you flip it. Confirm propagation using a tool like dnschecker.org before declaring the cutover complete.

Estimated time: 5–10 minutes to make the changes; allow up to 1 hour for full propagation if TTL was pre-lowered.

9. Enable Notifications and Automations in the New System

Why it's critical: Your helpdesk relies on automations to function efficiently. These were likely disabled during migration to prevent a flood of notifications. Now it's time to turn them back on.

What to do:

• Activate Workflows in the correct order: Turn on automations in a specific sequence to avoid trigger loops. Enable ticket routing rules first, then SLA policies, then auto-reply and customer notification triggers last. If you enable customer-facing notifications before routing rules are active, tickets may fire a "ticket received" email before being assigned to the correct queue — causing a second notification on assignment.
• Enable Customer Notifications: Re-enable email notifications to customers for ticket creation, updates, and resolutions.
• Test a Live Ticket: Create a test ticket through a public channel (like your support email) to ensure it's routed correctly and that all expected notifications are sent.

Automation re-enablement risk: On platforms like Zendesk, a trigger that fires "on ticket update" can create a loop if another automation also updates the ticket in response. Before enabling automations on migrated data, audit your trigger conditions to confirm none of them fire retroactively on tickets with old timestamps. Freshdesk's automation engine evaluates rules at the moment of the next update — so a bulk import that marks thousands of tickets as "updated" can cause a cascade of automation firings immediately after re-enablement.

Estimated time: 30–60 minutes including testing.

10. Re-Establish Integrations with Third-Party Apps

Why it's critical: Your helpdesk doesn't operate in a vacuum. It connects to your CRM, bug tracker, communication tools, and more. These integrations need to be re-established and tested.

What to do:

• Authenticate Connections: Go through your list of integrations (e.g., Salesforce, Jira, Slack) and re-authenticate their connection to the new helpdesk using API keys or OAuth.
• Test Data Sync: For each integration, perform a test action to ensure data flows correctly. For example, link a test ticket to a Jira issue or sync a customer contact with your CRM.

Phase 3: Post-Cutover Hypercare (First 24-72 Hours)

You're live. But the job isn't done. The first few hours and days are a critical "hypercare" period where your team provides heightened support and monitoring to catch any issues that slipped through the cracks.

11. Establish a "War Room" for Immediate Support

Why it's critical: Issues will come up. Having a centralized, real-time communication channel allows you to identify and resolve them instantly, before they impact multiple agents or customers.

What to do:

• Open a Dedicated Channel: Create a dedicated Slack channel, Microsoft Teams chat, or even a live conference bridge.
• Mandatory Participation: Require all key personnel, migration leads, IT staff, support managers, and a representative from your helpdesk vendor or migration partner, to be present and available in the war room.
• Triage Issues Rapidly: Use this channel for agents to report any bugs, data discrepancies, or workflow problems. The technical team should be on standby to investigate and deploy fixes immediately.

12. Communicate with Your Entire Company

Why it's critical: Your support team isn't the only one who uses the helpdesk. Sales might need to check on a customer's ticket history, or marketing might need to pull reports. Everyone needs to know the migration is complete.

What to do:

• Send a Company-Wide "We're Live!" Email: Announce that the new helpdesk is live. Include a direct link, login instructions, and contact information for the support war room.
• Update Internal Documentation: Ensure any links to the old helpdesk in your company's internal wiki or knowledge base are updated.

13. Actively Monitor System Performance and Error Logs

Why it's critical: Proactive monitoring allows you to catch systemic issues before your agents or customers do. A spike in API errors or slow-loading tickets could indicate a deeper problem.

What to do:

• Watch the Dashboards: Keep a close eye on the performance dashboards of your new helpdesk provider. Look for unusual latency, high CPU usage, or API rate limit warnings.
• Review Logs: Have your technical team actively tail the application and integration error logs. Look for recurring error messages that could signal a widespread issue.

Rollback criteria for this phase: If you observe any of the following in the first 24 hours, escalate immediately to a rollback decision: (a) more than 5% of inbound tickets are not routing correctly after automations are enabled, (b) a critical integration (CRM sync, billing system) is producing consistent errors with no clear fix timeline, or (c) agents report that ticket history for more than 1% of active accounts is missing or corrupted.

14. Gather Real-Time Feedback from the Front Lines

Why it's critical: Your support agents are the power users. They will be the first to notice if a workflow is clunky, a macro is missing, or a data field is incorrect. Their immediate feedback is invaluable for post-launch optimization.

What to do:

• Encourage Reporting: Make it clear that no issue is too small to report during the hypercare period.
• Check in Regularly: Project managers should actively check in with support team leads throughout the day to ask how things are going.
• Document Everything: Create a shared document or project board to track all reported issues, assign owners, and monitor their resolution status.

15. Plan for a Post-Mortem and Celebrate Success

Why it's critical: Every project, successful or not, is a learning opportunity. A post-mortem helps you refine your processes for future projects. And just as importantly, after a high-stakes project like this, your team deserves recognition.

What to do:

• Schedule the Post-Mortem: Schedule this meeting for a week after go-live, once the dust has settled.
• Review the Project: Discuss what went well, what didn't, and what you would do differently next time.
• Acknowledge the Team: Publicly and privately thank everyone involved in the project. A successful helpdesk migration is a massive team effort. Celebrate the win!

Platform-Specific Gotchas

Generic checklists don't account for the differences between platforms. Here are the edge cases most likely to trip you up during a cutover, depending on which systems you're working with.

Zendesk (as source)

• The Incremental Exports API — which is what most delta migration scripts rely on — has a 1,000-record-per-page limit and a rate limit of 10 requests per minute on most plans. For high-volume accounts, a delta run covering even a few hours of activity can take longer than expected. Build this into your maintenance window estimate.
• Zendesk ticket IDs are sequential integers and are reliable as external ID keys in the target system. Always map and preserve them.
• Side conversation threads (Slack-linked conversations, email side threads) are not included in the standard Tickets API export. They require a separate API call per ticket and are frequently missed by migration tooling.

Freshdesk (as source)

• Freshdesk's export API paginates using page and per_page parameters with a maximum of 100 records per page. There is no cursor-based pagination, which means if records are created or updated during a long export run, your page offsets can drift and you may miss records.
• Freshdesk stores private notes differently from public replies. If your migration script doesn't distinguish the private boolean on note objects, private agent notes will be migrated as public customer-visible comments.

Freshdesk (as target)

• The Freshdesk Tickets API enforces a rate limit of 40 API calls per minute on the default plan (Growth) and 80/min on Pro. For a large delta import, you will hit this. Plan for throttling logic in your import script.
• Freshdesk attachment size is capped at 20MB per file. Any Zendesk attachment exceeding this limit will fail on import. Your QA step should include an explicit scan for oversized attachments before migration begins.

Intercom (as source)

• Intercom's data model treats conversations differently from ticket-based systems. A "conversation" can have multiple participants, re-open after resolution, and carry attributes not easily mapped to a standard ticket schema. Mapping Intercom conversations to Zendesk or Freshdesk tickets requires explicit decisions about how to handle multi-participant threads and conversation parts.
• Intercom does not provide a native bulk export for conversations. All exports require API pagination through the /conversations endpoint with rate limits of 83 requests per 10 seconds (about 500 per minute). At scale, this is the dominant constraint on migration speed.

Jira Service Management (as source or target)

• JSM stores issue history (audit log, field change history) separately from comments. Most migration tools move comments but not field change history. If your compliance requirements need full audit trail portability, this must be explicitly handled.
• JSM's issue link types ("is blocked by," "relates to," "duplicates") are not a standard field and won't map automatically to most target systems.

Don't Go It Alone: The ClonePartner Advantage

Navigating a helpdesk migration cutover is a high-pressure, zero-margin-for-error endeavor. While this checklist provides a solid framework, the ultimate key to a truly seamless transition is expertise.

At ClonePartner, we do more than just move data. We provide an engineer-led service that handles every complexity for you — including the platform-specific edge cases, delta migration logic, and automation re-enablement sequencing covered in this guide.

If you're facing a helpdesk migration and the thought of go-live day is keeping you up at night, let's talk.

Book a free Consultation today and learn how ClonePartner can make your helpdesk migration a predictable success.