---
title: How to Migrate an Intercom Workspace from the US to the EU
slug: how-to-migrate-an-intercom-workspace-from-the-us-to-the-eu
date: 2026-10-20
author: Abdul Aleem
categories: [Intercom, Migration Guide]
excerpt: "Intercom has no US-to-EU region toggle. Learn the step-by-step process to create a new EU workspace, migrate data via API, and repoint your SDKs."
tldr: "Intercom cannot move workspace data between regions. You must provision a new EU workspace, migrate structured data via API, manually rebuild all configuration, and accept that conversation history cannot be imported."
canonical: https://clonepartner.com/blog/how-to-migrate-an-intercom-workspace-from-the-us-to-the-eu
---

# How to Migrate an Intercom Workspace from the US to the EU


# How to Migrate an Intercom Workspace from the US to the EU

Intercom has no toggle, button, or built-in tool to move an existing workspace from the US data region to the EU data region. Direct migration of existing workspace data from one region to another is not possible — you must create a new workspace in your desired region and manually transfer your data and settings.

This guide covers the full technical execution: the API constraints, the exact sequence of operations, the error modes that break integrations during cutover, and what you can realistically expect on the other side.

For the strategic picture — why Intercom's EU hosting works this way and when to consider leaving Intercom entirely — see our deep dive on [the Intercom EU data hosting trap](https://clonepartner.com/blog/blog/intercom-eu-data-hosting-trap-the-us-to-eu-migration-guide).

> [!NOTE]
> **Conflict of interest disclosure:** ClonePartner runs paid data migrations. We have a financial interest in you considering expert help. The technical facts in this article are sourced to primary documentation and are independently verifiable.

> [!NOTE]
> **A note on naming:** Intercom rebranded to Fin in May 2026, and Salesforce completed its acquisition of Fin — the customer-service AI company formerly known as Intercom — for roughly $3.6B, folding Fin's technology into Agentforce. The product, workspace UI, and API endpoints still use the Intercom name at the time of writing. This guide uses "Intercom" throughout because that is what appears in the documentation, the API base URLs, and the search queries that bring you here.

## Why there is no US-to-EU region switch

**Intercom Regional Data Hosting** pins workspace data to a specific AWS region at creation time. Intercom lets customers host workspace data in AWS `eu-west-1` (Dublin, Ireland) instead of the default `us-east-1` (North Virginia). The workspace region is permanent and cannot be changed after provisioning.

A US-to-EU move is not a migration within Intercom — it is a teardown-and-rebuild. Your region-specific workspace exists independently from your US-based workspace, which means you cannot toggle between workspaces. The new EU workspace gets its own workspace ID, its own API keys, its own Messenger configuration, and its own empty data store. From Intercom's system perspective, this is a new customer signup. Your old US workspace and your new EU workspace share no underlying database infrastructure, making the project architecturally identical to [migrating from HubSpot to Intercom](https://clonepartner.com/blog/blog/hubspot-to-intercom-migration-the-ctos-technical-guide) or [migrating from Intercom to Front](https://clonepartner.com/blog/blog/intercom-to-front-migration-the-complete-technical-guide).

## What does Intercom EU data hosting actually cover?

**Intercom EU hosting** stores core customer data — contacts, conversations, events, custom attributes, and Help Center articles — in AWS `eu-west-1` (Dublin). But EU-hosted does not mean EU-only processing in every subsystem. Several data categories still cross the Atlantic:

- For EU workspaces, data required for billing and support processes may be transferred outside of your region, including your name, email, and credit card data (billing occurs in the US).
- Your workspace admin data is used for providing customer support. Metadata associated with usage (features used, types of messages sent, etc.) is also transferred to US systems.
- Fin AI model inference relies on US sub-processors such as OpenAI and Anthropic, so a transfer impact assessment for the model-inference path is still required even when data is stored in the EU.
- Any data flowing to or from external systems (Facebook, Twitter, Salesforce, etc.) may leave your region once it exits the Intercom system.

