Intercom EU Data Hosting Trap: The US-to-EU Migration Guide

If your DPO just flagged your Intercom workspace for GDPR compliance, you're probably looking for the toggle to move your data from the US to the EU. That toggle does not exist.

Intercom's own documentation confirms it: direct migration of existing workspace data from one region to another is not possible. You must create a brand-new workspace in the EU region, manually recreate every setting, and accept that your conversation history cannot be natively imported back in. That last part is the one nobody talks about until it's too late. (intercom.com)

This guide breaks down the technical reality of Intercom's EU hosting, the hidden constraints that still route data through the US, how the situation compares to alternatives, and how to engineer a migration path that preserves your historical support context.

For teams already committed to leaving Intercom entirely, we've published platform-specific guides for migrating from Intercom to Zendesk and migrating from Intercom to Trengo.

What Intercom EU Data Hosting Actually Covers

Intercom Regional Data Hosting lets customers host workspace data in AWS eu-west-1 (Dublin, Ireland) instead of the default us-east-1 (North Virginia). It covers visitor and contact data collected by the Messenger, all conversation data, and custom data attributes and events. (intercom.com)

The commercial gate

The first trap is commercial, not technical. Regional hosting is only available on Advanced and Expert annual plans, and only through Intercom's sales team. You cannot enable it from the billing page. You cannot get it on a monthly plan.

If you're on the Essential plan — where most startups and small teams land — you cannot get EU data hosting at all. Moving to Advanced nearly triples your per-seat cost. For a 10-person support team, that's roughly ~$3,480/year versus ~$10,200/year before AI resolution fees or add-ons.

Intercom's Early Stage program (up to 90% off for qualifying startups) does not include regional data hosting either. The very companies most likely to be building for a European audience from day one are locked out of EU hosting until they can afford Advanced-tier pricing. (intercom.com)

The architectural trap

The second trap is architectural. Intercom's sales team provisions a new regional workspace that exists independently from your US workspace. You cannot toggle between them. Every Messenger install, API client, webhook, and mobile SDK region setting has to be repointed at the EU stack during cutover. (intercom.com)

// Default US snippet
window.intercomSettings = {
  app_id: 'YOUR_WORKSPACE_ID',
  api_base: 'https://api-iam.intercom.io'
}
 
// EU-hosted workspace
window.intercomSettings = {
  app_id: 'YOUR_WORKSPACE_ID',
  api_base: 'https://api-iam.eu.intercom.io'
}

The REST API follows the same pattern — EU workspaces use https://api.eu.intercom.io/ instead of https://api.intercom.io/. (developers.intercom.com)

If you build private apps, there's another catch: developer workspaces are not supported in EU data hosting. They're provisioned in the US and synced to EU or AU. For EU private-app work, Intercom recommends using a paid regional workspace or manually copying settings from a US dev workspace. This immediately complicates data residency for engineering teams building custom integrations. (intercom.com)

Why US-to-EU Migration Is a Full Restart

Intercom's official position is blunt: direct migration of existing workspace data from one region to another is not possible. The documented path is to create a new workspace in the desired region and manually transfer data and settings. Intercom does not offer app-to-app migration — you rely on export/import methods plus manual recreation for everything else. (intercom.com)

What you can move (with significant effort)

• Contacts and companies: Exportable via CSV or the Contacts API. Re-importable via CSV upload or API scripting.
• Custom data attributes: Must be recreated in the new workspace, then values re-applied to contacts.
• Events: Exportable via the Events API, but must be replayed into the new workspace. Note that Intercom's GDPR export covers only the last 90 days of events. (intercom.com)
• Help Center articles: Migratable via the Articles API, but with a critical gotcha (see below).
• Tags: Must be recreated manually or via API.

What you lose

This is where the "migration" feels more like an amputation:

