How to export your data from Intercom before your contract ends
Intercom's export routes cover different slices of your data, and only the Conversations API returns full message history. If a renewal, a pricing change, a data residency rule or a plan to leave has put your support records in motion, you need to know which route delivers which content before you rely on any of them. The main routes are PDF and text transcripts, which are produced in batches of a few hundred conversations, a CSV of reporting metadata that carries no message content, and a JSON export to Amazon S3 that omits transcripts. Each one answers a different question, so none of them alone is a complete archive.
The practical gap is between metadata and content. A CSV can tell you how many conversations were opened, when they closed and who handled them, but it cannot reproduce what customers and agents wrote. Transcript exports keep readable text, yet their batch limit means you must reconcile batch counts against your total conversation volume from reporting. Build a simple checklist: total conversations, total batches exported, and a sample of conversations checked for attachments, internal notes, contact attributes and tags. Ask Intercom to confirm in writing which fields each route includes for your workspace and plan, because export behavior can change.
Verify the export before you give notice or cancel. Run the Conversations API pull for a sample of conversations, load them into a second system, and confirm message order, timestamps, author names and attachment links. Keep the full API extract as your archive of record and schedule it early, leaving time to rerun it if a sample fails. Keep workspace access until verification is complete, and check in your contract what happens to data after cancellation, including how long Intercom retains it. Your own export evidence is what protects you if a gap appears later.
What Intercom exports, in which format, and with which limits
This table lists each documented Intercom export route, the data it carries, its format and the gaps that matter for a migration. Read the missing column first, because message content is the item most often left out. Confirm every limit against Intercom's current export documentation and your plan before you plan a cutover.
| Data type | Export method | Format and limits | What is missing |
|---|---|---|---|
| Conversation transcripts (PDF and text) | Export of selected conversations from the Intercom inbox | PDF and text files delivered in batches; confirm the current batch size in Intercom's export documentation | Structured fields for reporting and re-import; output is for reading, not for loading into another system |
| Reporting metadata for conversations | CSV export from Intercom reporting | Flat CSV rows with timestamps, assignees, tags and status; confirm row limits for your plan | Message content, attachments and the full conversation thread |
| Contacts, conversations and events in bulk | JSON export to Amazon S3 | JSON files written to an S3 bucket you control; confirm eligibility and file limits with Intercom | Conversation transcripts, so chat history must come from another route |
| Full conversation history with messages | Conversations API (paginated REST calls) | JSON responses per conversation; rate limits apply, so confirm current limits and plan allowances | Nothing in principle, but scripting, paging and retries are your effort to build and run |
| Help Center articles and collections | Help Center export or API reads | Article content and structure; confirm which formats Intercom currently offers | Article history, redirects and in-widget search settings usually need manual rebuilding |
| Users, companies and tags | CSV or API export of contact records | Attribute columns with custom attributes as separate fields; confirm attribute naming rules | Message history linked to each contact, and internal notes unless requested through the API |
| Attachments and uploaded files | Included in some transcript exports or fetched via API links | Files keep their original type; confirm whether links expire before you download | Files may be absent from CSV and S3 exports, so check each route before you rely on it |
What does not export in the standard routes and how to recover it
The standard Intercom routes return reporting metadata and some transcripts, but they leave out message bodies, configuration and the logic that drives your support operation. Each gap below needs a named recovery path and a question to Intercom before your team treats it as closed.
Message content outside the API
CSV reporting exports carry conversation metadata, and the JSON export to Amazon S3 carries no transcripts, so message bodies, internal notes and attachments are missing from both. The documented route for full history is the Conversations API, which needs a token with read access and a script that pages through every conversation. Before you rely on it, confirm with Intercom which objects the API returns, whether private notes and attachments come back, and how deleted or redacted messages appear.
Messenger and widget settings
Messenger appearance, launcher placement, home screen content and the install snippet are configuration rather than conversation data, and no standard export is documented to return them. Capture them now by screenshotting every settings screen and copying the install snippet from each site where it runs. In Chatwoot, rebuild the website live chat widget and its inbox, then test on a staging page before swapping the script tag. Ask Intercom whether any admin export covers Messenger settings.
Inbox routing and assignment rules
Routing rules decide which team or teammate receives a conversation, and they explain assignments visible in your transcripts. A standard export shows the outcome of those rules, not the rule definitions themselves. Document each rule's conditions, priority order and fallback from the admin screens, then rebuild them as Chatwoot auto-assignment with teams and labels. Ask Intercom whether rule definitions and their change history can be exported at all.
Automation and workflow definitions
Automated messages, bots and workflows hold logic that customers experienced, and no export route is documented to return that logic. Inventory each automation with its trigger, conditions, actions, schedule and any business hours it depends on. Chatwoot offers auto-responders, business hours and automation, so map each item to a native feature or mark it for redesign. Confirm with Intercom whether workflow definitions appear in any data export or only in the admin interface.
Help Center articles and collections
Articles, collections, translations and redirects make up the public knowledge base that customers and Fin both read. Check whether your export route returns drafts, translated versions and collection order, because a published article is not the same as its source content. Plan to move articles into the Chatwoot Help Center portal, then verify internal links and search results on the new domain. Confirm which Help Center content the API returns and whether custom domain settings are included.
Fin AI agent configuration
Fin's behavior depends on the knowledge sources it reads, the guidance you wrote, its handoff rules and the content it was allowed to answer from. None of these are conversation records, so treat them as configuration to document. Record each source, instruction and escalation path, then test a sample of past questions against the target setup. Chatwoot's Captain works with its own setup, so each Fin setting must be rebuilt from its intent and not copied. Confirm with Intercom whether any Fin configuration can be exported.
How the Conversations API pulls full history where the exports stop
The Conversations API is the route to complete transcripts, because it is the only option in this topic that returns the message content of each conversation along with its history. Plan it as a scripted bulk pull, not a click-through task. The API returns results in pages, so the script must follow the pagination cursor until the last page and record where it stopped. Rate limits will throttle a full history pull, so the script needs retries with backoff and a checkpoint that lets it resume after a failure. Confirm the current limits and pagination parameters in Intercom's developer documentation before you size the job, since these are the settings most likely to change.
The team, or an engineer it hires, owns the script and the output. Authentication uses an access token, so decide who creates it, how it is stored in a secrets manager, and how it is rotated. Store the raw JSON responses unchanged in object storage or on disk, with a manifest that lists each conversation ID, the page it came from and the pull date. This keeps the archive auditable if someone later asks how a record was produced. The output format is also the team's decision. A transcript export only helps if the chosen fields, such as author, timestamps, conversation state and attachment references, are documented and can be loaded into the new platform.
The API returns only what the token's permissions allow, so a pull made with a limited token can silently miss conversations, teams or contact data. Before the full run, have someone who knows the workspace check that the token can see every inbox and team that needs archiving. Then run a small test pull, reconcile its counts against the conversations visible in Intercom, and record any gaps. Ask Intercom which objects, such as attachments or archived records, fall outside the Conversations API so you can plan a separate route for them. A signed-off reconciliation report is the evidence that the archive is complete.
Which export route fits which goal
A compliance or legal hold archive has to show what was said, when it was said, and that the record has stayed intact. The PDF and text transcripts are the only routes in this set that carry message content in a form reviewers can read, so they usually form the core of the archive. Because they arrive in batches of a few hundred conversations, the team has to track which batches ran and confirm that none were skipped.
- Transcripts as the readable record: PDF or text transcripts keep the conversation content that reviewers and counsel will read.
- Batch coverage log: Record each batch's date range and conversation count so any gap can be shown and explained.
- Metadata alongside: Pair transcripts with the CSV reporting metadata for identifiers and timestamps that the transcript does not display prominently.
- Insufficient alone: The CSV and S3 routes omit message content, so neither one proves what was said.
Confirm with counsel or your auditor which formats and metadata they accept, how the archive will be stored and checked for integrity, and who holds custody of it.
Moving history into a self-hosted helpdesk means rebuilding conversations as threads, with authors, timestamps and status intact. The Conversations API is the route that returns full message content in a structured form that an import process can use. The PDF, text, CSV and S3 routes produce files a person can read or a spreadsheet can hold, but they do not give an importer the thread structure it needs.
- Conversations API for full history: It is the route to plan around for message content, since the other exports do not supply it.
- Contact identity mapping: Decide how Intercom contact identifiers map to the target's contact model before the first import so conversations attach to the right person.
- Zammad import path: Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, so an Intercom import would go through the Zammad API or custom development. See the Zammad migration documentation.
- Chatwoot import path: Ask the Chatwoot project whether a supported importer exists for your version and what it preserves, including timestamps, authors and attachments.
- Insufficient alone: Transcripts in PDF or text form cannot be turned back into threads in a helpdesk without reconstruction work.
Before the full run, import a small set of conversations into a non-production instance and check authorship, timestamps, attachments and closed status on each one.
Reporting on past volume and satisfaction needs counts, dates and ratings over a fixed period, and it rarely needs the wording of each message. The CSV reporting metadata fits that job because it describes conversations without their content. It works well for trend lines and for comparing periods, but it cannot explain the reasons behind a trend.
- CSV reporting metadata: It suits counts, dates and per-conversation attributes that feed a spreadsheet or business intelligence tool.
- No message content: Topic analysis or reading why a customer gave a low score requires transcripts, which the CSV does not include.
- Matching report definitions: The Chatwoot README lists conversation, agent, inbox, team and CSAT reports, and Zammad documents reporting features that depend on Elasticsearch. Confirm which of your historical metrics you can rebuild from the CSV in each platform.
- Agreed date window: Set the date range and time zone before the export so historical figures line up with figures from the new platform.
- Insufficient alone: Metadata shows volume and score movement but not the cause of either.
Ask the target platform to reproduce one known month's totals from the export before you retire the Intercom reports.
Keeping a copy of customer records and attachments is a retention task. The JSON route to Amazon S3 places structured records in a bucket you control, which suits long-term storage and downstream processing. It does not carry transcripts, so the bucket holds the metadata while the conversation text lives elsewhere. The two must be joined with stable identifiers to be useful together.
- JSON to S3 for records: Structured customer and conversation data lands in storage you operate, which suits long-term retention.
- Transcripts stored separately: Pair the bucket with the transcript or API route so conversation text is kept alongside the records.
- Attachment coverage: Check in a test export whether files shared in conversations are included and, if they are not, where they can be retrieved.
- Storage controls: Set encryption, access logging, retention and deletion rules under your own policy before the first run.
- Stable identifiers: Keep contact and conversation IDs consistent so records and transcripts can be joined later.
Confirm attachment handling in writing against Intercom's current export documentation, then run a restore test from the bucket before relying on it.
The sequence for a complete export with verification
This sequence turns scattered Intercom exports into one verified archive that you control, with a checksum manifest, a reconciliation report and a signed record of what was and was not captured. Each step produces an artifact that the next step checks.
Inventory the workspace and data types
The workspace owner lists every data type in scope: conversations, contacts and companies, help center articles and collections, reports, tags, teams, attachments and automation settings. For each type, record the export route that covers it (transcript export, reporting CSV, S3 JSON or the Conversations API) and the owner who will run it. The artifact is a signed inventory sheet. It is complete when every data type maps to at least one route and no type is marked as unassigned.
Confirm plan, admin rights and API access
The workspace admin confirms in writing which export features the current plan includes, who holds the admin role needed to run them, and which access token will call the Conversations API. Ask Intercom to confirm any feature whose availability is unclear for your plan. The artifact is an access record listing roles, token owner and token scope. It is complete when a single test request to the Conversations API returns a known conversation, and the token owner has been recorded.
Run the reporting and transcript exports
The operator runs each export route from the inventory: reporting CSV files, PDF or text transcripts in batches, and the JSON delivery to Amazon S3. Name each file with its route, date range and batch number, and keep the files in a staging folder. The artifact is a batch log showing every file, its size and its route. It is complete when the batch count for each route matches the inventory, and every gap in batch numbering is explained in the log.
Script the Conversations API pull
The engineer writes a versioned script that pages through the Conversations API and saves each conversation, including its full message history, as raw JSON. The script records pagination cursors, timestamps and any failed requests so they can be retried. The artifact is the script in version control plus one raw JSON file per conversation. It is complete when the number of conversation IDs saved matches the conversation count in the inventory, and every failed request has been retried or logged.
Store output in client-controlled storage with checksums
The engineer moves all staging output into storage that your team controls, such as a bucket or file share in your own cloud account or data center, with encryption at rest and access limited to named roles. The engineer generates a manifest listing each file with its SHA-256 hash. The artifact is the manifest. It is complete when the hashes recomputed from the stored copies match the manifest exactly, and the access list has been reviewed by the data owner.
Verify record counts and sampled transcripts
A second person reconciles the archive against Intercom. They compare record counts for conversations, contacts and articles with the figures shown in Intercom, then pick a random sample of conversations and check that the archived messages, timestamps and author names match what Intercom displays. The artifact is a reconciliation report listing counts, sample IDs and any mismatches. It is complete when every mismatch has a recorded cause and a fix or a documented gap.
Document gaps in a gap register
The owner lists everything the export does not capture or captures only in part, such as automation rules, third-party app data, Messenger configuration, or any attachment the API does not return. For each gap, the owner records the reason, the business impact and whether it will be rebuilt manually or accepted. The artifact is a gap register with an owner and a decision for every line. It is complete when no gap lacks a decision and the open items have been confirmed with Intercom or your own records.
Sign off the archive before any cancellation
The data owner, the security lead and the business owner each sign the archive acceptance record, which references the manifest, the reconciliation report and the gap register. No subscription changes or account closure happen until all three signatures are on file and the archive has been opened successfully by someone outside the export team. The artifact is the signed acceptance record. It is complete when all three approvals are dated and stored with the archive.
What to plan before renewal or termination
Intercom exits tend to fail on timing rather than tooling. The cards below cover the items to settle before the contract end date, from the notice and retention terms to the sign-off on the final archive.
Contract notice and retention terms
Before anything else, read the Intercom agreement for the notice period, the date service ends, and how long Intercom keeps your data after termination. These terms set your real deadline, which may be earlier than the renewal date you have in mind. Ask Intercom to confirm in writing when read access to conversations ends and whether it will provide a full export on request. If the answer is unclear, do not assume the export routes you have tested will still be available at the end.
Time for a full API pull
Pulling full conversation history through the Conversations API is the only route in this guide that includes message content, so it takes the longest. Plan for rate limits, paginated requests, retries and storing each response in a durable format. Budget time for the pull to run, then for checking record counts and spot-checking transcripts against the Intercom interface. Ask Intercom which API rate limits apply to your plan and whether a higher limit is available for a one-time bulk pull.
A test export well before the deadline
Run a complete test export early, using the same scripts and storage you will use at cutover. The test shows which conversations fail, which attachments are missing, and whether your archive opens in the format your records team needs. A failed test leaves time to change the approach, for example by asking Intercom for help with a bulk data request. Keep the test log, because it becomes evidence that the archive was checked.
Freeze on configuration changes
Once you start exporting, stop editing inboxes, teams, automation rules, macros and help center articles, or record every change with a date. Changes made after the export snapshot will not appear in your archive, and you may need to rebuild them later in Chatwoot or Zammad. Agree the freeze date with support leads and the people who own automation. Ask Intercom to confirm whether its audit history and configuration exports are available before the freeze begins.
Parallel running before cutover
Keep Intercom live while the replacement is tested with real traffic, so a gap in the new widget or routing does not stop customer conversations. Parallel running also means deciding which system answers new chats on each day and how replies that started in one system are closed. Confirm with Intercom how long your subscription keeps the Messenger active after the notice date, since that window sets how long you can run both systems.
Sign-off on the archive
Name one owner who accepts the final archive, usually a combination of the business owner for customer records and the compliance or legal lead. The sign-off should cover what is included, what is missing, where the archive is stored, who can access it, and how long it is kept. Record each exception, such as attachments that could not be retrieved, so the gap is documented before Intercom access ends. Ask the vendor for written confirmation of the deletion timeline once the archive is accepted.
Questions buyers ask before exporting Intercom data
Can our team export Intercom data on its own?
Yes, for a partial export. A workspace administrator can run the built-in exports, which produce PDF or text transcripts, CSV reporting metadata, or JSON delivered to Amazon S3. None of these gives you complete conversation content in one structured file that a helpdesk can import. A full history requires the Conversations API, which needs an engineer to write and run the pull, handle pagination and retries, log every request, and map results to the target system. Teams with an admin account and an engineer comfortable with REST APIs can often do this in-house. Teams that must prove completeness to a regulator or auditor usually want an outside review of the process. Confirm current export options and access levels in your own workspace before you plan.
What makes an Intercom data export take longer?
Scope and target format drive the effort more than anything else. The main factors are:
- Conversation volume: more threads mean more API calls, longer runs and more validation work.
- Attachments: files are retrieved separately from message text, so each one needs its own download, checksum and storage path.
- Custom data attributes: contact and conversation fields must be mapped to the fields the target system uses.
- API rate limits: large pulls run in throttled batches, so the script must resume cleanly after interruptions.
- Target format: an archive for legal hold has different structure requirements than an import into Chatwoot or Zammad.
Each factor multiplies the others, so a clear written scope is the best control on effort.
How long does an Intercom export take?
The duration depends on scope, and no timeline is given here. Volume, attachment count, field mapping complexity, number of target systems and the number of review cycles all change the schedule. A small archive of recent conversations with simple fields is a very different job from a multi-year history with attachments and custom attributes moved into a self-hosted system. Ask for a written schedule tied to a defined scope. It should show the sample run, the reconciliation checkpoints, the sign-off dates and what happens if a validation check fails. A schedule without those milestones is hard to hold anyone to.
What does our team need to provide for an Intercom export?
Four things, at minimum:
- An Intercom admin account with rights to run exports and create API access.
- An engineer to build and run the Conversations API pull, including pagination, retries and logging.
- Storage for raw exports, attachments and checksums, with access controls and a retention setting.
- A named owner who signs off on scope, sample results and final acceptance.
The owner should come from support operations or compliance, not only IT, because that person decides what counts as complete. Plan time for that person to review samples. Without a clear owner, the export tends to stall at the acceptance step.
Is an Intercom export enough to move into Chatwoot or Zammad?
Usually not on its own. PDF, CSV and JSON files are archives, and a helpdesk needs records mapped to its own objects: contacts, conversations, messages, attachments, agents and teams. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, and its migration documentation describes the API route for other systems. Confirm with Chatwoot which import paths it supports for Intercom data today. In either case, test the import on a sample in a separate instance, reconcile record counts, and plan a period where both systems run during cutover.
How do we confirm an Intercom export is complete before deleting anything?
Keep the source workspace unchanged until the owner signs off. Compare conversation and message counts against the source, confirm that every attachment was downloaded and matches its recorded checksum, and spot-check threads against the original in Intercom. Record each check with a date, the person who ran it and the result, so the evidence can be shown later. This record supports compliance readiness, but an independent auditor or certification body makes any formal determination. DeployOpen prepares these controls and evidence and does not issue audit reports or attestations.
What does a fixed-scope DeployOpen engagement cover for an Intercom export?
DeployOpen plans, implements and documents the export inside your own environment, whether that is your cloud account, data center or air-gapped network. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. Typical work includes reviewing the current data and sources, designing the export, building and running the API pull, handling attachments, running validation checks, preparing sign-off evidence and writing the runbook. Your legal and compliance teams decide what must be retained. DeployOpen does not publish a price list, and a quote follows from the written scope. Ongoing support is available as a retainer.
How DeployOpen scopes and delivers an Intercom data exit
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Intercom data exit, we treat the export as a scoped engineering project: first confirming which records you need, then building and verifying an extraction you can keep as evidence.
How we scope
- Inventory which Intercom data you need: conversations with full transcripts, contacts, attachments, reporting metadata and help center articles.
- Confirm which export route covers each data type, since PDF, CSV and S3 exports do not carry full message content.
- Agree the scope, deliverables and timeline in writing before any extraction work starts, as engagements are fixed-scope.
How we build
- Build the extraction against the Intercom Conversations API, with a pipeline that resumes safely after rate limits or interruptions.
- Normalize records into a target format and validate counts, timestamps and attachment links against the source workspace.
- Test restores into a staging instance so you can see the exported history before the source is closed.
How we hand over
- Document the export procedure, data mapping, known gaps and the checks used, so your team can rerun or audit it.
- Deliver the extracted archive and scripts into your own storage, with access controlled by your team.
- Walk your administrators through the handover so the knowledge stays inside your organization.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover, if your team wants it.
- Provide prepared systems and evidence for your compliance assessments, while independent auditors issue any formal opinion.
- Confirm with you in writing before any change to scope, so cost and timing stay visible throughout the engagement.
