Migrate from Fluid to Asana

Fluid Programs are top-level groupings of related Projects. Asana has no native Program object. We map Programs to Asana Teams (where the Team name matches the Program name and the team scope controls project visibility) or to a custom multi-select or text field Program_Group__c on Projects. The customer chooses the strategy during scoping based on whether Program-to-Program reporting is required. If Program-level reporting is needed, we recommend using a dedicated Asana Portfolio with a custom field for Program attribution.

Fluid Projects map directly to Asana Projects. Project name, description, status (active, on-hold, complete), start date, end date, and owner assignment migrate to Asana Project fields. The Project's parent Program relationship is resolved via the Team mapping or the Program_Group__c custom field. Projects are created before Tasks so that parent references are satisfied at insert time.

Fluid Tasks carry name, status, start/end dates, assignees, priority, and notes. We map these to Asana Task fields with a direct 1:1 transform for standard fields. The subtask nesting structure in Fluid is preserved as a flattened set of Task records with a parent_id reference field so Asana's native subtask hierarchy can be reconstructed in the destination. Task-level start dates in Asana require a Premium plan or above (Starter does not include start dates); we flag this tier constraint during scoping if the customer's Fluid plan supports start dates.

Fluid Subtasks inherit fields from their parent Task. Asana natively supports subtasks. We map each Fluid Subtask to an Asana Subtask linked to the parent Task via the parent-task relationship. Subtask-level custom fields migrate as-is if the destination project includes those field definitions. If a Fluid Subtask carries fields not present on the parent Task, we add those field definitions to the destination project before import.

Fluid Custom Fields are supported but require a pre-migration schema review to determine field type (text, number, date, picklist, boolean, multi-select). We generate corresponding Asana Custom Fields in the destination project, mapping type for type. Multi-select fields in Fluid map to Asana multi-select. Boolean flags in Fluid map to Asana checkbox or single-select with two options. If a Fluid custom field uses a data type not natively supported in Asana (for example, a Fluid-specific formatted number), we flag this during scoping and either create a text-equivalent custom field or discuss a type-conversion approach with the customer.

Fluid assigns Tasks to named users. We extract the user identity (display name and email) from Fluid's assignee data and map it to the Asana Task assignee field. Asana assigns one user per Task (Fluid supports single assignee per Task as well). We resolve assignees by email match against the Asana workspace User list. Any assignee with no matching Asana User goes to a reconciliation queue for the customer's admin to provision before the import phase continues.

Fluid stores hours-consumed and planned-effort per Task as numeric fields. Asana does not include a native effort-tracking object on Starter or Advanced tiers. We map Fluid effort fields to Asana numeric Custom Fields (Effort_Planned__c, Effort_Actual__c, Hours_Logged__c) created on the destination projects. Asana's native Timeline view then displays these as custom columns. If the customer requires a native time-tracking interface (start/stop timer, timesheet approval), we flag that this requires Asana's Enterprise+ time-tracking add-on or a third-party integration and note it in the migration scope as a post-migration recommendation.

Fluid stores Task start and end dates that drive its Gantt visualisation. We extract these as standard date fields (start_date, due_date) and map them to Asana Task Start Date and Due Date. Asana's Timeline view reconstructs a Gantt-style display from these fields. The Gantt layout itself is a UI construct in Fluid and does not migrate; the underlying schedule data transfers completely.

Fluid computes workload distribution charts at runtime by aggregating Task assignments and effort metrics. These visualisations are not stored as discrete exportable records. We do not attempt to migrate workload distribution data. We flag this gap in the migration scope and note that Asana's Workload view (available on Business tier at $24.99/user/mo) requires manual reconfiguration of resource allocation rules.

Flex Statistics mode in Fluid stores scenario-modelling and what-if planning data in a proprietary analytical format with no documented export endpoint. We do not migrate Flex Statistics data. We document this gap explicitly in the migration scope before work begins and advise the customer to export any scenario outputs as PDF or screenshot for manual reference.

If Fluid stores discrete time-entry records (timestamped log entries, not just effort fields), we map these to a custom time-entry structure in Asana. Asana's native data model does not include a time-entry object, so we create a dedicated Time_Entry__c custom object in Asana with fields for Task_Lookup__c, User__c, Hours__c, Date__c, and Notes__c. If the customer uses Fluid's effort metrics as a simpler timesheet, the numeric effort fields covered in the Effort Metrics mapping may suffice without a separate entry record.

Task attachments (documents, images, links) stored in Fluid migrate as Asana task attachments. Asana's API accepts file attachments with a 100MB per-file limit. We flag any Fluid attachments exceeding this size during the pre-migration audit and skip them with a documented exception report for the customer's admin to handle manually.