• Conversation history: Intercom says conversation data can be exported via the Conversations API or as CSV from the Reports UI, but there is no way to import a conversation and all its related data into a new workspace. Years of customer interactions, internal notes, CSAT ratings, and conversation metadata are gone from the live system. (intercom.com)
• Series and automated workflows: Manual recreation only. No export capability.
• Product Tours: Manual recreation only.
• Bots and custom bot flows: Manual recreation only.
• Inbox settings, macros, and assignment rules: Manual recreation only.
• Reports and saved views: Manual recreation only.
• Outbound messages and campaigns: Manual recreation only.

Intercom's community forums confirm this is a persistent pain point. An Intercom staff member acknowledged in the community that while the team was working on a solution, "it won't be a fully automated process, and you will still need to recreate/reconfigure certain Intercom features, such as Series, Messages, Product Tours, Reports, etc." As of May 2025, community replies were still pointing users to third parties because no official US-to-EU migration tool existed. (intercom.com)

One easy doc-reading mistake: another Intercom help article says existing EU customers that were previously using US data processing for certain AI features will be automatically transitioned to EU-hosted infrastructure. That does not create a migration path for customers whose workspace itself is US-hosted at app.intercom.com. Those are separate situations. (intercom.com)

Unsupported integrations in EU workspaces

The region move isn't just a data copy — it can also be an integration redesign. Intercom's current unsupported-app list for EU and AU regional workspaces includes Mailchimp sync, Marketo, Mixpanel, Pipedrive, WordPress, and Zoom webinars. The Intercom MCP server and ChatGPT connector are also listed as available in the US but not Europe or Australia. If your current workspace relies on any of these, you need a plan beyond just moving data. (intercom.com)

The Help Center image trap

A subtle but painful edge case: when you export articles from a US workspace using the Articles API, all embedded images have URLs that reference the US workspace's internal storage. When you create those articles in the new EU workspace, Intercom sees the URLs are already "ingested" and doesn't re-upload them. The result: all article images still point to the old US workspace. The moment you delete that workspace, every image in your Help Center breaks.

The workaround: download every image, re-host it temporarily (S3, Google Drive, etc.), replace the URLs in the article HTML, then create the articles in the EU workspace with the new URLs. Nobody tells you this upfront.

What Data Still Leaves the EU?

Even after you've set up a new EU workspace and accepted the loss of your live conversation history, not all data actually stays in Europe. EU hosting is not the same as EU-only processing. Intercom's Regional Data Hosting Addendum lists several categories of data that are transferred to and processed in the US:

Intercom also tells customers to test any third-party app that installs the Messenger into a regional workspace and says it cannot guarantee all third-party apps will work with regional hosting. Code-less installs through tools like Google Tag Manager and Segment require passing the correct regional parameter. Your compliance story depends partly on how your surrounding integrations are wired, not just where Intercom stores the primary records. (intercom.com)

Intercom's Regional Data Hosting Addendum also says support is global, with EU-based teams handling the majority of issues during EU business hours, while exceptional out-of-region access follows the addendum process.

The email routing question

This is the point that catches most DPOs off guard. Intercom's documentation explicitly states that inbound and outbound emails for Australian workspaces route through US infrastructure. Whether the same blanket constraint applies to EU workspaces is less clearly documented — the current EU section of Intercom's regional hosting article does not make the same statement. (intercom.com)

If email-path locality is a hard requirement for your DPO, do not rely on assumptions, secondhand reports, or older screenshots. Ask Intercom to confirm the current behavior for your exact channels in writing before renewal.

Intercom vs EU-Friendlier Alternatives

When faced with deleting years of conversation history for partial data residency, many teams use the event as a catalyst to evaluate the wider market. If you have to start from scratch, you might as well start on a platform that fits your compliance requirements out of the box.

Zendesk

Zendesk offers a Data Center Location add-on included free of charge on Suite Professional plans and above. It's not automatically activated — you contact support — but the approach is fundamentally different from Intercom's. Zendesk can migrate existing covered service data to the chosen region, then delete the former-region copy under its deletion policy. You don't start a new account and rebuild from zero. (support.zendesk.com)

