Migrate your monday service data

Tickets are Items on Boards in monday service. Standard fields (title, description, status, priority, assignee, created date) are well-documented and stable. We migrate Tickets as Items, preserving the board-to-ticket mapping and all native Item column values.

Customer records are Items on a dedicated Customer Board or contacts stored in a monday.com Contacts integration. We map these to the destination's native contact/customer object, flagging custom columns that require value translation.

Conversation threads are stored as Updates or sub-items on Ticket Items, depending on configuration. We extract updates and reconstruct thread chronology, noting that some rich media (e.g. embedded images) may require re-embedding after cutover.

SLA policies are set via custom columns or automation rules referencing dates. We preserve the SLA target values as custom date columns and flag automation rules that reference them so they can be rebuilt at the destination.

Agent records are standard monday.com Users. We map them 1:1 by email, preserving display names, role assignments, and active/inactive status.

Boards are the core container object. We migrate all boards including private and shareable boards, preserving group structure, column types, and board-level settings.

Groups are row groupings within a Board. We preserve group names and item placement within groups, mapping them to equivalent grouping constructs at the destination.

monday.com column types include text, numbers, dates, status, dropdown, link, file, and formula. Column types translate to destination equivalents; unsupported column types (e.g. formula columns) are flagged for manual review.

Automation rules are monday.com native and are not accessible via the public API. We cannot export automation definitions programmatically. We document all automation triggers and actions during discovery and provide a written playbook for recreating them at the destination.

Files uploaded to Items can be included in account exports but add significant processing time. We optionally exclude files during scoping and advise on re-attachment post-migration. Files stored externally (via links) are preserved as URL values.

The customer-facing portal layout, custom domains, and branding settings are not exposed via API. We document portal configuration during discovery and note that portal re-setup is a manual post-migration step.

Tags applied to Items are preserved as tag values or mapped to equivalent labelling fields at the destination, depending on whether the destination supports a native tag model.

Dashboard widgets referencing board data are migrated as data exports rather than live dashboard replications. We preserve the underlying data and flag dashboard widgets that will require manual reconfiguration.

Third-party integrations are account-level configurations not accessible via API. Integration credentials and mapping rules must be re-established manually at the destination. We document active integrations during discovery so nothing is missed.