Migrate from Fruux to Asana

Fruux CalDAV calendars (RFC 4791 collections) map to Asana Projects. The Fruux calendar name becomes the Asana Project name, and VEVENT components (iCalendar RFC 5545) within the calendar become Asana Tasks. Recurrence rules (RRULE), time zones, organizer, and summary fields from each VEVENT transfer as task fields. We map Fruux calendar color coding to Asana project color options where available. If the Fruux calendar is shared with other Fruux users, the sharing permissions translate to Asana Team membership on the Project during migration.

Fruux VTODO components from CalDAV task collections map to Asana Tasks. The VTODO SUMMARY maps to task name, DUE (DTSTART/DUE) maps to due_date, COMPLETED maps to completed_at, STATUS (COMPLETED/NEEDS-ACTION) maps to task completion status, DESCRIPTION maps to task notes, and PRIORITY maps to a custom numeric priority field or to Asana's native priority system if the customer configures it. Subtasks within a VTODO become Asana subtasks via the parent_task_gid relationship.

Fruux supports multiple task lists per user. Each Fruux CalDAV task collection maps to a separate Asana Project. Within each Project, we create Sections corresponding to any named VTODO categories or grouping properties present in the source. If Fruux task lists contain unnamed or flat tasks without grouping, all tasks import into the default Section of the destination Project.

Fruux CardDAV contacts (RFC 6350 vCard) do not map to a native Asana object because Asana does not have a CRM-style contact repository. We offer two migration strategies: Strategy A — extract vCard fields (FN, EMAIL, TEL, ADR, ORG) and store them as a JSON-formatted custom field value on a dedicated 'Contacts' Project or on individual Tasks that reference the contact. Strategy B — pre-convert vCards to a CSV and import them into the customer's preferred contact management tool (Google Contacts, HubSpot, Salesforce) separately, with a custom field on Asana Tasks pointing to the external contact record by email address. The customer selects Strategy A or B during scoping.

Fruux CardDAV addressbook-home-set containers (multiple address books per user) map to Asana Teams at the Workspace level. Each Fruux address book becomes a Team, and the vCard contacts within it are handled via the Contact migration strategy above. If the destination Asana plan supports only one Team, multiple Fruux address books merge into a single Team with address-book-of-origin stored as a custom field on each contact reference record.

Fruux iCalendar subscriptions (webcal:// or https:// .ics feeds) appear as read-only calendars in the Fruux interface. We export the subscription URL and re-register it in Asana as an external calendar integration if the customer's Asana plan supports it, or store the .ics URL in a dedicated Project description for manual re-subscription post-migration. If the subscription URL is private or requires authentication, we flag it during scoping and the customer re-subscribes manually in Asana.

Fruux CardDAV and CalDAV sharing is implemented via WebDAV ACL (RFC 3744) principal-privilege bindings. When a Fruux calendar or address book is shared with another Fruux user, we extract the sharing principal URL and map it to an Asana Team membership on the destination Project or Team. The customer's Asana admin provisions matching User records before migration so that sharing ACLs can resolve to Asana User GIDs.

Fruux stores category assignments within vCard CATEGORIES and iCalendar CATEGORIES properties. These migrate to Asana Tags, which are a native Asana object accessible at the Workspace level. We create tags in Asana before task import and apply them via the Asana Tags API to each migrated Task. Tag names are preserved exactly as they appear in the Fruux CATEGORIES field; duplicates are deduplicated by name during import.

Fruux preserves server-side copies when the same record is edited on multiple devices simultaneously. These conflict artifacts appear as duplicate VEVENT or VTODO entries with identical UIDs but different SEQUENCE numbers or DTSTAMP values. We detect duplicates by comparing UID fields and select the entry with the highest SEQUENCE number as the canonical record. Lower-sequence duplicates are flagged as suspected conflicts and created as separate Tasks with a 'conflict_resolved' custom field set to false, for customer review before deletion.

Fruux Owners are identified by email principal URLs in CardDAV and CalDAV ACLs. We extract every distinct Owner email from the Fruux data export and match by email against the destination Asana Workspace's User list. Owners without a matching Asana User go to a reconciliation queue for the customer's admin to provision. Unassigned Tasks default to the migration service account during import and are reassigned post-migration.

Fruux Bookmarks are stored in a proprietary internal format not accessible via CardDAV or CalDAV and have no public export specification. We do not migrate Bookmarks because there is no interoperable export protocol. Customers with heavy Bookmarks usage are notified during scoping and may choose to export Bookmarks manually from the Fruux web interface before account closure. No Asana object provides a native bookmark or URL-repository function.

Fruux Notes are stored in a proprietary format without a CardDAV or CalDAV binding. We attempt extraction via the Fruux web application scraping path, but cannot guarantee structural fidelity, formatting, or complete content preservation. Migrated Notes are written into the notes field of the nearest Asana Task (matched by date proximity or a Fruux-defined task reference if present), or attached as a .txt file to the destination Project if no task relationship is defined. Customers with heavy Notes usage receive a warning during scoping that manual verification of migrated content is required.