Migrate from Fruux to Microsoft Project

Fruux VTODO components map to Microsoft Project Task records. The VTODO SUMMARY maps to the Task Name field, VTODO DUE-DATE maps to Finish, and completion status (VTODO STATUS:COMPLETED) maps to % Complete = 100. Fruux task descriptions migrate as MS Project Task Notes. Priority from Fruux custom fields maps to MS Project Priority (1-10). Recurring VTODO items expand into MS Project summary tasks with subordinate sub-tasks. If multiple Fruux task lists exist, we merge them into a single MS Project plan and flag the merge for customer review.

Fruux VEVENT entries (iCalendar calendar events) map to MS Project Tasks with the event date as the scheduled start and finish. VEVENT SUMMARY becomes Task Name; VEVENT DESCRIPTION becomes Task Notes. Recurring VEVENT RRULE values expand into individual MS Project tasks on each occurrence date. Calendar subscriptions (webcal/ics feeds) are exported as .ics URLs and re-registered as MS Project calendars if the customer licenses Project Online or Project Desktop.

iCalendar subscriptions (webcal/ics feeds) from Fruux appear as read-only calendars. We export them as .ics files and import them into Microsoft Project as separate base calendars. If the subscription URL is private or requires authentication, the customer must provide access. MS Project calendars define working days and hours, holidays, and resource availability, which Fruux does not model.

Fruux Contact records (vCard RFC 6350) do not have a direct MS Project equivalent. Microsoft Project uses Resources as people or equipment assigned to tasks, which is a different semantic model from address book contacts. We extract Fruux contacts as a vCard export for the customer to import into Azure AD, Outlook Contacts, or SharePoint as appropriate. If the customer wants contacts available as Resources in MS Project, we map them to Resource records using the vCard FN (full name) and EMAIL fields, but this requires the customer to confirm that every Fruux contact is a project participant.

Fruux supports multiple task lists per user. Microsoft Project does not have an equivalent multi-list concept within a single plan. We merge all Fruux task lists into a single MS Project plan, using the original task list name as an MS Project Summary Task at the top of each group of tasks, preserving the organizational grouping. The customer reviews the grouping during Sandbox validation.

Fruux Notes are stored in a proprietary format not accessible via CardDAV or CalDAV. We attempt export via web API scraping where accessible, but cannot guarantee full content or formatting fidelity. For VEVENT descriptions and VTODO notes that are embedded in the iCalendar stream, we extract and map them to MS Project Task Notes. Standalone Fruux Notes without a parent event or task are exported as a separate text file for manual insertion.

Fruux Bookmarks are stored in a proprietary internal format with no public export specification. Microsoft Project has no bookmark concept. We do not attempt to migrate Bookmarks. We notify the customer during scoping and recommend exporting Bookmarks from the Fruux web interface manually before the migration window.

Fruux CardDAV addressbook-home-set collections map to a single MS Project Resource Sheet if the customer chooses to surface Fruux contacts as project resources. Each vCard FN becomes a Resource Name, EMAIL becomes Resource Initials or a custom field, and TEL becomes a custom text field on the Resource. Address book groupings (e.g., 'Team', 'Vendors') become MS Project Resource Groups.

Fruux VEVENT components with RRULE (recurrence rules) expand into Microsoft Project recurring tasks. We parse the RRULE frequency (DAILY, WEEKLY, MONTHLY, YEARLY) and interval, and generate the corresponding MS Project recurrence pattern on the target Task. Exception dates (EXDATE) in the VEVENT are excluded from the recurrence series. COUNT limits and UNTIL termination dates are honored.

Fruux's conflict resolution creates server-side copies when the same record is edited on multiple devices simultaneously. These copies appear as duplicate VTODO or VEVENT entries after export. We detect duplicates by comparing UID fields and SUMMARY fields, flag suspected duplicates for customer review before deletion, and import only the most recently modified version. This step adds processing time proportional to the number of conflict artifacts present.