How to migrate from Intercom to Chatwoot without losing conversation history
Moving live chat, inbox and help center from Intercom to self-hosted Chatwoot is feasible, but full conversation history depends on the Intercom Conversations API. The CSV export carries conversation metadata without message content, and the JSON export to Amazon S3 omits transcripts, so a migration that relies on either file will leave the message history behind. The work usually falls to one of three groups: internal platform engineers who can script API pulls and run the Chatwoot server, support operations staff who own inboxes, teams, canned responses and automation rules, or an implementation partner who takes on the build under a written scope. Most teams split these roles, with engineers owning the data and infrastructure and support operations owning how agents work on day one.
Effort and risk depend on what you carry across, so size the work from your own data before you commit to a date. Chatwoot's self-hosted deployment requires Ruby 3.2 or later, recommends Node.js 20.x, supports only PostgreSQL as its database and recommends Redis 7.0 or higher. Its Chatwoot deployment requirements page lists Ubuntu 20.04 as the only officially supported Linux distribution, so confirm that choice with Chatwoot before you build. The same page recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, which is a useful first check against your own daily volume. The main risks are how attachments and contact identifiers map during import, the need to reinstall the chat widget on every page where Intercom's Messenger runs, and automation rules that may need rebuilding by hand. Ask any implementation partner to price each of those items separately in the written scope.
Start with a decision list before you touch the export. Decide which conversations are in scope (for example, closed tickets from the last year, as an illustrative cut), which contact fields and tags must carry over, and how Intercom teams, inboxes and automation rules map to Chatwoot. Then pull conversations through the Conversations API into storage you control, check a sample against the source, and load them into a staging Chatwoot instance before the production move. Plan a cutover in which Intercom and Chatwoot run side by side, switching the widget page by page and routing new conversations to one system at a time. Confirm with Chatwoot which paid features your team needs, such as custom branding or roles and permissions, because those sit in its self-hosted Premium and Enterprise plans rather than the free Community Edition.
Which Intercom capabilities map to Chatwoot and which need rework
This table maps the Intercom capabilities a support team uses day to day to their Chatwoot equivalents, based on Chatwoot's published feature list. Each row is marked clean if it can be configured directly, needs rework if it must be rebuilt or re-verified after import, or gap if it needs separate planning. The main takeaway: the inbox, teams and help center move across with configuration work, while the Fin AI agent, custom bots and integrations need their own plan.
| Intercom capability | Chatwoot equivalent and migration note | Status |
|---|---|---|
| Messenger and website chat | Website live chat widget tied to each inbox. Reinstall the widget script on every site and retest the pre-chat form. | Needs rework |
| Omnichannel inbox and channels | One inbox for website chat, email, Facebook, Instagram, WhatsApp and other listed channels. Reconnect each channel and confirm message routing. | Needs rework |
| Contacts and conversation history | Contact records and contact segments. Map custom attributes before import, and confirm imported transcripts link to the correct contact. | Needs rework |
| Teams, auto-assignment and business hours | Teams, auto-assignment by agent availability, auto-responders and business hours. Re-enter teams, schedules and time zones by hand. | Needs rework |
| Automation, canned responses and bots | Automation rules, canned responses, labels and private notes. Recreate rules from scratch and copy canned response text across. | Needs rework |
| Help center articles | Help Center portal for articles, FAQs and guides. Republish articles, rebuild collections and set redirects from old article URLs. | Needs rework |
| CSAT and reporting | CSAT plus conversation, agent, inbox and team reports. Historical Intercom metrics do not carry over, so confirm what must be archived. | Needs rework |
| Fin AI agent | Captain AI is on the paid Premium plan, listed at $19 per agent per month. Plan model hosting and knowledge sources as a separate workstream. | Gap |
| Custom integrations | Slack, Dialogflow, Shopify, Google Translate and Linear are listed. Any other Intercom app or webhook must be rebuilt and tested. | Needs rework |
What data to move and which export path carries it
Intercom's export routes do not carry the same data. Reporting exports leave out message content, and the S3 export leaves out transcripts, so the conversation history has to come through the Conversations API. Each card below names one data type, the route that carries it, and what your import script must handle before cutover.
Contacts and company records
Contacts are the identity layer for every conversation, so they should move first. Pull users and leads through the Intercom API, keep the Intercom contact ID as an external identifier, and map custom attributes to Chatwoot contact attributes before the first import. Check duplicates by email and phone, since Intercom allows records without either. The contact export is a reporting view, so confirm the fields you need are present in the API response, not only in the dashboard.
Conversations with full message history
Only the Conversations API returns full message history. CSV reports carry conversation metadata without message content, and the JSON export to Amazon S3 omits transcripts. Your extraction job must page through each conversation and store every part, including author type, timestamps and internal notes, so the history stays readable after cutover. Estimate runtime by testing on a sample, since Intercom rate limits apply to bulk pulls.
Attachments and inline files
Files shared in conversations are referenced by URL in the API response, and those links can expire or sit behind access controls. Download each file during extraction, store it in your own object storage, and record the mapping from original URL to new location. Without this step, transcripts will show broken images and documents. Confirm file size and type limits in your Chatwoot version before you plan the upload path.
Tags, labels and conversation attributes
Intercom tags and conversation attributes drive reporting and routing, so they need a defined target in Chatwoot. Chatwoot uses labels for much of this work, so map each Intercom tag to a label and decide which custom attributes become conversation or contact attributes. Create the labels in Chatwoot before the import runs, or the script will fail on the first conversation that uses them.
Teams, admins and assignment rules
Intercom teams and admin assignments do not carry over automatically. Recreate each team in Chatwoot, map every Intercom admin to a Chatwoot agent account, and decide how historical assignments are recorded. Confirm which agent roles and team settings your Chatwoot edition supports, because some role controls sit in paid self-hosted plans. Map ownership on closed conversations separately so reports stay accurate.
Help Center articles and collections
Articles and collections are a separate content stream from conversations. Export them through the Intercom Articles API, keep their ordering and collection structure, and rebuild them in the Chatwoot Help Center portal. Redirect old article URLs to the new paths so search results and links in past emails keep working. Confirm the article formats and multilingual variants you rely on before you commit to a rebuild schedule.
The migration sequence from inventory to decommission
This sequence moves an Intercom support operation to self-hosted Chatwoot in controlled stages, so each stage produces a checked artifact before the next one starts. It keeps Intercom live until the new stack has proven it can carry real traffic and history.
Inventory channels, automations and integrations
Start by listing everything Intercom does for your team: the Messenger and website widget placements, email and social channels, inboxes, teams, routing and assignment rules, auto-responders, custom bots, saved replies, tags, custom attributes, and every connected app such as Slack or Shopify. Record the owner, the traffic volume and the business purpose of each item. The output is an inventory register that maps each item to a Chatwoot equivalent, a rebuild task, or a documented decision to drop it. The step is done when the register is signed off by support operations and the security owner.
Stand up a pilot inbox on self-hosted Chatwoot
Deploy Chatwoot in your own infrastructure using the deployment method your platform team has approved, and confirm it meets the published requirements for Ruby, Node.js, PostgreSQL, Redis and host sizing for your expected conversation volume. Create one pilot inbox with a single team, the widget, and the automation rules that carry the most traffic. Confirm the instance runs backups and sits behind your standard identity and TLS controls. The output is a working pilot environment and a short configuration record that the platform team can reproduce. The step is done when a test conversation flows from widget to agent and back without manual workarounds.
Extract full conversation history through the Conversations API
Use the Intercom Conversations API to pull complete conversation records, including message content, because CSV reporting and JSON exports to Amazon S3 do not carry transcripts. Work with your developers to write the extraction job, respect Intercom's rate limits, and store raw responses unchanged in a staging area with checksums. Run the extraction in batches and keep a log of failed or partial pulls for retry. The output is a raw data set with a count reconciliation against Intercom's own reporting. The step is done when record counts match within the agreed tolerance and every exception is documented.
Load contacts and conversations into Chatwoot
Transform the raw extract into Chatwoot's data model, bringing across contacts with their identifiers and attributes, conversation threads with timestamps and assignees, and labels that still matter to reporting. Load into a non-production instance first, then check a sample of conversations by hand against the source, paying attention to attachments, private notes and multi-channel threads. Document which fields were not mapped and why. The output is a validated data set and a mapping document that support leads and the security owner have reviewed. The step is done when sampled records match the source and the open issues list is accepted by the business owner.
Run a parallel period with the widget on a test site
Embed the Chatwoot widget on a test page or a staging copy of your website while the production Intercom Messenger stays live. Route real internal test traffic and a controlled share of agent work through both platforms, and compare response handling, notifications, assignment and CSAT capture. Track defects in a single list with severity and owner. The output is a parallel-run log and a defect register with each item either fixed or accepted. The step is done when no open defect blocks normal support work and agents have completed their training on the new inbox.
Cut over the production widget and routing
Replace the production Intercom script with the Chatwoot widget script in your site templates, tag manager or application code, and update any DNS, redirect or email routing records that point support traffic at the new platform. Keep Intercom's widget disabled rather than deleted so a rollback path exists. Confirm that forwarding of support email and social channels reaches Chatwoot, and that the help center links resolve. The output is a signed cutover checklist covering each change, its owner, the time it was made and the verification result. The step is done when the checklist is signed by the support lead and the security owner.
Decommission Intercom after the agreed retention period
Once the retention period agreed with legal and compliance has passed, revoke Intercom API tokens and app integrations, disable seats, and confirm that any final export needed for records has been archived in your own storage. Ask Intercom to confirm the terms that apply to deletion of your data and document the answer. Remove the Intercom script from any remaining properties. The output is a decommission record with the archive location, the date of token revocation and the confirmation of data deletion. The step is done when that record is filed with your compliance evidence.
Running Intercom and Chatwoot side by side during cutover
Keep Intercom and Chatwoot live together only for as long as the cutover needs, and make the first decision a channel-by-channel one. Website live chat is the easiest channel to run in parallel, because the Chatwoot widget can sit on a test page or a limited set of URLs while the Intercom Messenger stays on the rest of the site. Email and social channels are different. A single email address, Facebook page, Instagram account or WhatsApp number can usually be connected to only one inbox at a time, so moving those channels means disconnecting them from Intercom first, then reconnecting them to Chatwoot. Before the parallel run starts, confirm for each connected channel whether Chatwoot can take it over without a conflict, and check the reconnection steps with the vendor and in your own test environment.
Chatwoot must be ready before any traffic reaches it. It needs PostgreSQL as its only supported database, Redis 7.0 or higher, Ruby 3.2 or later and Node.js 20.x, and the host must be sized for your expected conversation volume according to the Chatwoot deployment requirements. Ubuntu 20.04 is the only officially supported Linux distribution on that page, so check your operating system before you build the host. Route new chats to one platform at a time: for example, send a small share of website traffic to Chatwoot, or assign one team or one inbox to it, then widen the share as agents confirm that routing, assignment and business hours behave as expected. Keep a written record of which platform owns each channel and each team on each day, so that nobody answers the same customer in both tools.
Agents need Intercom to stay readable for history after new conversations move. Keep the Intercom workspace open for search, and tell agents that old transcripts live there until the export and import are complete. Where a customer writes to a channel that has moved, the team should decide whether to reply in Chatwoot and add a note pointing to the earlier Intercom thread, or to finish that conversation in Intercom. Set a closing date for each channel, after which Intercom receives no new inbound messages and is kept read-only for reference. Plan the parallel period with your own volume and team structure in mind, and record the decision for each channel in writing before you switch it.
How the migration changes by team size and starting point
A small team with one website widget, one or two inboxes and a short list of automation rules has the simplest version of this move. The main work is mapping one set of conversations, contacts and articles into a single Chatwoot account, then replacing the Intercom Messenger snippet on the site. Because the surface is small, the migration can often be run as one planned cutover window rather than a long parallel run, though the team should still confirm this against its own volume.
- Account structure: Decide whether one Chatwoot account with one website inbox matches how the business already works before creating anything.
- Widget replacement: Plan the swap of the Messenger snippet for the Chatwoot widget script on every page that carries it, including login and checkout pages.
- Contacts: Export and reconcile the contact list so duplicates are merged before import, since a small list is quicker to clean by hand.
- Help center: Move the few published articles by hand or through a scripted copy, and check links that point back to Intercom URLs.
- Rollback path: Keep the Intercom workspace readable and the old widget script available for a short fallback period.
Before starting, confirm the conversation volume with your own export and check whether your hosting target meets the Chatwoot requirements for that load.
A support operation that serves several brands, countries or languages usually runs many Intercom inboxes, teams and widgets, often with different business hours and routing rules. In Chatwoot each brand or region tends to map to its own inbox, and teams and agent roles must be set up to match. The migration grows because every inbox needs its own widget, its own contact set and its own mapping of teams, so the work is planned as a set of parallel waves rather than one import.
- Inbox map: Build a table that links each Intercom inbox to a Chatwoot inbox, team, business-hours schedule and widget before any data moves.
- Teams and roles: Recreate teams and agent permissions so each region sees only its own conversations where required by policy.
- Data residency: Decide where each regional Chatwoot instance or database will run, since self-hosting lets you keep data in specific jurisdictions.
- Migration order: Move one brand or region at a time, verifying conversation history and routing before starting the next.
- Translations: Plan how help center articles in several languages are moved and linked to the right widget locale.
Ask your team to confirm which brands share customers, because shared contacts across inboxes affect how duplicates are merged.
A team that relies on Intercom Fin, custom bots, complex workflows or many event-driven messages has the most work to re-create. Chatwoot does not carry over Fin configurations, and its automation rules, Captain AI and integrations are configured again, not imported. The decision that matters most is whether the replacement needs AI at all, and if it does, whether the self-hosted Premium plan and a model host of your choice fit your data rules. Start by inventorying every bot flow and automation trigger before deciding what to rebuild.
- Automation inventory: List each Intercom workflow, bot and rule with its trigger, condition and action, then mark which ones Chatwoot can express natively.
- AI decision: Decide early whether Captain AI on a paid self-hosted plan replaces Fin, and confirm the model hosting and knowledge sources that would sit inside your environment.
- Integrations: Map custom integrations to the Chatwoot integrations and API that cover them, and identify gaps that need development work.
- Testing: Run rebuilt bots and rules against recorded test conversations before any customer sees them.
- Cost drivers: Ask for a written quote that separates the Chatwoot plan, hosting, model usage and build effort so the recurring costs are visible.
Confirm with Chatwoot which features are in each self-hosted plan before committing to a design that depends on them.
What drives migration cost and duration
This table lists the factors that change how much effort and infrastructure an Intercom to Chatwoot move needs, with the reason each one matters and how to keep it under control. Read it before requesting a quote, since most of the variance comes from history volume, attachments and the number of inboxes and automation rules rather than from the software itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Volume of conversation history | Full transcripts must be pulled through the Intercom Conversations API, so the number of conversations and messages sets the extraction and import workload. | Agree a retention cutoff in writing, for example open and recent conversations only, and archive older threads as read-only files. |
| Attachment size and count | CSV and S3 exports omit transcripts, and attachments add storage, transfer time and object storage sizing on the Chatwoot side. | Inventory attachments by size before scoping, and decide which historical files stay in an archive instead of the live inbox. |
| Number of channels and inboxes | Each website widget, email address and social or messaging channel needs its own inbox configuration, connection and testing. | Consolidate unused inboxes before migration and confirm which channels Chatwoot supports on the self-hosted edition you choose. |
| Automation rules and custom integrations | Intercom workflows, routing logic and third-party connections must be rebuilt by hand in Chatwoot, and each one needs testing. | Export the rule list, remove rules nobody uses, and rank the rest by business impact before rebuilding. |
| Teams, roles and agent count | Every agent needs an account, team membership and permissions, and the number of agents also drives the per-agent plan fee if you buy one. | Map teams and roles in a single spreadsheet, and buy paid seats only for agents who need features the Community Edition lacks. |
| Self-hosting and hardware choices | The Chatwoot requirements page recommends 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap. Hosting choices also set the operations effort for PostgreSQL, Redis and upgrades. | Size against your daily conversation peak, not the monthly average, and confirm the Ubuntu, Ruby and Node.js versions named in the requirements before provisioning. |
| Paid Premium or Enterprise features | Per the self-hosted plans page, Premium Support costs $19 per agent per month and adds Captain AI, voice calls, custom branding, roles and permissions, while Enterprise costs $99 per agent per month and adds SSO with SAML and SLA policies. | List the features you truly need before quoting, and check whether the Community Edition covers them. Ask for the plan fee per agent in writing. |
| Parallel running during cutover | Keeping Intercom and Chatwoot live together means two sets of channels, two sets of agent logins and duplicate routing for the overlap period. | Set a single cutover date for each channel, and agree in writing who handles conversations that start on one platform and finish on the other. |
What usually goes wrong in an Intercom to Chatwoot move
Most failed Intercom moves are not technical failures in Chatwoot itself. They come from incomplete history, forgotten front-end code, unclear cutover rules and infrastructure sized for a pilot rather than production. Each card below names one of these risks and the check that prevents it.
Partial history from the wrong export
Teams often start with the CSV or S3 export because it is the easiest option to find. Those routes omit message transcripts, so the imported Chatwoot inbox shows contacts and dates but not what was said. Pull full conversation content through the Intercom Conversations API, then compare a sample of imported threads against the originals before you retire Intercom. Ask your Chatwoot integrator to confirm how attachments and internal notes are carried over.
Widget scripts left on old pages
The Intercom Messenger snippet often sits in site templates, tag managers, help center pages, mobile web views and app webviews. If it remains on some pages after the Chatwoot widget goes live, visitors see two chat launchers and conversations split across two tools. Inventory every template and tag container that loads Intercom, replace the snippet in each one, and test the Chatwoot widget on desktop, mobile and logged-in pages before go-live.
Duplicated or lost conversations in parallel run
Running both tools during cutover means a customer who writes on one channel may be answered in the other, or a conversation may be started in Chatwoot while an older thread still waits in Intercom. Decide which channel routes to which tool on each date, set a freeze date after which Intercom stops accepting new conversations, and track open items in a shared list. Confirm with your team who closes conversations that started before the switch.
Assuming Captain matches Fin
Captain AI in Chatwoot is a different product from Intercom Fin, with its own knowledge sources, behavior and configuration. Teams that expect identical answers, resolution reporting or handoff rules are often disappointed after launch. Treat AI as a separate pilot: define the topics it may answer, test it against real questions from your Intercom history, and confirm which Captain features your chosen self-hosted plan includes before you turn it on.
PostgreSQL and Redis sized for a pilot
Chatwoot supports only PostgreSQL as its database and recommends Redis 7.0 or higher. Sizing that works for a test inbox can fail once bulk history imports, attachments and daily conversation volume arrive together. Use the published requirement tiers as a starting point, reserve swap space, and load-test the import job against a copy of production data. Ask your hosting partner to confirm backup and failover for both services.
Agents losing access to old contacts
Contacts, tags, teams and past conversations are the working memory of a support team. If agent accounts, roles or team assignments are not recreated before cutover, agents may find that a customer record they used daily no longer opens or shows no history. Map each Intercom team and role to a Chatwoot team and role, create and test agent logins before import, and check that a sample of contacts with long histories loads for a non-admin agent.
Questions teams ask before moving from Intercom to Chatwoot
Is the CSV or S3 export enough to move Intercom conversations?
No. The CSV export carries conversation metadata without message content, and the JSON export to Amazon S3 does not include transcripts. If you need the history of your conversations in Chatwoot, you have to pull each conversation, with its messages, through the Intercom Conversations API and write it into Chatwoot. That means scripting against the API, handling pagination and rate limits, mapping Intercom message types to Chatwoot conversations, and deciding how attachments are handled. Confirm the exact endpoints, limits and data fields against Intercom's current API documentation before you scope the work, because those details decide how much of the effort is extraction and how much is mapping.
How long does an Intercom to Chatwoot migration take?
No researched duration exists for this migration, so the honest answer is that the length depends on your environment. The main drivers are the number of conversations and contacts to extract, how many inboxes, teams, automation rules and canned responses you need to rebuild, how many website pages carry the Intercom Messenger snippet, and how long you plan to run both systems during cutover. Integrations with other tools add work because each one needs to be re-pointed. Ask for a timeline in the written scope, with the assumptions behind it, and check it against a sample export from your own account.
Can our team migrate from Intercom to Chatwoot without outside help?
A team with Linux server administration, PostgreSQL and Redis experience, and developers who can work with the Intercom API, can do it in house. Chatwoot documents an installation script for a Linux virtual machine as well as Docker and Kubernetes deployments, so the platform itself is approachable. The harder parts are the conversation extraction script, the contact identity mapping, rebuilding the chat widget and routing rules, and testing cutover. Teams that lack capacity for those tasks often bring in a partner. DeployOpen plans, implements, integrates, backs up, documents and supports self-hosted platforms in your own infrastructure, usually under a fixed-scope agreement signed before work starts.
What do admins and developers need to provide for the move?
Admins need a current inventory of Intercom inboxes, teams, auto-assignment settings, business hours, automation rules, canned responses, labels, contact attributes and help center content, plus access to the workspace to confirm each item. Developers need an Intercom access token with read permission for conversations and contacts, a host that meets Chatwoot's requirements, and time to test the import against a copy of your data. On the host side, Chatwoot requires Ruby 3.2 or later, recommends Node.js 20.x, supports only PostgreSQL as its database, and recommends Redis 7.0 or higher. Ubuntu 20.04 is the only officially supported Linux distribution. Check these against the Chatwoot deployment requirements before you choose an operating system.
What does Chatwoot cost on Community, Premium and Enterprise?
The Community Edition is listed at $0 and free forever, but you still pay for the server, storage, backups, administration time and any outside help. Premium Support is listed at $19 per agent per month and adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions, and priority support. Enterprise Edition is listed at $99 per agent per month and adds SSO with SAML and SLA policies. Per-agent prices scale with headcount, so as an illustrative example, a team of 10 agents on Premium would pay $190 per month in licenses before hosting costs. Confirm current prices, billing terms and which features each edition includes on the Chatwoot self-hosted plans page and with Chatwoot directly.
What should a migration quote include before we sign?
A useful quote lists the scope in writing before any work starts. It should name the Intercom data in scope, such as conversations with message content, contacts, attachments, the Messenger widget, help center articles and automation rules, and state what is excluded. It should describe the extraction method, the field mapping for contacts and conversations, the target Chatwoot edition and hosting environment, the parallel run and cutover plan, testing and acceptance criteria, backup steps, handover documentation and post-go-live support. Ask whether the work is fixed-scope, what changes would trigger a new estimate, and whether ongoing support or upgrades are offered as a retainer. Every assumption should be written down, including who provides the Intercom API access and the Linux host.
What breaks during cutover, and how do we run both tools?
The usual breakpoints are the website script that loads the chat widget, email forwarding and DNS records for support addresses, integrations that still post to Intercom, and agents working in two inboxes at once. Contacts can also appear twice if identity matching is not planned. A common approach is to route new chats to Chatwoot in a defined window while keeping Intercom available for agents to look up older threads. Freeze the Intercom export in a dated snapshot so the archive stays complete after the subscription ends. Agree the cutover date, rollback steps and owners in the written plan, and test each channel before switching it over.
What to confirm with Chatwoot before committing
Confirm the Chatwoot version and host requirements before you sign off on the migration plan. The current release at the time of writing is v4.18.0, published on September 18, 2026, but your team should check the chatwoot/chatwoot GitHub releases page on the day you deploy and pin the tag you tested. Chatwoot requires Ruby 3.2 or later, recommends Node.js 20.x, supports only PostgreSQL as its database and recommends Redis 7.0 or higher. Its documentation lists Ubuntu 20.04 as the only officially supported Linux distribution, so confirm with your platform team whether that release is acceptable under your patching policy, or whether a different base image or Docker or Kubernetes path is needed. Size the host against the vendor's guidance of at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and plan at least 1 GB of swap. Your own peak conversation volume, not the average, should set the final size, since the requirements page notes Sidekiq can use more than 1 GB of memory on a very active server.
Decide which Premium features you actually need before you budget. The Community Edition is free, but several capabilities discussed elsewhere on this page sit in paid self-hosted tiers: Captain AI, voice calls, custom branding, agent capacity, roles and permissions and priority support sit in Premium, and SSO with SAML and SLA policies sit in Enterprise. Check the Chatwoot self-hosted plans page against your requirement list, and confirm the current per-agent prices directly with Chatwoot, because they can change. If your Intercom workflows depend on custom branding for the widget or on roles that restrict agent access, treat those as paid items in the migration scope rather than assuming the Community Edition covers them. Finally, verify each channel reconnection as its own test. Website live chat is the simplest, since you replace the Intercom widget snippet on your site, but email forwarding, Facebook, Instagram, WhatsApp, Telegram, Line and SMS each depend on a separate account authorization or provider setup in Chatwoot. Record for every channel who owns the Meta, WhatsApp or SMS provider account, which credentials must be re-issued, and whether message history will reappear in the new inbox or stay in the archived export. Run one inbound and one outbound test per channel on the staging instance before cutover, and document any channel that cannot be reconnected so that the support team knows where Intercom must stay live during the parallel run.
How DeployOpen scopes and runs an Intercom to Chatwoot migration
DeployOpen plans, implements and hands over self-hosted Chatwoot inside your own cloud account, data center or air-gapped network, and treats the conversation history, contacts and widget as one migration. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope lists which Intercom conversations, contacts, articles and widgets move, and which are archived or retired.
- We confirm the Conversations API extraction method, export volume and handling of attachments before any data leaves Intercom.
- Scope names the hosting target, PostgreSQL and Redis topology, and the inboxes, teams and automation rules to rebuild.
How we build
- We install Chatwoot on your infrastructure and size it against your daily conversation volume using the published requirements.
- We rebuild the website chat widget, email and social inboxes, teams, auto-assignment, business hours and automation rules.
- We load migrated contacts and conversation history into a staging instance and test them before cutover.
How we hand over
- You receive documentation covering the deployment, configuration, the migration runbook and the cutover plan.
- We run both platforms in parallel during cutover so agents and customers see no gap in support, then retire the Intercom widget.
- Handover includes backup and upgrade procedures, so your team can operate Chatwoot without relying on us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Security testing of the deployed Chatwoot instance and its integrations can be scoped as a separate fixed-scope engagement.
- Any compliance evidence we prepare is for your independent auditors or certification bodies to assess, not issued by us.
