Migrate from Fruux to monday Work Management

Fruux Contacts are exported as vCard (RFC 6350) blobs from each CardDAV addressbook-home-set. Standard properties (FN, N, EMAIL, TEL, ADR) map to monday Contact fields (name, email, phone, address) if the destination includes monday CRM. If monday CRM is not active, contacts are imported as Items in a dedicated Board using Name, Text, Email, Phone, and Location columns, with one Item per vCard. We extract UID from each vCard as a custom monday Item ID column to support deduplication against Fruux conflict artifacts.

Fruux Calendars are CalDAV collections (RFC 4791) containing iCalendar (RFC 5545) VEVENT components. Each Fruux calendar becomes a separate monday.com Board. Calendar name maps to Board name. VEVENT SUMMARY maps to Item name; DTSTART/DTEND map to Date columns (Start Date and End Date) or a Timeline column if the destination plan supports it; DESCRIPTION maps to a Text column; RRULE (recurrence) is parsed and expanded into individual monday.com recurring Items or a Note with recurrence rule preserved. ATTENDEE list is noted but not actively imported as monday does not have a native attendee object.

Each VEVENT component within a Fruux Calendar maps to one monday.com Item in the corresponding Board. Recurrence exceptions (RECURRENCE-ID overrides) are handled as separate Items with a custom Recurrence ID column linking them to the parent recurring Item. Time zone data from VTIMEZONE is applied to all DTSTART/DTEND timestamps during import. VALARM components are noted as a separate column (Reminder) for manual rebuild as monday automation recipes.

Fruux VTODO items are extracted from the task CalDAV collection. SUMMARY maps to Item name; DUE (DUE:DATETIME or DUE;VALUE=DATE) maps to a Date column; COMPLETED (STATUS:COMPLETED and VALARM) maps to Status column (Done/Not Done); DESCRIPTION maps to a Text column. Fruux allows multiple task lists. We offer two strategies during scoping: merge all task lists into a single monday Board (with a Group per original task list for visibility) or create separate Boards per task list. The customer chooses before migration begins.

Fruux stores iCalendar subscriptions (webcal/ICS feed URLs) as read-only calendars. We export the subscription URL from each Fruux subscription calendar. If the subscription is public, we re-register it in monday.com by creating an Item in a Subscription Board with a Link column pointing to the .ics URL, allowing users to re-subscribe in their calendar client. Private subscription URLs are flagged for the customer to handle manually post-migration.

Fruux supports multiple CardDAV addressbook-home-set collections per user. Each Fruux address book maps to a separate monday.com Board (if using Work Management) or a separate Contacts folder (if using monday CRM). We preserve the address book name as the Board or folder name during migration. If the customer has address book sharing configured in Fruux, we document the sharing configuration as a notes column for manual access-control setup in monday.

Fruux Bookmarks are stored in a proprietary non-standard format with no public export specification, no CardDAV binding, and no iCalendar equivalent. There is no interoperable protocol for bookmark extraction and no equivalent object in monday.com. We do not attempt to migrate Bookmarks. The customer is informed during scoping and Bookmarks are documented in the handoff inventory as requiring manual recreation in a monday Board with Link columns.

Fruux Notes are proprietary objects without a CardDAV or CalDAV binding. We attempt extraction via the Fruux web API path where accessible, but cannot guarantee full content or formatting fidelity. Extracted notes are imported as long-text column values on the most relevant monday Item (e.g., the contact Item for a note associated with a Fruux contact, or the Board-level Item for a standalone note). Notes with no associated record are imported as Items in a dedicated Notes Board. The customer is informed that note formatting may not transfer completely.

Fruux conflict resolution creates server-side copies when the same record is edited on multiple devices simultaneously. These copies appear as duplicate vCards or VEVENTs in the export with the same UID and different FN/NAME values. We detect duplicates by comparing UID fields and FN/NAME fields, flag suspected duplicates with a custom Duplicate column (values: Original, Conflict Copy) for customer review before deletion. If the customer approves, we retain only the most recently modified version and remove conflict copies from the monday destination.

Fruux tracks which device last modified each record via the X-MUTAPPLETSYNCDEVICEID property in vCards and CREATED and LAST-MODIFIED iCalendar properties. We extract device attribution and note it in a custom Device Source column on each monday Item so the customer's team can trace record provenance. This is informational only and does not affect the migration mapping.

Fruux does not have a team or user-assignment model in the same sense as monday.com. Fruux user accounts are per-individual with device-based sync. When migrating to monday.com, we map the Fruux account holder to the monday.com workspace primary user. If multiple Fruux users with separate accounts are being migrated (e.g., a Team tier with multiple members), we create corresponding monday.com User accounts and distribute Items based on Fruux device-owner attribution. Fruux sharing configurations (up to 2 shares on Basic, unlimited on Pro/Team) are documented as access-control notes for manual rebuild in monday.

Fruux allows multiple named task lists (VTODO collections). By default we merge all task lists into a single monday Board and create a monday Group per original task list to preserve organizational semantics. If the customer prefers separate Boards per task list, we create one Board per task list during migration and name each Board after the original Fruux task list. The preference is collected during scoping before migration begins.