Migrate your Movidesk data

Tickets are the primary object with a rich schema: status, priority, owner, ownerTeam, changedBy, changedDate, permanencyTimeFullTime, permanencyTimeWorkingTime, and a read-only statusHistories audit log. We migrate tickets 1:1, preserving full status history and timestamps. Custom field values use the POST-only /ticketCustomFieldValue/{operation} endpoint which we call sequentially to respect the 10 req/min limit.

Movidesk distinguishes agents and customers under a unified People object. We export and import People records via the documented spreadsheet templates. Email addresses and contact details are preserved. Bulk import requires adherence to the People import layout format.

Organizations (companies) are separate from People in Movidesk's data model. We map organizations to the destination CRM's equivalent Account/Company object and resolve cross-references to People records.

Services represent service-level abstractions in Movidesk. We migrate service definitions but note that the concept may not map 1:1 in all destination platforms—some CRMs lack an equivalent service-level object and we fold service associations into ticket properties.

Billing agreements track contractual service terms. These are Movidesk-specific and require field-level mapping to the destination's contract or agreement objects where they exist.

Assets are a distinct object in Movidesk for tracking equipment or products linked to tickets. We migrate asset records including relationships to organizations and tickets via the Assets import template.

Articles are published within categories and localized via Movidesk's multilingual knowledge base. We export articles with their category assignments and body content. Note that multilingual KB requires separate Help center appearance configurations per language.

KB categories structure the knowledge base hierarchy. We preserve category assignments during migration. Multilingual KB mandates that categories have translations in each enabled language before articles publish correctly.

Workflows define sequential task execution and automation rules. Workflow must be explicitly enabled in the agent's access profile before the UI option appears. We export workflow definitions and note that rule complexity may require manual reassembly in the destination if the target platform uses a different automation model.

Custom fields (ticketCustomFieldValue) are managed via a POST-only API with three operations: InsertValues, UpdateValues, DeleteValues. There is no GET or DELETE at the object level. We generate per-operation API calls for each field and respect the 10 req/min rate limit by chunking requests and applying back-off between operations.

Movidesk supports tagging on tickets and articles. Tags migrate as flat label associations; we map them to the destination platform's equivalent tagging or labeling mechanism.

Chat widgets are Movidesk-configured embeddable widgets for customer-facing chat. Widget configurations (embed code, settings) are migrated as configuration data rather than records, and embedding logic must be rebuilt in the destination platform.

SLA definitions govern response and resolution time commitments. We export SLA rules and map them to the destination's SLA configuration schema, noting that naming conventions and escalation triggers vary between platforms.