Zendesk has its own caveats. Its regional-hosting policy says processing can still happen outside the chosen region as reasonably necessary to provide the service. Email campaign data is hosted by SendGrid in the US, and older Messaging/Sunshine Conversations accounts created before April 2023 can't be moved. But for core ticketing, help center, and chat data, Zendesk will actually migrate your existing account rather than making you start over.

If Zendesk is on your shortlist, see How to Migrate from Intercom to Zendesk (Step-by-Step). For a deeper look at the platform itself, read The Ultimate Zendesk Guide.

European-native platforms

Platforms like Trengo (headquartered in the Netherlands) offer EU data hosting as a default, not a premium upsell. HelpSpot runs its EU Cloud on dedicated servers in AWS Frankfurt with EU-only backups, no extra cost, and migration help at no additional charge. (helpspot.com)

If your main requirement is straightforward EU-hosted support with a simpler residency story, these platforms offer a notably more direct path than Intercom's gated model. The feature-fit question is separate and should be evaluated against your Messenger, automation, and outbound needs. We cover the architectural differences in The Complete Guide to Migrating from Intercom to Trengo.

Comparison matrix

How to Migrate Your Intercom Data Without Losing History

Intercom's official process accepts conversation data loss as a given. But the data isn't gone — it's accessible via the API. The question is where you put it and what fidelity you need.

Decide what "preserve history" actually means

There are three workable end states:

• Compliance archive: Export everything into a queryable store outside Intercom — PostgreSQL, a data warehouse, or an S3 bucket with JSON files. Agents lose inline access within Intercom's UI but you satisfy audit and retention requirements.
• Reconstructed history in a new EU Intercom workspace: Good for agent context. Not a 1:1 workspace clone, but agents can look up past conversations.
• Migration to another help desk: Best when data residency is only one part of a bigger platform change.

The mistake is trying to force all three goals into one build. If you need regulatory-grade fidelity, keep an archive. If you need agent usability, reconstruct only what needs to be live. If you need both, run both tracks.

Extract more than CSVs

Intercom's CSV exports are not backups. CSV exports do not include conversation message content — they're primarily metadata and reporting oriented. Browser CSV downloads are limited to 10,000 rows before larger exports are emailed. User CSVs only include the name and ID of the most recent company, not full company data. (intercom.com)

For evidence-grade extraction, you need a layered approach:

• Contacts, companies, tags, and custom attributes via the API. Intercom's Data Attributes API covers custom contact and company attributes. (developers.intercom.com)
• Conversation bodies and attachments via the Conversations API or cloud export. Intercom's cloud export can send JSON/JSONL plus attachments to S3 or GCS, but the historical export window is up to two years. (intercom.com)
• Long-thread handling via special logic. The conversation retrieve endpoint has a hard limit of 500 parts, returning only the 500 most recent parts when the thread is longer. (developers.intercom.com)

Import in the right order

Intercom's own historical-migration guide specifies the import sequence: contacts first, then custom data attributes, then conversations or tickets. Every conversation must be linked to an existing contact — trying to create conversations before the associated contacts exist will fail. (intercom.com)

If the destination is a new EU Intercom workspace, use EU endpoints everywhere. Intercom's create-conversation endpoint supports a created_at field specifically for migrating past conversations, letting you preserve original dates even though you're reconstructing the history. (developers.intercom.com)

Choose transcript fidelity deliberately

Intercom's own migration guide makes a useful distinction: if the goal is reporting continuity, migrate historical data in its simplest form. If the goal is agent context, message-by-message migration may be justified — but Intercom warns this increases API volume by 10x to 100x. Their guide even suggests posting the full transcript as a single reply body instead of replaying every individual message when simpler is sufficient. (intercom.com)

