Helpdesk migration
Field-level mapping, validation, and rollback between Helpdesk 365 and Zendesk. We move data and schema; workflows are rebuilt natively in Zendesk.
Helpdesk 365
Source
Zendesk
Destination
Compatibility
7 of 10
objects map 1:1 between Helpdesk 365 and Zendesk.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from Helpdesk 365 to Zendesk is a platform shift from a SharePoint list-backed ticketing app to a purpose-built SaaS helpdesk with a mature API surface. Helpdesk 365 stores tickets, contacts, and companies in SharePoint lists with attachment URLs pointing to document libraries; Zendesk stores these as normalized relational records with thread history, organization relationships, and a separate Help Center for knowledge base content. We extract from Helpdesk 365 through its admin Export tab and REST API, map contacts to Zendesk end-users and organizations, map companies to Zendesk organizations, and resolve the custom field count against the Standard plan's five-field cap before committing to a field-level plan. Knowledge base articles have no native export in Helpdesk 365 and no native bulk import in Zendesk Guide, so we extract article HTML via page scraping or API evaluation and write them through the Zendesk Help Center API with category and section hierarchy preserved. Attachment files stored in SharePoint document libraries migrate as linked attachments in Zendesk tickets. Automations, SLA policies, and routing rules in Helpdesk 365 do not migrate; we deliver a written inventory of these for the customer to rebuild in Zendesk.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Helpdesk 365 object lands in Zendesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Helpdesk 365
Ticket
Zendesk
Ticket
1:1Helpdesk 365 tickets map directly to Zendesk tickets. The Helpdesk 365 ticket ID becomes a custom field ticket_id_hdk365__c on the Zendesk ticket for audit traceability. Ticket status (Open, Pending, Resolved, Closed) maps to Zendesk ticket status with a custom field preserving the original Helpdesk 365 status name. Priority and assignee map directly. Thread history (comments, internal notes) migrates as Zendesk ticket comments with the author set to the mapped agent user and the public/private flag preserved from the Helpdesk 365 channel type.
Helpdesk 365
Contact
Zendesk
End-User
1:1Helpdesk 365 contacts map to Zendesk end-users. Email address is the primary dedupe key. Name, phone, and organization link migrate directly. The Helpdesk 365 contact ID becomes a custom field contact_id_hdk365__c on the Zendesk user record. Any contact without an email address receives a generated placeholder email using the pattern contact-{id}@migrated.local so that the Zendesk import accepts the record.
Helpdesk 365
Company
Zendesk
Organization
1:1Helpdesk 365 companies map to Zendesk organizations. The company name becomes the organization name, domain becomes the organization domain (used for automatic user-to-org association), and the company ID becomes a custom field org_id_hdk365__c. Organization is created before end-user import so that the organization_id lookup is satisfied at the moment of end-user insert.
Helpdesk 365
Agent
Zendesk
Agent
1:1Helpdesk 365 agent profiles (name, email, role) map to Zendesk agent accounts. We extract agent records from Helpdesk 365 during ticket export or via a dedicated agent read if the endpoint is confirmed available during scoping. Agent email becomes the Zendesk user email, and role mapping (Admin, Agent) transfers to Zendesk's agent role model. Agents without email are flagged in the reconciliation report for manual provisioning before ticket import.
Helpdesk 365
Team
Zendesk
Group
1:1Helpdesk 365 teams map to Zendesk groups. Team name and team membership (list of agent IDs) translate to Zendesk group name and group membership. Groups are created before agent import so that the group assignment on tickets can reference a valid group_id. If Helpdesk 365 team export is not confirmed at scoping, we infer team membership from the assigned_agent_id on each ticket record.
Helpdesk 365
Custom Field
Zendesk
Ticket Custom Field
lossyHelpdesk 365 custom ticket fields map to Zendesk ticket custom fields. We inspect the Helpdesk 365 field schema during scoping to count active custom fields. If the source system uses Standard plan (capped at five), we map all five. If Enterprise plan, we map all active fields. Field types (dropdown, text, numeric, date, checkbox) map to equivalent Zendesk custom field types. Fields exceeding five on Standard plan are flagged in the scoping report for the customer to select which to migrate.
Helpdesk 365
Tag
Zendesk
Tag
1:1Helpdesk 365 tags stored on tickets migrate as Zendesk tags. We extract tags from ticket records during ticket extraction rather than from a standalone tag endpoint (not confirmed in Helpdesk 365 API). Tags migrate as flat strings on the Zendesk ticket. The customer chooses whether to migrate all tags or a filtered set during scoping.
Helpdesk 365
Knowledge Base Article
Zendesk
Help Center Article
lossyHelpdesk 365 knowledge base articles have no documented export API, so we evaluate extraction via page scraping or admin-level data evaluation during scoping. Article title, HTML body, category, and publish status extract and write to Zendesk Help Center via the Help Center Articles API. Zendesk Help Center requires a parent Section and Category to exist before articles can be created, so we migrate categories and sections first, then articles in dependency order. Draft articles migrate as draft in Zendesk; published articles migrate as published.
Helpdesk 365
Attachment
Zendesk
Ticket Attachment
1:1Helpdesk 365 ticket attachments are stored as URLs pointing to SharePoint document libraries. We extract the attachment URL from each ticket record and evaluate whether to migrate the underlying file. If the target Zendesk plan supports attachment upload via API, we download the SharePoint file, upload to Zendesk as a ticket attachment, and replace the URL with a Zendesk-hosted attachment reference. If the SharePoint library is not accessible externally, we preserve the original URL as a custom field attachment_url_hdk365__c on the Zendesk ticket comment for manual resolution post-migration.
Helpdesk 365
SLA Configuration
Zendesk
SLA Policy (documented, not migrated)
lossyHelpdesk 365 SLA policies (first response time, next response time, resolution time) do not export as data. We inspect the Helpdesk 365 SLA configuration during scoping, document every active SLA policy with its name, business hours, and rule conditions, and deliver a written inventory mapping each to a Zendesk SLA Policy equivalent. The customer's Zendesk admin rebuilds SLA policies in Zendesk Admin Center post-migration. This is standard scope; we do not configure Zendesk SLA policies as part of the migration run.
| Helpdesk 365 | Zendesk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Contact | End-User1:1 | Fully supported | |
| Company | Organization1:1 | Fully supported | |
| Agent | Agent1:1 | Fully supported | |
| Team | Group1:1 | Fully supported | |
| Custom Field | Ticket Custom Fieldlossy | Fully supported | |
| Tag | Tag1:1 | Fully supported | |
| Knowledge Base Article | Help Center Articlelossy | Fully supported | |
| Attachment | Ticket Attachment1:1 | Fully supported | |
| SLA Configuration | SLA Policy (documented, not migrated)lossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Helpdesk 365 gotchas
Standard plan caps custom fields at five
API key tied to admin user account
No documented bulk export endpoint
Zendesk gotchas
Data export requires API scripting on non-Enterprise plans
Automations cap at 500 active rules and 1,000 tickets per hour
Help Center has no native export feature
Custom Objects and full data export are Enterprise-only
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the Helpdesk 365 tenant across plan tier (Standard or Enterprise), active custom fields count, ticket volume and date range, contact and company record counts, agent and team count, knowledge base article count and category structure, and attachment file accessibility. We also inspect the Zendesk destination environment for plan tier, existing data (if any), active triggers and automations, and Help Center configuration. The discovery output is a written migration scope with record counts, object dependency order, and a confirmed extraction method for knowledge base articles.
Schema pre-configuration in Zendesk
We configure the Zendesk destination before any data moves. This includes creating organizations (from Helpdesk 365 companies) and groups (from Helpdesk 365 teams) as container records so that ticket imports can reference valid group_id and organization_id values. We create custom ticket fields mapped to Helpdesk 365 custom fields with equivalent types. We temporarily disable active triggers and SLA policies in Zendesk Admin to suppress notification firing during import. If Helpdesk 365 is on Standard plan with more than five source custom fields, we agree on the field subset with the customer before this step.
User and agent import
We import Helpdesk 365 agents first, mapping each to a Zendesk agent account with the correct role (Admin or Agent). We import Helpdesk 365 contacts as Zendesk end-users with organization_id resolved from the company-to-org mapping. Contacts without email receive generated placeholder addresses. Agents and contacts without matches in the destination are logged to a reconciliation report for the customer's admin to resolve before ticket import begins.
Ticket import with thread history
We import Helpdesk 365 tickets in dependency order: parent ticket record first, then comments and internal notes as Zendesk ticket comments with public or private flag preserved. Attachment URLs from SharePoint document libraries are evaluated for external accessibility; accessible files are downloaded and re-uploaded as Zendesk-hosted attachments. Tags from Helpdesk 365 migrate as Zendesk tags on each ticket. Custom field values migrate to the mapped Zendesk custom field ID. We batch tickets in chunks of 100-200 records, respect Zendesk API rate limits per plan tier, and emit a row-count reconciliation report after each batch.
Knowledge base migration
We extract Helpdesk 365 knowledge base articles via the confirmed method (API evaluation or page scraping). We create Zendesk Help Center categories and sections first, then articles as draft or published based on the original publish status. Inline images in article HTML are extracted as separate ContentDocument records and the HTML src attributes updated to point to the Zendesk-hosted URLs. If multiple locales are in scope, translations migrate via the Zendesk Help Center translation API after the base article exists.
Cutover, validation, and handoff
We freeze writes to Helpdesk 365 during the final cutover window, run a delta migration of any records modified during the migration run, then re-enable triggers and SLA policies in Zendesk Admin. We deliver a written automation inventory documenting every Helpdesk 365 SLA policy, routing rule, and automation requiring rebuild in Zendesk, with Zendesk equivalents noted. We deliver a reconciliation report comparing record counts in Helpdesk 365 against Zendesk destination counts. We support a 72-hour hypercare window for record-level issues; we do not rebuild automations or SLA policies in Zendesk as standard scope.
Platform deep dives
Helpdesk 365
Source
Strengths
Weaknesses
Zendesk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Helpdesk 365 and Zendesk.
Object compatibility
3 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Helpdesk 365: Not publicly documented; Microsoft Graph throttling applies as the backend transport.
Data volume sensitivity
Helpdesk 365 doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Helpdesk 365 to Zendesk migration scoping. Not seeing yours? Book a call.
Walk through your Helpdesk 365 to Zendesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Helpdesk 365
Other ways to arrive at Zendesk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.