**Compliance implications:** EU hosting is a strong starting position, not a complete answer. Your GDPR compliance posture must additionally address:

- **Data Processing Agreement (DPA):** When your workspace region changes, your DPA with Intercom must be updated to reflect the new processing arrangement. The DPA governs how Intercom processes data on your behalf and must accurately describe the sub-processors and transfer mechanisms in use.
- **Standard Contractual Clauses (SCCs):** Even with EU hosting, data flows to US sub-processors (OpenAI, Anthropic, billing systems) require valid SCCs or another Article 46 transfer mechanism. Verify these are in place for each sub-processor before cutover.
- **Transfer Impact Assessments (TIAs):** For AI inference paths specifically, document why the transfer is necessary and what safeguards apply.

EU hosting alone does not satisfy GDPR if these supplementary mechanisms are not in place.

## What can be migrated between Intercom workspaces?

Not everything survives the move. Here is the breakdown based on Intercom's current API surface:

| Data type | Migratable? | Notes |
|---|---|---|
| Contacts (users, leads) | ✅ Yes | CSV import or Contacts API. Match on `external_id` or `email`. |
| Companies | ✅ Yes (API only) | CSV import does not support company data. Use the Companies API. |
| Custom data attributes | ✅ Yes | Create attribute definitions first, then populate values. |
| Tags | ✅ Yes | Create tags, then apply to contacts/companies. |
| Events | ✅ Yes | Events API. Linked to contacts by `user_id`. |
| Help Center articles | ✅ Yes (with scripting) | No UI copy path. Use the Articles API. |
| Conversation history | ❌ Export only | Cannot be imported into a new workspace. Archive for compliance. |
| Series & workflows | ❌ Manual rebuild | No export or import capability. |
| Bots & Fin AI config | ❌ Manual rebuild | Rebuilt in the visual builder. |
| Macros / saved replies | ❌ Manual rebuild | No API import path. |
| Outbound messages | ❌ Manual rebuild | Recreated from scratch. |
| Reports | ❌ Manual rebuild | Cannot be copied across workspaces. |
| CSAT responses | ❌ Lost | Historical satisfaction data is not importable. |
| SLA policy history | ❌ Lost | SLA tracking starts fresh in the new workspace. |
| SSO/SAML configuration | ❌ Manual rebuild | Identity provider settings must be reconfigured in the EU workspace. |
| Custom email domain (SPF/DKIM) | ❌ Manual re-verification | DNS records must be re-verified in the EU workspace before cutover. |
| Messenger Identity Verification secret | ❌ New secret issued | The `identity_secret` changes between workspaces; update all backend signing logic. |

Intercom does not offer migration options from one workspace to another. Conversation data can be exported using 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.

> [!WARNING]
> **Do not plan around live conversation history inside the new EU workspace.** Your options are: archive to external storage (S3, data warehouse), build an internal lookup tool for agents, or accept the fresh start. If searchable historical conversations inside the live tool are a hard requirement, Intercom's native US-to-EU path does not meet it — at that point you are deciding whether archive-only history is acceptable or whether the requirement points to a broader platform migration.

## Step-by-step: executing the US-to-EU workspace migration

### Step 1 — Audit your US workspace

