Ticket Data Migration and Field Mapping (Onboarding)

Ticket Data Migration and Field Mapping (Onboarding)

1. 01

   Freeze the legacy ticket queue and export a full snapshot before any import begins

   Pull every open, pending, and closed ticket with timestamps, assignee IDs, and channel origin. A frozen snapshot gives you a rollback point if field mapping corrupts thread history.

2. 02

   Inventory every field the old system captured and mark each as keep, merge, or drop

   Legacy helpdesks accumulate custom fields nobody uses. Map status values, priority scales, and tag taxonomies side by side so nothing silently collapses into a default bucket.

3. 03

   Rebuild the status and priority taxonomy in the new platform before importing a single record

   Agencies running managed support for multiple clients often inherit three or four different status vocabularies. Define one canonical set, then write the translation table that converts each legacy value into it.

4. 04

   Test the import against a 200-ticket sample and verify thread integrity end to end

   Check that internal notes stay internal, attachments resolve, and timestamps survive timezone conversion. BoldDesk and Help Scout both expose import tooling, but the field-mapping decisions are yours to validate.

5. 05

   Reassign ownership by matching legacy agent identities to new seat records

   Departing staff leave orphaned tickets. Route those to a holding queue rather than a random active agent, and document the reassignment rule for the client.

6. 06

   Run the full migration during a low-volume window and keep the legacy system read-only for 14 days

   Parallel access lets agents answer from the old queue if the new one misbehaves. After two weeks of clean operation, archive the legacy instance.

7. 07

   Reconcile ticket counts and spot-check 20 random records against the source export

   A count match alone proves nothing. Open the records and confirm the conversation reads correctly from first message to resolution.

8. 08

   Document the field mapping table and hand it to the client as part of the onboarding record

   When a retainer renews or a new analyst joins the account, the mapping table explains why a ticket sits in a given state. Without it, every future audit restarts from zero.