This is where many DIY scripts break. A successful import can still be bad if it spams customers, breaks timestamps, or creates unreadable transcripts. Intercom warns that creating email-channel conversations and replying in a live workspace can trigger customer notifications unless email notifications are explicitly suppressed or the workspace isn't live during migration.

Work within the platform limits

Intercom's default REST rate limits are 10,000 API calls per minute per app and 25,000 per minute per workspace, distributed into 10-second windows. That's high on paper, but large historical replays still need queueing, backoff, and idempotency — especially when you're multiplying calls across contact creation, attribute creation, conversation creation, replies, attachments, and tagging. (developers.intercom.com)

A workspace with 100,000 conversations, each requiring a GET request plus pagination for parts, can take 24–48 hours of continuous API work just for the extraction phase. Budget the time accordingly.

If you're migrating to a different platform (Zendesk, Freshdesk, Help Scout, Front), you're also translating Intercom's conversation-centric model (contacts → conversations → conversation_parts) into that platform's ticket-centric model (requesters → tickets → comments). You'll need to handle:

• Mapping Intercom admin IDs to target-platform agent IDs
• Downloading and re-uploading all attachments (Intercom attachment URLs expire)
• Respecting the target platform's API rate limits during import
• Preserving original timestamps for reporting continuity

You also need a non-API plan for what Intercom says will not transfer cleanly: active conversations, workflows, Series, bots, Macros, Inbox settings, certain outbound assets, and unsupported apps. Document these objects before you start and rebuild them intentionally instead of discovering gaps on go-live day.

Cut over with deltas and QA

Intercom's migration guide describes the right pattern: run an initial migration for older closed items, set a delta date, then do a final cutover and delta pass for conversations changed since that point. After the move, validate user mappings, conversation history, and organization data before declaring success. That's the part teams rush, and it's where silent data loss usually hides. (intercom.com)

In our own migration work at ClonePartner, the safest projects split into two tracks: a forensic extraction track that preserves everything you may need later, and a live-system reconstruction track that gives agents the right context in the new platform. That's how you avoid the false choice between losing history and freezing support for weeks.

Before extracting anything, run through our Intercom Migration Checklist to audit your current workspace and identify which custom attributes, tags, and configuration items are worth keeping. For a broader look at how we approach these projects, see How We Run Migrations at ClonePartner.

What to Do Right Now If You're on US Hosting

If you're an existing Intercom customer on US servers and you need EU data hosting, here's the honest decision framework:

1. Audit your actual compliance requirement. GDPR does not strictly mandate EU-based data storage — it requires adequate protections for data transfers. Intercom relies on Standard Contractual Clauses (SCCs) in its DPA for cross-border transfers. For some organizations, that's sufficient. For others — especially those in regulated industries or with strict internal policies — data residency in the EU is non-negotiable.

2. Calculate the real cost of staying on Intercom. Factor in the plan upgrade to Advanced or Expert (annual commitment), the engineering time to rebuild your workspace from scratch, the loss of historical conversation data in the live system, and any ongoing limitations around data routing or unsupported integrations.

3. Evaluate whether a platform switch is cheaper. If you're going to lose your conversation history anyway and rebuild from scratch, it's worth evaluating whether a different platform gives you better data residency out of the box at a lower total cost.

4. Don't delete your US workspace prematurely. Keep it active — even in a reduced state — until you've verified that all data has been extracted, archived, and successfully imported into your target. Once it's gone, it's gone. Intercom processes workspace deletion immediately and irreversibly.

The uncomfortable truth is simple: Intercom EU data hosting is a migration project disguised as a compliance setting. The least risky path is to preserve a complete archive of the US workspace, rebuild only the live history and configuration you actually need in the new system, and test every integration before cutover. If the platform fit still makes sense after that, move to a new EU Intercom workspace with eyes open. If it doesn't, use the same extraction effort to move to a vendor with a cleaner residency model.