Before touching the EU workspace, inventory what you have. Count contacts, companies, conversations, articles, tags, custom attributes, active Series, bots, and integrations. Include SSO configuration, custom email domains, and Messenger Identity Verification in your audit. This scoping determines the migration effort and surfaces data you may want to archive rather than move. Our [Intercom migration checklist](https://clonepartner.com/blog/blog/intercom-migration-checklist) covers this in detail.

### Step 2 — Provision the EU workspace

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. Once provisioned, your EU workspace lives at `app.eu.intercom.com` with API access at `api.eu.intercom.io`.

> [!WARNING]
> Developer workspaces are not supported in EU data hosted workspaces. If you build private apps that depend on a dev workspace for testing, you will need a workaround — typically a sandbox within a paid EU workspace.

### Step 3 — Freeze your identifier strategy

**Identifier strategy** is the rule Intercom uses to decide whether a record is an update or a duplicate. Intercom matches contacts in order: Intercom ID → `user_id` → email. The sharp edge is CSV import: if an existing contact has no `user_id`, but your import file includes both email and `user_id`, Intercom will not fall back to email matching — it creates a new contact. Backfill stable `user_id` values first, and make sure Messenger, CSV imports, API scripts, and any CDP all use the same identifiers.

If you use companies heavily, do not rely on the user export alone to rebuild relationships. Intercom's user export only includes the name and ID of the most recent company on a user record. Export company data separately, decide the definitive `company_id` up front, and recreate company associations through the API where users belong to multiple companies. `company_id` cannot be changed after creation, and a company only becomes visible in Intercom after it has at least one associated user.

Because both workspaces are completely isolated, every entity receives a new internal Intercom `id`. If your backend stores Intercom's internal IDs to trigger events or look up users, those IDs become invalid. Update your application logic to reference the new workspace's IDs, or — better — rely exclusively on your own `external_id`.

**Messenger Identity Verification:** The `identity_secret` used to generate HMAC signatures for Messenger identity verification changes when you create the EU workspace. Any backend code that signs user identities for Intercom must be updated to use the new secret before the EU Messenger goes live. If you deploy the EU Messenger before updating the secret, authenticated users will see an identity verification failure and may be treated as anonymous visitors.

### Step 4 — Recreate workspace configuration

This is the labor-intensive phase that no API can automate. Rebuild in the EU workspace:

- **Teams, teammates, and roles** — invite all agents, assign roles
- **Inbox settings** — routing rules, assignment logic, office hours
- **Messenger customization** — branding, launcher behavior, home screen
- **Workflows and bots** — every automation, from scratch
- **Series** — every outbound sequence, rebuilt manually
- **Macros and saved replies** — re-entered one by one
- **Fin AI configuration** — knowledge sources, tone settings, custom answers
- **SLA policies and business hours** — configured fresh
- **Reports** — cannot be copied across workspaces
- **SSO/SAML configuration** — re-enter your identity provider settings (entity ID, certificate, ACS URL) in the EU workspace and update your IdP (Okta, Azure AD, Google Workspace) with the new Intercom SP metadata
- **Custom email domain (SPF/DKIM)** — re-verify your sending domain in the EU workspace settings; Intercom will issue new DKIM keys that must be published in DNS before the EU workspace can send authenticated email

Budget significant time here. This is the workspace rebuild clock, separate from the data migration.

### Step 5 — Extract data from the US workspace

Use the REST API at `api.intercom.io` (US base URL) to export:

- **Contacts and companies** — `GET /contacts` (cursor-based pagination, 150 per page max)
- **Tags** — `GET /tags`
- **Custom data attributes** — `GET /data_attributes`
- **Events** — `GET /events` (scoped per contact)
- **Articles** — `GET /articles`
- **Conversations** — `GET /conversations/{id}` for full conversation parts (archive only)

**Rate limits and throughput math:** Private apps have a default rate limit of 10,000 API calls per minute per app and 25,000 API calls per minute per workspace. Intercom distributes this limit into 10-second windows, so the real burst ceiling is approximately 1,667 calls per 10-second window. Your script must monitor the `X-RateLimit-Remaining` response header and implement exponential backoff on `429 Too Many Requests` responses.

To make this concrete: at a sustained ceiling of 10,000 calls/minute and one API call per contact (ignoring pagination overhead), you could theoretically process 10,000 × 60 × 24 = 14.4 million contact reads per day. In practice, overhead from pagination, event retrieval per contact, error retries, and the one-at-a-time contact creation constraint on the write side reduce effective throughput significantly. For a dataset of 50,000 contacts with attributes and tags, plan for 2–4 hours of extraction time and a comparable write window.

**Error modes to handle during extraction:**

| HTTP status | Cause | Handling |
|---|---|---|
| `429 Too Many Requests` | Rate limit exceeded | Exponential backoff; read `Retry-After` header |
| `401 Unauthorized` | Invalid or expired API key | Verify key; US and EU workspaces have separate keys |
| `403 Forbidden` | Region mismatch (calling US endpoint with EU key, or vice versa) | Check base URL matches workspace region |
| `404 Not Found` | Contact or conversation deleted between list and retrieve calls | Skip and log; do not abort batch |
| `500 / 503` | Intercom server error | Retry with backoff; log for later review |

User-uploaded files in conversations return signed URLs that expire after 30 minutes — you must download attachments immediately after fetching each conversation, not in a separate pass.

For conversation export, you need two calls per conversation: one to list, one to retrieve full parts. Conversation parts are not returned when listing or searching conversations — only on single conversation retrieval. There is a hard limit of 500 parts per conversation with no pagination within a single conversation. Conversation data older than two years cannot be exported through the workspace UI and requires the API.

For a complete walkthrough on extraction methods, see our guide on [how to export data from Intercom](https://clonepartner.com/blog/blog/how-to-export-data-from-intercom-methods-api-limits-transcripts).

### Step 6 — Load data into the EU workspace

Point your scripts at `api.eu.intercom.io` and create records in dependency order:

1. **Custom data attributes** — define schemas first. If you attempt to push a contact record containing a custom attribute that does not exist in the EU workspace, the API will reject the payload or silently drop the attribute. Silent drops produce no error in the response — the contact is created but the attribute value is absent. Validate by reading back a sample of created contacts and comparing attribute counts.
2. **Companies** — `POST /companies`. Store a mapping of old Company IDs to new Company IDs.
3. **Contacts** — `POST /contacts`. There is no bulk create endpoint for contacts — contacts must be created individually via `POST /contacts` with rate-limit handling. Include company associations referencing the newly created Company IDs.
4. **Tags** — `POST /tags`, then apply to contacts and companies.
5. **Events** — `POST /events` (linked to contacts by `user_id` or `email`).
6. **Articles** — `POST /articles`.

> [!TIP]
> Match contacts between workspaces using `external_id` or `email` as the deduplication key — not Intercom's internal `id`, which will differ between workspaces.

**Help Center image handling:** When you extract an article from the US workspace, the `body` field contains HTML. If that article includes images uploaded to Intercom, the `src` attributes point to CDN URLs tied to your US workspace. If you push this HTML to the EU workspace unchanged, the images will render correctly at first — but the moment you decommission your US workspace, those CDN links will 404, leaving your EU Help Center full of broken images.

Your script must parse the HTML, download the image binaries, upload them to the new EU workspace, capture the new CDN URLs, and rewrite the `src` attributes before creating the article. Also test formatting early: article bodies are HTML-driven, and Intercom normalizes heading levels and strips unsupported tags or attributes.

**Detecting silent attribute drops:** After loading a batch of contacts, sample 5–10% by calling `GET /contacts/{id}` and comparing the returned attribute set against your source data. A discrepancy indicates either a missing attribute definition or a type mismatch (e.g., sending a string value into an integer attribute field).

### Step 7 — Repoint Messenger, SDKs, and API integrations

Every touchpoint that talks to your Intercom workspace must switch to the EU endpoint. Miss one, and data flows to the wrong workspace.

**Web Messenger snippet:**

```javascript
// US workspace (before)
window.intercomSettings = {
  app_id: 'YOUR_US_WORKSPACE_ID',
  api_base: 'https://api-iam.intercom.io'
};

// EU workspace (after)
window.intercomSettings = {
  app_id: 'YOUR_EU_WORKSPACE_ID',
  api_base: 'https://api-iam.eu.intercom.io'
};
```

**iOS (Info.plist) — verify against the current Intercom iOS SDK release for your version:**

```xml
<key>IntercomEURegion</key>
<true/>
```

**Android — verify against the current Intercom Android SDK release for your version:**

Set `io.intercom.android.sdk.server.region` to `@integer/intercom_server_region_eu` in your configuration.

**React Native (Expo) — verify plugin version compatibility before upgrading:**

```json
{
  "expo": {
    "plugins": [
      ["@intercom/intercom-react-native", { "intercomRegion": "EU" }]
    ]
  }
}
```

> [!WARNING]
> SDK configuration keys and plugin parameters change between major SDK versions. The examples above reflect configuration patterns as of mid-2025. Verify against the current Intercom developer documentation before applying to production.

**Backend API calls:** replace `api.intercom.io` with `api.eu.intercom.io` in every service that reads or writes Intercom data.

Rebuild your mobile apps after making SDK changes. Make sure to select the correct data hosting region on the login page — signing in via the wrong region will not find your workspace, even if your subscription is active. A region mismatch on API calls returns `HTTP 403 Forbidden`.

The non-obvious changes that teams miss:

- **Code-less Messenger installs:** GTM and Segment need the correct `api_base` or they keep installing the Messenger against the US region.
- **Messenger Identity Verification secret:** The `identity_secret` for HMAC signature generation changes in the EU workspace. Update your backend signing code before deploying the EU Messenger to production users.
- **Help Center domains:** EU-hosted Help Centers use EU-specific hostnames such as `eu.intercomhelpcenter.com` for quick setup or `custom.eu.intercom.help` for manual CNAME routing. If you rely on logged-in recognition or article audience targeting, your app and Help Center must share a top-level domain.
- **Custom email domain (SPF/DKIM):** Re-verify your sending domain in the EU workspace. Intercom issues new DKIM public keys for each workspace; you must publish these in DNS and allow propagation time (typically 24–48 hours) before enabling the EU workspace for email sending.
- **Email asset domains:** Custom link-branding and email-asset domains point to EU hosts ending in `intercom-mail.eu`, not the default US host.
- **SSO/SAML:** Update your identity provider's Service Provider configuration with the EU workspace entity ID and ACS URL. Until this is done, SSO login will fail for all teammates.
- **Security allowlists:** If your firewall allowlists Intercom outbound traffic, switch to the EU IP file and use only ranges tagged `INTERCOM-OUTBOUND`. The published list is region-specific.
- **Webhook secrets:** The EU workspace provides a new client secret. Update your backend services to verify inbound webhook signatures using the new secret before enabling webhooks in the EU workspace.

### Step 8 — Manage the cutover window (parallel operation)

The period between provisioning the EU workspace and fully decommissioning the US workspace is the highest-risk phase. During this window, writes can arrive at both workspaces, creating divergence.

**The core problem:** If your application sends events or contact updates to the US workspace during parallel operation, those writes will not appear in the EU workspace. Similarly, any support conversations opened in the US workspace after you begin cutover will not be in your EU inbox.

**Strategies to manage this:**

- **Hard cutover (recommended for most teams):** Pick a cutover timestamp. At T=0, simultaneously deploy the EU `api_base` and `app_id` across all surfaces (web snippet, mobile SDK, backend API calls, Segment/GTM). Accept that any writes between your last US extraction and T=0 will not be in the EU workspace. Plan a final extraction pass as close to T=0 as operationally possible.
- **Dual-write (for teams with strict consistency requirements):** During the parallel window, write to both workspaces from your backend. This requires your application to resolve conflicts (e.g., a contact attribute updated in both workspaces with different values). Dual-write is operationally complex and should only be used if a hard cutover creates unacceptable business risk.
- **Freeze writes before cutover:** If feasible, put your application into a read-only or maintenance state for 15–30 minutes before cutover, perform a final incremental extraction from the US workspace, load the delta into the EU workspace, then cut over. This minimizes divergence to near-zero at the cost of planned downtime.

Document the cutover timestamp precisely. This timestamp marks when EU data becomes the system of record and is the reference point for any post-migration data reconciliation.

**Rollback plan:** If validation in Step 9 reveals critical failures in the EU workspace after cutover, your rollback path is to revert all `api_base` and `app_id` values to the US workspace and redeploy. Because the US workspace has not been decommissioned yet, it remains live and will resume receiving writes. Any data written to the EU workspace during the failed cutover will not be reflected in the US workspace — this delta must be reconciled manually. Define your rollback decision criteria before cutover (e.g., "if X% of webhook deliveries fail within 30 minutes, roll back") so the decision is not made under pressure.

### Step 9 — Validate before going live

Before cutting over production traffic:

- Verify contact and company record counts match between source and target (allow for records created or deleted during the migration window)
- Spot-check custom attribute values on a random sample of at least 50 contacts across different contact types
- Compare attribute counts on sampled contacts to detect silent drops
- Confirm article content renders correctly in the EU Help Center — specifically check images and heading formatting
- Test Messenger behavior on web, iOS, and Android using test accounts
- Verify webhook deliveries from the new workspace reach your backend using the new client secret
- Confirm SSO login works for at least one teammate before inviting the full team
- Send a test email from the EU workspace and verify DKIM authentication passes (check email headers for `dkim=pass`)
- Confirm all recreated workflows trigger as expected on test contacts
- Check that data loaded via CSV or API is not being overwritten by your application sending stale values
- Verify the Messenger Identity Verification signature validates correctly for authenticated users

### Step 10 — Cut over and decommission the US workspace

Once validated, point all production traffic to the EU workspace. Before cancelling, export any historical conversation data you want to retain — this data cannot be transferred and will be lost once the workspace is closed.

Keep the US workspace active for at least 30 days post-cutover as a backstop. Decommission only after you have confirmed that no production traffic is reaching it and that all archived data has been saved to external storage.

## What happens to your conversation history?

**Intercom does not support importing conversation history into a new workspace.** Historical conversation data cannot be migrated to the new workspace. It can only be exported for record-keeping before you decommission your old workspace.

Your options:

- **Archive to external storage** — export conversations as JSON via the REST API and store in S3, a data warehouse, or a searchable archive. This preserves data for compliance and agent reference, but it will not appear in the Intercom inbox.
- **Build a lookup tool** — some teams create an internal app that lets agents search archived conversations by customer email or ID, displayed alongside the Intercom inbox.
- **Accept the fresh start** — if your team rarely references conversations older than a few months, the operational impact may be manageable.

One critical caveat: Intercom's built-in export tools silently drop conversation message content. The REST API is the only reliable path to full conversation bodies. Use API-based retrieval rather than the CSV export from the Reports UI or the S3 JSON export if you need actual transcripts.

## Which integrations break in the EU workspace?

Not every integration is available in the EU region. The following apps are not currently supported on EU workspaces:

- Mailchimp (import, subscribe, sync)
- Marketo (and Marketo unsubscribe)
- Microsoft Teams
- Mixpanel
- Outlook Calendar
- Pipedrive
- Trello
- WordPress
- Zoom Webinars
- Campaign Monitor
- Clearbit Reveal

All third-party apps are available through the app store, but you should test any app with your regional workspace before relying on it — not all apps are guaranteed to support regional data hosting. Intercom-built apps are progressively being added to regional workspaces.

If any of these are in your current workflow, plan replacements before cutover.

## How long does an Intercom US-to-EU migration take?

**Two separate clocks apply**, and confusing them is the most common planning mistake.

**Clock 1 — Data migration:** extracting contacts, companies, tags, attributes, events, and articles from the US workspace and loading them into the EU workspace.

To estimate your timeline, work from the rate limit math:

- Sustained API ceiling: 10,000 calls/minute = ~167 calls/second
- Contact creation: one `POST /contacts` call per contact (no bulk endpoint)
- At ceiling with no overhead: 10,000 contacts/minute → 600,000 contacts/hour
- Realistic throughput (accounting for pagination, retries, event loading, and I/O): approximately 20–30% of theoretical ceiling
- Practical estimate: ~120,000–180,000 contact creates per hour under normal conditions

For a dataset of 50,000 contacts with custom attributes, events, and company associations, plan for 4–8 hours of write time. A dataset of 500,000 contacts with full event history may take 2–4 days. Article migration time is negligible compared to contact volume.

**Clock 2 — Workspace rebuild:** recreating workflows, bots, Series, Messenger configuration, SSO, email domains, and team setup. This effort scales with configuration complexity, not data volume. A heavily automated workspace with 50+ workflows, custom bots, and complex Series could take 2–4 weeks to rebuild and test. We recommend starting the full scoping process at least 3–4 months before any internal compliance deadline.

For a deeper look at how data residency requirements affect migration planning, see our [GDPR-compliant data migration blueprint](https://clonepartner.com/blog/blog/gdpr-compliant-data-migration-the-enterprise-blueprint).

## What teams usually miss

The breakages come from configuration drift, not from the raw data export. The repeat offenders:

- **Identifier mismatches** that create duplicate contacts in the EU workspace — especially CSV imports where `user_id` is present in the file but not on existing records
- **Code-less Messenger installs** (GTM, Segment) still pointing at the US `api_base`
- **Messenger Identity Verification secret** not updated in backend signing logic, causing authenticated users to fail identity verification
- **Help Center or email CNAMEs** still using US hosts
- **Custom email domain SPF/DKIM** not re-verified, causing outbound emails from the EU workspace to fail authentication or land in spam
- **SSO/SAML configuration** not updated in the identity provider, blocking all teammate logins
- **Reports and workflows** nobody rebuilt because they were not in the data migration scope
- **Security teams** still allowlisting US Intercom IPs after the switch
- **Application code** that sends stale Intercom IDs, overwriting freshly imported data
- **Help Center images** hosted on the old workspace's CDN, which 404 after decommissioning
- **DPA and SCCs** not updated to reflect the new workspace region and sub-processor list

## Planning your move

An Intercom US-to-EU migration is technically straightforward for structured data — contacts, companies, attributes, articles — but the workspace rebuild, conversation history loss, SSO reconfiguration, and email domain re-verification make it a significant project. The data migration is the smaller clock; the workspace rebuild is the larger one.

Start scoping early, export everything before you decommission, define your rollback criteria before cutover, and test the EU workspace thoroughly — including SSO, email authentication, Messenger identity verification, and webhook delivery — before pointing production traffic at it.

A successful migration ends with a live EU workspace for new operations, validated archives from the US workspace, updated DPA and SCCs, and no hidden US endpoints left in code, DNS, or identity provider configuration. That is an achievable outcome — but it is different from moving everything exactly as-is, because Intercom does not support that today.

> Need to move your Intercom workspace to the EU? Book a free 30-minute scoping call and get a fixed-price proposal for the data migration — no hourly billing, no hidden fees, no change orders.
>
> [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Can I switch my Intercom workspace from US to EU without losing data?

No. Intercom does not support region changes on existing workspaces. You must create a new EU workspace and migrate contacts, companies, tags, events, and articles via the API. Conversation history can be exported for archival but cannot be imported into the new workspace.

### Can Intercom conversation history be moved to a new EU workspace?

No. Intercom's documentation states that conversation data cannot be imported into a new workspace. You can export conversations via the REST API for record-keeping, but they will not appear in the new workspace's inbox. Intercom's built-in export tools also silently drop message content — the REST API is the only reliable path to full conversation bodies.

### How long does an Intercom US-to-EU data migration take?

The data migration itself — contacts, companies, tags, attributes, events, articles — typically completes within 1–5 business days depending on volume and API rate limits. Small datasets under 10,000 records can finish in under 24 hours. The workspace configuration rebuild (workflows, bots, Series) is a separate effort owned by your team.

### What Intercom integrations don't work in the EU workspace?

At the time of writing, Intercom's EU workspaces do not support Mailchimp, Marketo, Microsoft Teams, Mixpanel, Outlook Calendar, Pipedrive, Trello, WordPress, Zoom Webinars, Campaign Monitor, or Clearbit Reveal. Test any third-party integration in your EU workspace before relying on it.

### Does Intercom EU hosting keep all data in Europe?

No. Core customer data is stored in AWS Dublin (eu-west-1), but billing data, workspace admin data, usage metadata, and Fin AI model inference are processed outside the EU. Data sent to external integrations also leaves the region.