How to Migrate From Intercom for Healthcare Support

To migrate a healthcare support team from Intercom, preserve the customer conversation and every open obligation before switching the replying system. Test the destination with a small, representative import. Keep one system responsible for outgoing replies on each thread during the transition.

A migration can move many records successfully and still lose the detail a patient is waiting on. Attachments, internal notes, promised credits, and an unanswered pharmacy question deserve as much attention as the contact list.

Write down what the move must improve

Choose a concrete reason for leaving: cost, an unsuitable inbox workflow, difficult account lookups, or time spent coordinating with vendors. Define how you will check that the destination improves it.

If the expensive work happens outside the inbox, test that work before migrating all history. A new inbox may make replies easier while leaving the investigation burden unchanged.

For a cost-driven decision, use our Intercom alternatives cost guide. Include import work, staff training, and the period when both systems remain available. Obtain the destination's scope in writing before setting a cancellation date.

Approve the destination before exporting PHI

Confirm the destination's agreement, account access, and intended services with your privacy and security reviewers. Include any migration contractor or transfer tool that will handle patient conversations.

HHS business associate contract guidance is a starting point for that review. A signed agreement with the source platform does not establish the arrangement for a new destination or an outside migration service.

Choose where the export will be stored, who may open it, and how temporary copies are removed after verification. Treat the exported archive as patient information throughout the project. Use synthetic samples for early development when practical.

Distinguish conversation history from reporting exports

Intercom exposes several kinds of export and API functionality. Pick the one that returns the records your migration requires.

Its content data export reference describes outbound delivery and engagement data; it explicitly excludes raw message and conversation content. A successful job from that API would not prove that you had saved your support transcripts.

Use the current Intercom API documentation to establish how your authorized export retrieves conversations and their parts. Verify the version, permissions, and response limits for the method you choose.

Ask the migration owner to show a source conversation alongside the resulting export. A row count or “completed” indicator cannot establish whether the original question and reply body are present.

Build a field map for a difficult thread

Select a synthetic thread with several replies and an attachment. Include an internal note that must remain private and a later customer correction.

Scroll the table to compare all options →

Make the handling of unsupported fields explicit. If the destination cannot display something natively, decide how authorized staff will read it. Do not flatten private notes into the customer transcript to make the import look complete.

Check edited or corrected information carefully. A later account email change should not rewrite the historical sender of an earlier message. Staff need to understand who said what at the time.

Carry forward the unanswered needs

Read the relevant originals through the latest inbound message. An old conversation may contain a billing concern, a request for an availability update, and a promised offer. A refund might settle the charge while the request for a future update remains open.

For each unresolved need, retain the evidence and next owner. Avoid converting the latest generic follow-up into proof that the earlier questions were answered. Imported update times can also make an old record look newly active; preserve the original message chronology.

Have a support lead inspect these cases independently. They should be able to explain the customer's outstanding need from the destination without asking the migration engineer to reconstruct it.

Give every live thread one replying system

During overlap, decide how new conversations and existing threads are handled. Make that rule visible to the operators answering them. Disable conflicting automation before the destination begins replying to the same audience.

Test an incoming email reply to an old thread after the new system starts receiving new requests. Confirm where it arrives and who sees it. Include a reply that reaches both platforms through forwarding so you can recognize and prevent duplicate outgoing messages.

An uncertain send needs reconciliation with the original channel. Moving systems does not make it safe to resend. Keep the original message reference and result available to the operator who investigates it.

Rehearse the cutover and recovery path

Use a small pilot group with synthetic data first. Run a final change capture for messages that arrived after the initial export. Compare the source and destination for that period so a busy afternoon does not leave a gap.

Agree who can stop the cutover and where support will continue if the destination fails. Keep the old system available under the approved retention and access arrangement until the team has verified the move.

After cutover, review replies, ownership, and attachment access from the operator and customer perspectives. Track missed messages and duplicate responses explicitly. A passing import check does not establish that live routing works.

Plan a Summer AI migration around your open work

Summer AI offers telehealth support across connected tools, with a BAA available for every customer. Review an Intercom migration with Summer AI to establish the supported import scope, channel transition, and the work your operators need to retain.

Bring a synthetic thread with a private note and an unfinished promise. Ask how it would appear to an operator and what the customer would see. Confirm the actual migration capabilities before committing to an automated transfer.

Migration questions

Can we import contacts first?

You can sequence the project that way, but contacts alone do not preserve the support conversation. Verify the thread, its authorship, and remaining obligations before retiring source access.

Should we delete the old workspace immediately?

Follow your approved retention and contractual requirements after the migration is verified. Establish access and deletion responsibilities as part of the project rather than making deletion a default cutover step.

Can we pilot Summer AI without a complete move?

Discuss your desired workflow and source-system responsibilities during setup. Confirm how messages and ownership will be handled for the proposed pilot before enabling replies.