Migrate your Octadesk data

Tickets is the primary helpdesk object in Octadesk, holding status, priority, owner assignment, custom fields, and channel metadata. The REST API exposes full CRUD via /tickets with customField arrays and attachment arrays. We migrate Tickets 1:1 and preserve their ID mapping for downstream dependency resolution.

Chats represent real-time conversation sessions, retrievable via GET /chat with filter criteria, pagination (MAX=100 per page), and sort parameters. Conversation events inside a Chat are a separate /chat/{id}/events endpoint. We map Chats to the destination's equivalent conversation object, splitting message history from session metadata.

Contacts store customer profiles with contact details, lifecycle data, and custom properties. We migrate Contacts 1:1 where the destination schema supports the same field types. Custom Contact properties require value-level mapping when the target uses different field naming conventions.

Companies in Octadesk represent business accounts associated with Contacts. We map the association relationship explicitly during migration and flag if the destination does not have a separate Company object, in which case we merge Company fields into the Contact record.

Agents are users who handle Tickets and Chats. We migrate the agent record (name, email, role) and preserve the owner assignment on Tickets. If the destination uses a different user model, we map Agent email to the target's user identifier and flag role mismatches.

Teams group Agents for routing and SLA purposes. We preserve team membership during migration and map team-based routing rules to the destination's equivalent queue or team structure.

Octadesk Tickets support customField arrays and apps arrays. Custom field data types (text, numeric, dropdown, date) require field-level mapping against the destination schema. We export the full custom field definition and data so the target can reproduce the same field structure or equivalent.

Attachments on Tickets and Chats are referenced by URL and can be downloaded and re-uploaded to the destination. We download files during migration, map them to the corresponding Ticket or Chat on the target, and preserve the original filename and MIME type.

Tags are labels applied across Tickets and Contacts. We export all tag assignments per record and recreate them on the destination. Some platforms restrict tag characters or length, so we normalise tag strings during import.

Octadesk automation rules (triggers, macros, routing logic) are internal configuration that references agent IDs, team IDs, and custom field values by internal identifier. These do not have a documented export API and cannot be reliably migrated in a generic way. We document the automation logic during scoping and recommend a manual rebuild on the destination.

Octadesk's proprietary AI agents and chatbot flow configurations are built on internal proprietary schemas not exposed via public API. We do not migrate these as they require recreation in the destination platform's native AI tooling.

Dashboards and performance reports reference internal Octadesk metrics and aggregation logic. We export report configurations as metadata but cannot replay them on platforms with different metric definitions. We recommend rebuilding key dashboards manually post-migration using migrated data.