Help Desk Migration Field Map template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

Every help-desk migration lives or dies on one document: the field map. This worksheet forces the question 'where exactly does this field land in Zendesk, and what has to happen to it on the way?' for every field in your old system — before anyone writes a script or clicks an import button.

It comes pre-filled with the eight mappings that trip up most migrations: statuses that don't correspond one-to-one, priorities with different scales, custom fields with changed types, and the created-date problem. Replace our sample rows with your own inventory and you have the artifact a migration engineer, admin, and stakeholder can all sign off on.

How to use it, step by step

1. Inventory every field in the source system. Export a sample ticket with all fields visible, and list every field — including the embarrassing abandoned ones. Unmapped fields are how data quietly disappears in migrations.
2. Name the Zendesk destination precisely. 'A custom field' isn't a destination; 'custom dropdown field: Product Area (to be created)' is. If the destination doesn't exist yet, say so in the row — that becomes your build list.
3. Describe the transform, not just the mapping. Status value translations, priority rescaling, date format changes, user-ID lookups — write the rule in transform_needed so it can be implemented and tested rather than remembered.
4. Paste a real sample value into every row. A genuine value from your data exposes surprises a field name hides — empty fields, HTML in text fields, IDs where names should be.
5. Mark what doesn't migrate cleanly and decide. Some fields won't survive — that's normal. The migrates_cleanly column makes it a documented decision with an owner instead of a post-launch discovery.
6. Get a sign-off before the build starts. Circulate the finished sheet to support leadership. Every migration argument you have on this spreadsheet is an argument you don't have in production.

What each column means

Common mistakes to avoid

• Mapping fields by name similarity without checking types — a source text field into a Zendesk dropdown fails on every unexpected value.
• Forgetting created/updated timestamps: most imports set creation date to import day unless you explicitly preserve dates, which destroys reporting history.
• Leaving status mapping implicit — 'Pending' rarely means the same thing in two systems, and agents feel that mismatch daily.
• Skipping the sample_value column — it's the single cheapest way to catch HTML, emojis, and nulls before they hit the importer.

Questions, answered

Do I really need this if I'm using a migration tool?

Especially then. Tools execute mappings; they don't decide them. Every migration tool asks you the questions this sheet answers — the difference is whether you answer them deliberately or under time pressure inside a wizard.

What happens to fields marked 'doesn't migrate cleanly'?

Three honest options: transform them (with the rule written down), park them in a ticket comment or tag so the data survives searchably, or consciously drop them with stakeholder sign-off. All three beat silent loss.

Should ticket history migrate as comments?

Usually yes — conversation history lands as ticket comments with original timestamps where possible. Attachment handling and author mapping are the fiddly parts, which is why they each deserve a row in this sheet.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.