Helpdesk migration
Field-level mapping, validation, and rollback between Movidesk and Freshdesk. We move data and schema; workflows are rebuilt natively in Freshdesk.
Movidesk
Source
Freshdesk
Destination
Compatibility
5 of 10
objects map 1:1 between Movidesk and Freshdesk.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Movidesk to Freshdesk means leaving a single-tier, Brazilian-market helpdesk for a globally-scaled, AI-powered support platform with tiered pricing from $15 per user per month. The structural differences are significant: Movidesk represents agents and customers under a unified People object while Freshdesk separates Contacts and Agents; Movidesk's custom field API is POST-only and rate-limited at 10 requests per minute versus Freshdesk's per-minute limits of 200 to 700 calls depending on plan. We map People to Contact and Agent records based on Movidesk's personType discriminator, sequence the ticket import with the Movidesk API's rate ceiling in mind, and handle custom field values as Freshdesk custom fields after the schema is pre-built in the destination. Workflows, automations, SLA configurations, and chat widget code do not migrate as functional records; we deliver a written inventory for your admin to rebuild in Freshdesk's automation builder.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Movidesk object lands in Freshdesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Movidesk
Ticket
Freshdesk
Ticket
1:1Movidesk Tickets map directly to Freshdesk Tickets. The Movidesk standard fields status, priority, owner, ownerTeam, changedBy, and changedDate map to Freshdesk's status, priority, agent_id, group_id, and updated_at. The statusHistories audit log migrates as Freshdesk Conversation records of type comment, preserving the full timeline of changes. Ticket type mapping uses Movidesk's type field mapped to Freshdesk's type property (Incident, Request, Problem, Question) or a custom ticket field if Movidesk uses a custom type schema.
Movidesk
People
Freshdesk
Contact and Agent
1:manyMovidesk's unified People object holds both agents and customers. We split on the personType discriminator if present, or infer from whether the person is referenced as an owner on any ticket. Agents migrate to Freshdesk Agent records; customers migrate to Freshdesk Contact records. Email, phone, and organizational affiliations preserve. We create Freshdesk Agents first since Agent ID is required for ticket owner resolution during the ticket import phase.
Movidesk
Organization
Freshdesk
Company
1:1Movidesk Organizations map to Freshdesk Company records. Organization name, domain, address, and custom fields transfer. Company ID serves as the dedupe key during import. We create Companies before Contacts so that the Freshdesk company_id lookup is satisfied at the moment of Contact insert.
Movidesk
Service
Freshdesk
Product (Freshdesk Product Catalog)
lossyMovidesk Services represent service-level abstractions without a direct Freshdesk equivalent. Freshdesk Product Catalog can represent service items attached to tickets. We map service definitions to Freshdesk Product records with the service name as product name and the service description as the product description. If no product-equivalent is appropriate, we migrate services as Freshdesk ticket custom fields with picklist values.
Movidesk
Asset
Freshdesk
Asset (Freshdesk Asset Manager, Enterprise+)
1:1Movidesk Assets (equipment and product records linked to tickets) map to Freshdesk Asset records if the destination Freshdesk plan includes Asset Manager (Enterprise tier). If the destination plan does not include Asset Manager, we migrate asset data as ticket custom fields or as Company-level custom fields and document the limitation in the scope summary.
Movidesk
Knowledge base Article
Freshdesk
Article
1:1Movidesk Knowledge base articles migrate to Freshdesk Portal articles. We preserve article title, body content (rich text), category assignment, and status (draft, published). Attachments embedded in article bodies migrate as Freshdesk article attachments. Movidesk's multilingual KB requires all target language Help center appearances to be activated in Freshdesk before articles in those languages can publish; we flag this as a post-migration configuration step.
Movidesk
Knowledge base Category
Freshdesk
Category and Section
lossyMovidesk KB categories map to Freshdesk Sections within a Portal Category. We preserve the category hierarchy so articles land in the correct sections. For multilingual knowledge bases, each language category set migrates to a corresponding Freshdesk portal language setting, requiring the Help center to have the same language enabled in Freshdesk before articles appear correctly.
Movidesk
Custom field
Freshdesk
Custom field
lossyMovidesk custom fields are discovered during the scoping phase by analyzing the ticketCustomFieldValue API responses. We pre-build Freshdesk custom field definitions (matching the field type and options) before any ticket records are imported. Each custom field value is then posted as a Freshdesk ticket field update. Movidesk's POST-only custom field API (InsertValues/UpdateValues/DeleteValues) means we cannot retrieve schema definitions directly; we infer field types from the values encountered during the scoping pass. Custom fields on People and Organizations follow the same pattern against the respective Freshdesk Contact and Company objects.
Movidesk
SLA configuration
Freshdesk
SLA Policy
lossyMovidesk SLA definitions with response time and resolution time commitments migrate as Freshdesk SLA Policies. We map SLA names, time thresholds, and escalation rules to Freshdesk's SLA Policy entity with corresponding business hour calendars. Note that Freshdesk SLA Policies are tied to specific plans and require the appropriate tier to be active at the destination.
Movidesk
Tag
Freshdesk
Tag
1:1Movidesk tags on tickets migrate as Freshdesk tags. Tag labels transfer as-is. If Movidesk tags exceed Freshdesk's tag length conventions, we truncate and document the change in the scope summary. Tags used for article classification migrate as Freshdesk article tags.
| Movidesk | Freshdesk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| People | Contact and Agent1:many | Fully supported | |
| Organization | Company1:1 | Fully supported | |
| Service | Product (Freshdesk Product Catalog)lossy | Fully supported | |
| Asset | Asset (Freshdesk Asset Manager, Enterprise+)1:1 | Fully supported | |
| Knowledge base Article | Article1:1 | Fully supported | |
| Knowledge base Category | Category and Sectionlossy | Fully supported | |
| Custom field | Custom fieldlossy | Fully supported | |
| SLA configuration | SLA Policylossy | Fully supported | |
| Tag | Tag1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Movidesk gotchas
API rate limit of 10 requests per minute constrains bulk migrations
Custom field API is POST-only with three named operations
Workflow requires access profile activation before it is visible in the UI
Pricing is in Brazilian Real, not USD, and may fluctuate
Multilingual knowledge base requires per-language Help center appearance setup
Freshdesk gotchas
API access is blocked on the free plan
Per-minute rate limits are account-wide and endpoint-specific
Multi-channel source types do not map 1:1 to all destinations
Custom objects created in-product cannot be accessed by other apps
Contact import requires at least 10 existing tickets in the account
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the source Movidesk account for record volumes across all migratable objects (Tickets, People, Organizations, Assets, Services, Billing agreements, Knowledge base articles and categories), custom field definitions inferred from scoping samples, active Workflow rules, SLA configurations, and chat widget setup. We pair this with a Freshdesk plan review to confirm which destination features are available (Asset Manager, SLA Policies, custom objects). The discovery output is a written scope document with object counts, custom field inventory, and a Freshdesk plan recommendation.
People-to-Contact and Agent split analysis
We run a scoping query against Movidesk's API to identify which People records are agents (referenced as ticket owners or ownerTeam members) versus customers (ticket requesters). We build the split map and verify it with the customer's Movidesk admin before migration begins. Freshdesk Agents are created first so their IDs are available for ticket owner resolution during the ticket import phase. Any People record with ambiguous role assignment is flagged for manual resolution before the migration phase.
Freshdesk schema pre-build and automation disable
We pre-build the Freshdesk destination schema: custom fields on Tickets, Contacts, and Companies (typed and option-valued based on Movidesk field inference), Freshdesk Agents with matching role and group assignments, Freshdesk Companies from Movidesk Organizations, and Freshdesk Product Catalog entries from Movidesk Services. We also disable all Freshdesk Automations, Scenario Automations, and email notifications during this phase per Freshdesk's migration preparation guide. This prevents Freshdesk from altering record state during the import window.
Rate-limited Movidesk export in dependency order
We export Movidesk data in strict dependency order: Assets first (for any asset-linked tickets), then Organizations, then People (Agents, then Contacts), then Knowledge base Categories, then Knowledge base Articles, then SLA policies, then Tickets. Each object batch is rate-limited to 10 req/min with exponential back-off on failures. Custom field values are exported alongside their parent ticket records and sequenced as separate POST operations against Freshdesk's custom field API. Large ticket histories may require multiple export sessions across several days.
Freshdesk import with reconciliation
We import records into Freshdesk in dependency order: Companies (as Freshdesk Company records), then Agents, then Contacts (with company_id resolved), then Products (from Movidesk Services), then Knowledge base categories and articles, then Tickets (with owner_id, group_id, and type resolved). Custom field values are posted to Freshdesk tickets after the base ticket record exists. Each phase emits a row-count reconciliation report showing records attempted, records succeeded, and records failed. Failed records are analyzed and re-imported in a targeted pass.
Cutover, validation, and automation rebuild handoff
We freeze writes on Movidesk during cutover, run a final delta pass to capture any records modified during the migration window, then re-enable Freshdesk automations and notifications in controlled sequence. We deliver a written inventory of Movidesk Workflow rules, SLA configurations, and chat widget settings for the customer's Freshdesk admin to rebuild using Freshdesk's Automation rules, SLA Policies, and Help center configuration. We support a one-week hypercare window for reconciliation issues raised by the support team. Post-migration admin rebuilds of automations, forms, and reports sit outside standard migration scope and are quoted separately.
Platform deep dives
Movidesk
Source
Strengths
Weaknesses
Freshdesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Movidesk and Freshdesk.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Movidesk: 10 requests per minute per API token.
Data volume sensitivity
Movidesk doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Movidesk to Freshdesk migration scoping. Not seeing yours? Book a call.
Walk through your Movidesk to Freshdesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Movidesk
Other ways to arrive at Freshdesk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.