Migrate from Float to Jira

Float Projects map to Jira Projects as the top-level container. Project name, status (active vs archived), client association, and start/end dates migrate. Jira Project key and type (team-managed or company-managed) are configured during Jira setup. Projects with no end date in Float are created as ongoing Jira projects with no target date set.

Float People records map to Jira User accounts. We resolve by email match. Float role and department assignments migrate as custom fields on the Jira User since Jira's native user properties do not include a role field. Inactive Float People are imported as Jira users with inactive status to preserve historical assignment data. The migration user must have Jira Admin rights to provision users in bulk.

Float Tasks map to Jira Issues with the task type determined by the Task name or a Float custom field tag. Float assigned hours become Jira Original Estimate (in hours). Float start and end dates map to Jira Due Date; the Jira start date field is available via the Jira automation or a custom field. Assignee resolves via the People-to-User mapping. Jira does not have a direct equivalent to Float's placeholder-based scheduling; tasks assigned to Placeholders in Float are either reassigned to real users or flagged in a custom field during migration.

Float Clients group Projects for billing and reporting. Jira does not have a native Client object. We map Client to Jira Labels on the Project or to Components within the Project, depending on the customer's reporting needs. The chosen strategy is confirmed during scoping. Multi-client projects in Float create a comma-separated label in Jira or multiple Component entries.

Float Departments group People and affect capacity rollup views. Jira does not have a native Department concept. We map Department to a custom User field or Jira Group membership, chosen based on whether the department structure is used for permissions (Group) or reporting (Custom Field). Jira Group names must be unique and are validated against the existing Jira group list during scoping.

Float Roles categorize People (Developer, Designer, PM) and affect availability filtering. Jira Project Roles (Developers, Administrators, Users) are application-level and not directly equivalent. We map Float Role to a custom User field and optionally create Jira Project Roles with matching names. The customer selects the preferred approach during scoping based on whether the role data is used for permissions or reporting.

Float Time Entries (Pro and above) record actual hours logged against Tasks. We map to Jira Worklogs via Tempo Timesheets if the customer has or will add Tempo to their Jira subscription. If Tempo is not in scope, Time Entry hours and dates are preserved as Jira Issue Comments with a structured format (date, hours, notes) for later extraction. Historical time entries that fall outside Jira's reporting periods are flagged but still migrated as Worklogs.

Float Time Off blocks capacity for People on specific dates. Jira has no native time-off or absence management feature. We do not migrate Time Off as it has no target destination in standard Jira Software Cloud. If the customer uses an absence management add-on (such as Tempo Vacation or an Atlassian Marketplace absence app), Time Off can be mapped during scoping. Otherwise, Time Off is excluded from the migration scope and documented as a gap.

Float Placeholders represent unconfirmed hires or temporary workers. Jira has no placeholder concept — every user must be a provisioned account. During scoping, we identify all Placeholders and the customer decides: convert to a real Jira User account (provisioned and marked inactive), carry as a custom field value on a real User record, or exclude from migration. Leaving Placeholders as-is in Float during migration preserves them for later resolution.

Float custom fields on People and Projects are discovered via the custom-fields API endpoint before extraction. We map text, number, date, and select fields to equivalent Jira custom field types. Multi-select picklist options from Float map to Jira options. Custom fields that cannot be mapped (due to incompatible types) are flagged with a schema recommendation. Jira requires Admin rights to create custom fields, which we coordinate with the customer's Jira admin during setup.