Migrate from Float to Asana

Float People records map to Asana Members. We preserve name, email, department assignment, and role. Float's cost_rate and bill_rate fields have no native Asana equivalent and migrate as custom fields cost_rate__c and bill_rate__c on the Member or as project-level custom fields depending on where the customer wants the data visible. Any People record flagged as a Float Placeholder is held in a reconciliation queue; we create a custom multi-select picklist placeholder_type__c with values confirmed and unconfirmed, set the Asana Member to inactive, and document the queue for the admin to resolve manually before go-live.

Float Departments map directly to Asana Teams. The mapping is one-to-one using the department name as the Team name. All People assigned to a Department inherit the Team membership in Asana, which enables the Workload view to filter by team during capacity analysis. If the customer uses multi-department reporting, we also create a custom field original_department__c on each Member to preserve the source data if Team names change post-migration.

Float Roles (Developer, Designer, Strategist, etc.) have no native equivalent in Asana. We create a multi-select picklist custom field called role__c on the Asana Member object. Role assignments migrate as selected option values. If the customer's Float account uses Roles as scheduling constraints (e.g., only Developers can be assigned to Development tasks), we document the constraint logic in a Roles and Permissions matrix so the admin can recreate it using Asana's custom fields or a third-party resource management integration.

Asana has no native Client object. We create a single-select picklist custom field client_name__c on the Asana Project. Each Float Client maps to an option value in that picklist. If the customer has more than 50 Clients, we recommend using a text field instead to avoid picklist value limits, or grouping by Client into Asana Portfolios where the Portfolio name matches the Client. The mapping choice is made during scoping based on the Client count and the customer's reporting structure.

Float Projects map to Asana Projects. We preserve the project name, status (active, archived), start date, and end date. The Float project status maps to an Asana project membership and visibility setting. Archived projects migrate as archived Asana projects where the destination plan supports archiving (Starter and above). Client association is preserved via the client_name__c custom field described above.

Float Placeholders represent unconfirmed hires or future team members and are constrained by plan tier (1 on Starter, 5 on Pro, unlimited on Enterprise). Asana has no placeholder equivalent. We migrate Placeholder records as inactive Asana Members with a custom field placeholder_type__c set to unconfirmed. The inactive status prevents them from appearing in assignee dropdowns by default. The admin reviews the reconciliation list post-migration and either converts confirmed placeholders to active members or excludes them from the final migration. We flag this queue explicitly in the migration scope document before data movement begins.

Float Tasks map to Asana Tasks. We preserve task name, description (notes), start date, end date, and assignee. Float's assigned hours migrate as a custom field estimated_hours__c on the Asana Task. Float's planned hours vs actuals (available on Pro and above) map to estimated_hours__c and actual_hours__c custom fields respectively. Float task notes migrate to Asana task descriptions. Section and subtask hierarchy in Float migrates to Asana sections and subtasks respectively.

Float's schedule exports contain People allocated to Tasks with date ranges and scheduled hours. We map start_date and end_date from the schedule export to the Asana Task start date and due date, which renders the allocation in the Timeline view. Float CSV schedule exports are constrained by date-range selection; we handle multi-range stitching by chunking large schedules into weekly or bi-weekly exports, deduplicating on task_id and date, and reassembling before load. The scheduled hours from the schedule export populate the estimated_hours__c custom field.

Float Time Entries record actual hours logged against Tasks. Asana has no native time tracking object. We migrate time entry data as a custom field actual_hours__c on the relevant Asana Task, populated from the Float time entry hours and date. For customers with high time-entry volume (over 10,000 records), we offer a separate time entry reference sheet as an alternative to bulk custom field population, since Asana custom field writes at scale against the API have lower throughput than standard record imports. The customer chooses the strategy during scoping.

Float Time Off records block capacity for specific People on specific dates and affect utilization calculations. Asana has no native time-off object. We export Time Off records as a structured CSV with person, start date, end date, and type (vacation, sick, personal). The customer can use this to configure a calendar integration (Google Calendar or Outlook) or an HRIS sync (Rippling, BambooHR) post-migration. We do not import Time Off as Asana tasks since that would distort project planning data.

Float supports custom fields on People (text, number, date, multi-select). We discover the full custom field schema via the Float custom-fields API endpoint before extraction and map each field type to the equivalent Asana custom field format. Multi-select picklists in Float map to multi-select picklists in Asana. Number fields map to number fields. Text fields map to text fields. We deploy the Asana custom fields to the Member object via the API before member import begins.

Float supports custom fields on Projects with the same type set as People custom fields. We discover the full project custom field schema during the pre-migration discovery phase, create equivalent fields on the Asana Project object, and map values during project import. Project custom field values that reference People (e.g., Project Manager as a person custom field) require a lookup resolution step to convert the Float person ID to the Asana Member GID before insert.

Float task groupings within a Project (called Sections in Float's UI) map directly to Asana Sections within a Project. Section order is preserved by the sequence field. Tasks within each Section migrate with their section membership intact.

Float Tags on Tasks map to Asana Tags. Tags used for content classification can alternatively map to Asana Topics with TopicAssignment records. The customer chooses the tag strategy during scoping. If Tags are used for categorization across multiple object types (Projects and Tasks), we recommend Tags as the simpler mapping.