Migrate from Fruux to Trello

Fruux stores task items as VTODO components within CalDAV task-list collections. Each distinct CalDAV task-list collection in Fruux becomes a dedicated Trello board; each VTODO item within that collection becomes a card in the corresponding board. The Fruux VTODO SUMMARY maps to the Trello card name. STATUS (COMPLETED/NEEDS-ACTION) maps to Trello card checklist completion or card archival at customer preference. DUE maps to Trello card Due Date; CREATED and LAST-MODIFIED timestamps are preserved as custom fields. Fruux's lack of a native assignee model means task ownership is preserved as a card label or custom member field at scoping discretion.

Fruux allows multiple independent CalDAV task lists per user. Each source task-list collection is mapped to a separate Trello board. Within each board, a default To Do list is created. If the source task list contains sub-categories or tags, additional Trello Lists are created per category and cards are distributed accordingly. Fruux task lists with no internal categorization are migrated as a single board with one list. Teams using Fruux Team tier with multiple shared task lists receive one Trello board per source list.

Fruux calendars are CalDAV collections containing iCalendar VEVENT components with RFC 5545 properties (DTSTART, DTEND, SUMMARY, DESCRIPTION, LOCATION, RRULE for recurring events). Each Fruux calendar becomes a dedicated Trello board. Each VEVENT becomes a card in that board with DTSTART mapped to card start date, DTEND mapped to card due date if applicable, SUMMARY as card name, DESCRIPTION carrying the VEVENT description, and LOCATION as a custom field. Recurrence rules (RRULE) are preserved as text in the card description because Trello has no native recurrence model; the customer rebuilds recurring cards via Butler rules post-migration.

Fruux iCalendar subscriptions appear as read-only CalDAV calendars pointing to external webcal or ICS feed URLs. We extract the subscription URL and create a Trello card in the corresponding calendar board with the subscription URL stored as a link attachment or as a custom URL field. If the subscription URL is private (requires authentication), we flag this at scoping and document the URL so the customer's admin can re-register the subscription in Trello or a calendar app. Trello does not natively refresh ICS subscriptions, so calendar-level sync requires a third-party integration or manual re-subscription.

Fruux contacts are exported via CardDAV as vCard 3.0 or 4.0 blobs (FN, N, EMAIL, TEL, ADR, ORG, PHOTO). Trello has no native contact management object, so we create a dedicated Contacts Trello board and model each Fruux contact as a card. FN becomes the card name. EMAIL (work and home), TEL (work and home), ADR, and ORG map to Trello Custom Fields (Text type for email and org, Text for phone). Fruux multi-address-book support maps to separate Trello boards per address book. Contact photos are stored as card attachments if the photo blob is small enough; large photos are flagged for manual re-upload.

Fruux supports multiple CardDAV address books per user, each containing vCard contact records. Each source address book is mapped to a separate Trello board in the destination. Board naming follows the Fruux address book display name. Contacts within each address book become cards in the corresponding board as described in the vCard mapping. If the destination workspace has naming conventions for contact boards, we apply them during configuration.

Fruux allows users to create multiple independent task lists. When migrating to Trello, each source Fruux task list is split into its own Trello board. If the customer uses Fruux Team tier with shared team task lists, each shared list becomes a Trello board shared with the relevant workspace members. Fruux Pro users with up to 10 device sync but single personal task lists receive one Trello board per source list. We flag the list-to-board split at scoping and confirm the desired workspace organization before migration begins.

Fruux Notes are stored in a proprietary format with no CardDAV or CalDAV binding. We attempt to export accessible Notes via the Fruux web application scraping path and convert the content to plain text. Each Note becomes a Trello card in a dedicated Notes board (or a designated list within an existing board per customer preference) with the Note content as the card description. Rich formatting, embedded media, and Fruux-specific styling cannot be guaranteed to transfer. Customers with heavy Notes usage are warned that formatting loss is expected and should plan for manual review post-migration.

Fruux Bookmarks are stored in a proprietary internal format not accessible via CardDAV or CalDAV. The web API documentation does not define bookmark export endpoints. We attempt web application scraping but cannot guarantee structural fidelity. Migrated Bookmarks are documented as plain-text URL entries in a dedicated Trello board's cards, with the bookmark title as card name and URL as a custom field or card description link. Customers relying on Fruux Bookmarks for active workflow should plan to recreate bookmark collections manually in Trello or a dedicated bookmark manager post-migration.

Fruux iCalendar subscriptions are stored as external ICS or webcal feed URLs within the Fruux CalDAV hierarchy. We export each subscription URL and create a Trello card in the corresponding calendar board with the URL stored as a custom URL field. Subscription URLs requiring authentication or containing private calendar data are flagged during scoping for the customer's admin to re-register post-migration. Trello does not natively refresh ICS subscriptions, so teams relying on live calendar sync from Fruux feeds need to re-establish those subscriptions in a compatible calendar client (Google Calendar, Fantastical, or similar) alongside Trello.

Fruux CardDAV address books support contact groups (GROUP vCard component or X-ADDRESSBOOKSERVER-MEMBER references). When migrating to Trello, contact groups are mapped to Trello Labels on the corresponding Contacts board cards. Label names match the Fruux group name. If a contact belongs to multiple groups, it receives multiple labels. Label color assignment is configured during migration to provide visual grouping in the Contacts board. Customers choosing to use Labels as the group-semantic equivalent confirm the labeling scheme during scoping.

Fruux preserves server-side copies when the same record is edited on multiple devices simultaneously, creating duplicate contacts or events. We detect duplicates by comparing UID fields and FN/NAME fields during the transform phase. Suspected duplicates are imported into Trello as cards with a Duplicate Flag label, and a deduplication report is delivered to the customer for manual review before deletion. For contacts, UID comparison is definitive; for calendar events, DTSTART plus SUMMARY comparison is used as a proxy. This approach prevents silent duplicate creation while giving the customer final authority over which record to retain.