Migrate from Fluid to Trello

Fluid Projects map directly to Trello Boards. Each Fluid project becomes a Trello board with the project name, description, status, and date range preserved in the board description or as a card. We extract the project owner and assign them as a board admin. Projects with a Program parent do not have a native Trello container; we agree on a workspace-reorganisation strategy during scoping (workspace per program, label per program, or board naming convention). Archived Fluid projects require explicit flagging since Trello boards have no native archive state.

Fluid Programs are top-level groupings of related projects with no direct Trello equivalent. We agree on a workspace-per-program or label-per-program strategy during scoping. Each Fluid Program maps to a Trello Workspace (if the customer has multiple workspaces) or a consistent label prefix (e.g., 'Program: [Program Name]') applied across all boards in the migration. Program-level description, owner, and date range are preserved as board-level metadata or as a pinned card within the first board of the group.

Fluid Portfolios aggregate Programs across an organisation and carry portfolio-level KPIs, budget, and strategic status. Trello has no portfolio object. We document the portfolio-level record as a written scope item and propose a Trello Workspace with a portfolio-overview board containing status-tracking cards for each program, or a label-based reporting strategy using Trello Standard or Premium for multi-board reporting views. This is a structural gap requiring admin-level decision-making before migration.

Fluid Tasks with standard fields (name, description, status, start/end dates, assignees, priority) map to Trello Cards. We extract the task name as the card title, description as the card body (markdown preserved), and status as the target list within the board. Start and end dates require Trello Premium for card dates; without Premium, we map them to a label or card description. Subtasks inherit fields from their parent and are handled by the Subtasks mapping row.

Fluid Subtasks map to Trello checklist items within the parent Card (preferred for simple subtasks) or as child Cards on the same board (preferred if subtasks carry custom fields, due dates, or assignee changes). We flatten the parent-child hierarchy into a 'Parent: [Task Name] | Subtask: [Subtask Name]' card title for child Cards and resolve the relationship via label or link. The customer chooses the strategy during scoping based on how subordination is used in Fluid.

Fluid task assignees map to Trello Card Members. We extract the user identity from Fluid's task assignment and resolve it by email match against Trello workspace members. Members without an active Trello account go to the reconciliation queue for admin provisioning before the migration phase begins.

Fluid Custom Fields (text, number, date, picklist, boolean) map to Trello Custom Fields if the destination workspace has Trello Premium enabled. We read the Fluid field type during discovery and pre-create the corresponding Trello Custom Field before migration. On Trello Free or Standard, we map picklist fields to Labels (up to 25 per board) and text/number fields to card description appends. Custom field data is migrated as structured metadata in our staging layer so the correct format is applied regardless of the target tier.

Fluid stores task start and end dates that drive its Gantt visualisation. We extract these as standard date values and map them to Trello Card Start Date and Due Date fields. Trello Premium is required for native date fields on cards; Standard and Free tiers store dates in card description or labels only. The Gantt layout itself is a UI construct and cannot be migrated. We note this gap in the scope document and advise customers that Trello Timeline view (Premium) can approximate a Gantt-style view but requires the card date fields to be populated first.

Fluid live effort metrics (hours-consumed versus planned, effort tracking per task) map to Trello Custom Number fields. Trello does not have a native effort or time-tracking field, so we create a custom field (e.g., 'Hours Spent') on the Card object. Customers who rely on effort data for resource reporting should note that Trello does not aggregate effort across cards natively; a Power-Up or external time-tracking tool (Toggl, Harvest) is required for reporting-level aggregation.

Fluid computes workload distribution charts at runtime by aggregating task assignments and effort metrics. These visualisations are not stored as discrete records with a documented export path. We flag this during scoping and note that the underlying task assignment data is transferable; only the computed chart output cannot be migrated.

Fluid's Flex Statistics mode stores scenario-modelling and what-if planning data in a proprietary analytical format with no documented export endpoint. This is a platform-level limitation documented in the Fluid source page. We do not attempt to migrate Flex Statistics data and document this gap explicitly in the migration scope before work begins.

Fluid does not include native meeting management features, so there are no meeting records to migrate. Teams relying on Fluid for agenda preparation, meeting notes, or action-item capture should plan to use a dedicated meeting tool post-migration. Trello offers native meeting capture via Lozio, an Atlassian product integrated with Trello and Confluence.

Fluid time-entry records migrate to Trello Custom Number fields (Hours Logged, Hours Remaining) on the Card. Trello has no native time-tracking object. For customers with significant time-entry histories, we recommend a post-migration evaluation of Trello Power-Ups (Time Tracking by BlueCat, or similar) or a dedicated time-tracking integration with Toggl or Harvest.

Fluid attachments on tasks (files, linked documents) migrate as Trello Card Attachments. Trello imposes a 250MB per-file limit. We flag files exceeding this limit during discovery. Attachments are downloaded from Fluid and uploaded to Trello via the API with retry logic on rate-limit responses. Large boards with hundreds of attachments require chunked processing to avoid the memory-constraint issues documented in community migration tooling discussions.