Migrate from Movidesk to Intercom

Movidesk Tickets map to Intercom Tickets, which are backed by Conversation records in the Inbox. The Movidesk status (open, pending, resolved, closed) maps to Intercom's Open, Closed, and Snoozed states. Movidesk priority maps to Ticket priority attributes. The Movidesk owner (agent assignment) maps to the Intercom Admin or Team assignment on the Ticket. Movidesk statusHistory audit log migrates as a threaded internal note at the top of the Intercom conversation for audit continuity. Movidesk's createdDate and changedDate map to Intercom's created_at and updated_at timestamps.

Movidesk People records flagged as agents migrate to Intercom Admins. We map email address as the dedupe key, and Movidesk ownerTeam membership maps to an Intercom Team that we pre-create before User import. Any Movidesk agent without an email match in the target Intercom workspace goes to a reconciliation queue for the admin to provision.

Movidesk People records flagged as customers map to Intercom Contacts. Email address is the primary dedupe key. Movidesk custom fields on People records migrate to Intercom Contact Attributes via the custom_attributes endpoint. The Movidesk organization linkage migrates as a Company association on the Intercom Contact.

Movidesk Organizations map to Intercom Companies. The Organization name becomes the Company name; domain becomes the Company website. We resolve the Movidesk Organization-to-People relationship during import by pre-creating Companies before Contact import so that the Company association is satisfied at insert time.

Movidesk Services represent service-level abstractions (SLA tiers, service offerings) that have no direct Intercom standard object equivalent. We create an Intercom Custom Object named Service, define its schema with the relevant fields from Movidesk (service name, tier, SLA response time), and import Service records during migration. Note that Intercom Custom Objects require manual schema definition before data import; we provide the schema definition document as part of the migration scope.

Movidesk Billing agreements are contractual service terms with no direct Intercom standard object. We create an Intercom Custom Object named Agreement with fields mapped from the Movidesk schema (agreement ID, start date, end date, billing cycle, linked organization). We resolve the Organization lookup by matching to pre-created Intercom Companies before Agreement import.

Movidesk Assets (equipment, products, or devices linked to tickets) migrate as Intercom Custom Object records of type Asset. We map Asset name, type, serial number, and linked organization. Assets in Movidesk often have ticket linkage; we store the linked Movidesk ticket ID as an external_id field on the Asset Custom Object for traceability. Customers requiring a full asset management workflow in Intercom use the Custom Object in combination with Fin AI procedures.

Movidesk Knowledge base Articles migrate to Intercom Help Center Articles within their corresponding Collections and Sections. Article title, body content (HTML or Markdown), author, created_at, and updated_at migrate directly. The Movidesk Article ID is stored as an external_id attribute on each Article for cross-reference. If the Movidesk KB is multilingual, we flag the collection for per-language setup in Intercom, since Intercom requires a separate locale configuration and article translation per language.

Movidesk KB Categories map to Intercom Help Center Collections (top-level) and Sections (nested). We map the category hierarchy and preserve parent-child relationships. Intercom requires Collections to be created before Sections, which must be created before Articles can be added, so we sequence this import before the Article migration phase. Multilingual KB categories require translation in all enabled locales before the collection publishes.

Movidesk's ticketCustomFieldValue API is POST-only with three named operations: InsertValues, UpdateValues, DeleteValues. We discover all active custom field definitions during scoping, then configure equivalent Ticket Attributes in Intercom before migration begins. Each custom field value migrates via a dedicated POST to Intercom's custom_attributes endpoint. Because every custom field operation counts toward Movidesk's 10 req/min rate limit, we batch these calls and interleave them with primary object exports.

Movidesk SLA definitions govern response and resolution time commitments per service tier. Intercom has a native SLA feature (Service Level Agreement) for plans that include it. We export SLA rules from Movidesk (name, first response target, resolution target, business hours) and map them to an Intercom SLA configuration. Note that Intercom's SLA applies to the Inbox as a whole rather than per-service, so customers with service-tier-specific SLAs document this distinction and may need to adjust SLA logic post-migration.

Movidesk Workflow rules (sequential task execution, automated routing, and status triggers) do not migrate to Intercom as code because the two automation models are structurally incompatible. Movidesk uses a visual sequential task model; Intercom uses a Rules engine with event triggers, conditions, and actions. We export every active Movidesk Workflow definition and deliver a written inventory document that lists each rule's trigger, conditions, actions, and the equivalent Intercom Rule configuration. The customer's admin rebuilds the rules in Intercom's Rules engine post-migration.

Movidesk Tags on tickets and articles migrate to Intercom Tags. We export tag names and associations from Movidesk and import them as Intercom Tags attached to the relevant Tickets and Articles. Tags in Intercom are flat label strings used for filtering and segmentation in the Inbox and reporting views.

Movidesk-configured chat widgets (embed code, appearance settings, channel routing) are Movidesk-specific client-side configurations that do not map to an Intercom standard object. We export the widget settings as a configuration document and note that the customer must configure the Intercom Messenger independently using Intercom's installation instructions (Web, iOS, Android embed). This is a configuration handoff, not a data migration.