Migrate from Movidesk to HubSpot Service Hub

Movidesk Tickets map directly to HubSpot Conversations (also called Tickets in the Service Hub UI). We preserve status, priority, owner, ownerTeam, changedBy, changedDate, and the full statusHistory audit log as a custom long-text property on the HubSpot ticket for audit continuity. Movidesk's ticket conversations (message thread) migrate as HubSpot ConversationParts linked to the parent Conversation record. The mapping resolves Movidesk's ownerId to a HubSpot User by email match, with a reconciliation queue for unresolvable owners.

Movidesk's unified People object covers both agents and customers. We split at migration time: People records flagged as agents (based on Movidesk's access profile type) map to HubSpot User (for seat licensing) or remain as Contact if the agent also appears as a customer. Customer-type People map to HubSpot Contact. Email address is the dedupe key. Any Person record that appears as a ticket requester, organization-linked contact, or asset-linked contact is treated as a Contact regardless of agent status.

Movidesk Organizations map to HubSpot Companies. The organization's name, domain, and contact details migrate directly. Company is created before Contact import so that the HubSpot Contact-to-Company association (companyId) is satisfied at the moment of Contact insert. Organizations linked to Assets carry that relationship into HubSpot through the Asset-to-Product or Asset-to-custom-object mapping established during scoping.

Movidesk Assets are a distinct object tracking equipment or products linked to tickets and organizations. HubSpot Service Hub has no native Asset object, so we map Assets to HubSpot Products (if they represent billable or trackable products) or to a Service Hub Enterprise custom object (if they represent equipment or inventory requiring relationship tracking). The customer chooses the strategy during scoping. Asset-to-ticket relationships migrate as ticket associations in HubSpot.

Movidesk Services represent service-level abstractions that may not have a direct HubSpot equivalent. We migrate service definitions as a reference mapping for the customer to implement as Products (for service contracts) or a custom object (for service-level entities with multiple fields). This is a Movidesk-specific concept that requires customer input on how service data should function in HubSpot before we design the destination schema.

Billing agreements track contractual service terms in Movidesk and have no direct HubSpot Service Hub equivalent. We map them to HubSpot Deals with custom fields (contract start/end dates, billing frequency, tier) at Professional, or to a custom object at Enterprise if the agreement has complex line items or relationships. The customer selects the strategy during scoping based on their contract management workflow.

Movidesk Knowledge base articles migrate to HubSpot Knowledge base articles. Article body content, category assignments, and publish status transfer. We flag articles linked to Movidesk's multilingual KB where source languages are incomplete, because HubSpot requires that articles have a primary language before publishing. Movidesk article attachments migrate as HubSpot Knowledge base article attachments.

Movidesk KB categories map to HubSpot Knowledge base categories. The category hierarchy (parent/child relationships) preserves in HubSpot. For multilingual KBs, we verify that each category has a translation set in every enabled language; if a category lacks a translation in HubSpot's required format, we flag it for completion before the KB goes live in HubSpot.

Movidesk SLA definitions (response time, resolution time, escalation triggers) map to HubSpot Service Hub SLA policies on Professional and Enterprise tiers. We export SLA rules from Movidesk, then configure HubSpot SLAs with matching first-response and next-response targets. Conditional SLAs (with time-based or channel-based conditions) are available on HubSpot Enterprise and require additional configuration post-migration.

Movidesk ticketCustomFieldValue is a POST-only API with three named operations (InsertValues, UpdateValues, DeleteValues) and no GET endpoint to retrieve schema. We discover custom field definitions during scoping by inspecting exported ticket data, inferring the field type from value patterns, and generating the correct POST operation per record during the transform phase. Each custom field update counts toward the 10 req/min rate limit, so we batch these into rate-limited sequences separately from primary object imports. HubSpot custom properties use a standard REST API (GET, POST, PATCH) with typed fields (string, number, date, enumeration, etc.).

Movidesk tags on tickets and articles migrate as HubSpot Tags. Tag associations on tickets migrate as HubSpot conversation associations. Tag associations on KB articles migrate as HubSpot knowledge base article associations. Tags are preserved as flat label strings and do not restructure in HubSpot.

Movidesk chat widget configurations (embed code, trigger settings, greeting messages) export as configuration data. HubSpot has its own chat widget (HubSpot Conversations inbox with live chat and chatbots). Widget configuration export does not transfer as a live widget; we deliver the configuration inventory document so the customer's admin rebuilds the widget settings in HubSpot's Conversations inbox setup.