How can I migrate a customer-support ticket queue without losing assignments?

Start with an ownership inventory—not the import itself. Export or list the queue’s current tickets and record the owner on each one, including whether the owner is a person, team, or unassigned queue. Separately list the people and teams that can receive tickets in the destination. Make a crosswalk from each source owner to a destination owner, and flag any source owner with no confirmed match. Decide explicitly what should happen to tickets owned by former staff or inactive accounts; do not silently assign them to someone else.

For Microsoft’s documented Salesforce-to-Dynamics 365 migration route, target users must already exist, and user mapping is used to resolve record ownership. Its preparation guidance includes setting up target users and reviewing inactive users who own historical records [S1]. That is specific to that migration route, not a rule for every support platform. For any platform pair, confirm how that product handles owners and teams before relying on a mapping.

Make one row for each field or relationship that matters to how a ticket is handled. Include the source field, destination field, transformation or matching rule, and how you will check the result. At minimum, map owner, status, priority, tags, escalation indicator or details, and any queue or team assignment. Add ticket ID or another stable identifier so you can compare the same record on both sides.

Example template:

Source ticket ID | Source field/value | Destination field | Conversion or match rule | Validation check | Unresolved?

A sample row might be: [T-1042] | owner: [Team A] | [destination team field] | map to [Team A equivalent] | compare owner after test import | no. These are placeholders, not claims about a particular system. If a field has no clear destination equivalent, mark it as unresolved and agree whether to transform, preserve elsewhere, or exclude it before moving data. Don’t treat similarly named fields as equivalent without checking their meaning.

Not necessarily. Treat stored ticket ownership and automatic assignment behavior as two separate work items. Write down the source rules that send tickets to a person, team, or queue—for example, rules based on category, priority, or escalation—and identify which destination rule, if any, is meant to reproduce each one. Record the rule’s conditions, intended recipient, and what should happen when no condition matches. Then create or configure the destination rules using that platform’s supported process.

For the documented Salesforce-to-Dynamics 365 migration, Microsoft identifies case ownership and lifecycle-status processing, but its mapping guidance does not establish that every field, escalation detail, or assignment rule transfers unchanged [S2]. So don’t infer rule preservation from a successful ticket import. Keep the rule list with the migration plan and test routing behavior in the destination independently.

Use a non-production destination first, with test records that cover different owners, statuses, priorities, tags, and escalation cases. Include records owned by inactive users, unassigned records, and examples that exercise each important routing rule. For each test, compare the source and destination using the stable ticket identifier: check that the intended owner and mapped values appear, then test whether the destination routes a new or reopened ticket as intended. Record mismatches rather than fixing them invisibly, so you can adjust the map or rule and repeat the test.

A useful result log is: [ticket ID] | [expected owner] | [actual owner] | [fields checked] | [rule exercised] | [pass / issue] | [next action]. Before production, reconcile source and destination record counts, review per-record errors and migration logs, and investigate any unexplained differences. In the documented Salesforce-to-Dynamics 365 workflow, Microsoft calls for preflight and result checks and testing in a non-production Dynamics environment; it also notes that outcomes depend on source data quality [S3]. Those checks help organize verification but do not guarantee that every assignment or ticket field is preserved.