A customer-conversation migration is not complete when the import reaches 100 percent. It is complete when an agent can open a real case in the new system and still understand who the customer is, what happened, who owns the next step, and what must not be sent again.
Most migration plans begin with fields and row counts. Those checks matter, but they do not prove that the support operation survived the move. A status or tag can arrive with a different meaning. Every message can be present while its customer, order, consent record, or owner is missing.
Define what must still be true
Before mapping data, write a short set of statements that must remain true after cutover. For a typical support operation, they might be these.
- Every conversation belongs to the correct customer and channel identity.
- Messages, private notes, attachments, and timestamps stay in the right order.
- Open work has one current owner, state, deadline, and next action.
- Consent, opt-out, and source evidence remain distinguishable from ordinary tags.
- Reports can separate migrated history from work created after launch.
This is the acceptance contract. Different systems expose different versions of everything. Zendesk's current export guide shows why format matters. CSV omits comments and descriptions, while JSON and XML have different coverage and limits. A valid file can still be the wrong source.
Map meaning before fields
Do not begin with a spreadsheet that says source status maps to destination status. First ask what each value causes in the old operation.
Suppose the old system distinguishes waiting for a customer from waiting for a supplier, while the new one calls both snoozed. The mapping removes the difference between a customer commitment and an external dependency. Reminders and reports change although the import reports no error.
Map the meaning of identities, states, priorities, tags, assignments, relationships, and timestamps. Record old and new definitions, intended behavior, and proof. Keep former IDs in a dedicated external-ID field for traceability.
Modern conversation objects are not just message bodies. Intercom's conversation API documents contacts, state, priority, assignees, tags, custom attributes, parts, and linked objects, plus a 500-part retrieval limit. Test completeness instead of assuming one successful response contains the full history.
Separate live work from history
Closed history and active customer work need different plans. Historical records can often be copied, checked, and made read-only. An open conversation is still receiving replies, changing owners, and moving through deadlines while the migration runs.
Pylon's current migration documentation makes the distinction concrete. Its traditional API route migrates closed tickets as historical snapshots, but not open tickets, because the communication channel does not move with the record. Whatever the platform, ask where the next customer reply will arrive during cutover.
Choose one authority for new activity. Keep active cases in the old system until closure, move them through a controlled procedure, or switch channel delivery at a defined moment and reconcile the overlap. Two independent senders create duplicate replies and split ownership.
Build a proof set
A pilot should contain difficult records, not just tidy ones. Select a small proof set before the full run.
- A long conversation with attachments and private notes.
- One customer with several channel identities.
- An open case with a deadline and named owner.
- A merged, reopened, or transferred case.
- A record with consent or opt-out evidence.
- A case linked to an order, company, lead, or other business object.
Check relationships separately. HubSpot's current ticket API makes associations with contacts, companies, and activities explicit. If the ticket moves without those links, the text survived but its context did not.
Compare each proof record side by side. Check message order, authorship, timezones, attachments, identity, state, owner, relationships, and next action. Then let an agent perform the next real task. The record must be usable, not merely similar.
Cut over in layers
Freeze tag definitions, status rules, custom fields, and routing logic while testing. Take a protected export, run the proof set, import history, reconcile counts, handle active work, and switch channel delivery once.
During the first operating window, watch failed imports, unowned cases, duplicate identities, unexpected notifications, and missing attachments. Define rollback conditions before launch. Missing active work, broken identity links, incorrect consent, and duplicate customer messages must pause the cutover.
Keep only what you can justify
Migration is also a retention decision. The UK's Information Commissioner's Office guidance on storage limitation says personal data should not be kept longer than needed and retention must be justified. Decide what remains operational, enters a restricted archive, or is deleted. Preserve deletion duties and legal holds.
Make the new record useful
The practical value of a shared inbox is that history, assignment, notes, and status stay around the same work. A connected customer record keeps fields, tags, consent history, and ownership usable.
When evaluating DripTell or another destination, bring the proof set. Ask to see the imported records and complete the next action. A convincing demo is an agent continuing a real conversation without asking the customer to reconstruct the past.
Frequently Asked Questions
What customer conversation data should be migrated
Migrate the content and relationships needed to continue service, meet retention duties, explain prior decisions, and report accurately. Archive or delete other data according to a documented policy instead of copying everything by default.
How should open conversations be handled during migration
Give new activity one authority. Keep open cases in the old system until closure, move them through a controlled live-work process, or switch delivery at a defined cutover and reconcile the overlap.
How can a team verify that no context was lost
Use a difficult proof set and compare identity, chronology, authorship, attachments, state, ownership, relationships, deadlines, and next actions. Then have an agent perform the next real task in the new platform.
Should old tags be copied exactly
Not automatically. Preserve a tag only after documenting what it means, who applies it, what rule uses it, and how the destination will reproduce that behavior.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy