Migrate from SmartTask to Asana

SmartTask Projects map 1:1 to Asana Projects. Project name, description, start date, due date, status, and project-level custom fields transfer directly. We map SmartTask project views (Kanban, Timeline, List) to their nearest Asana equivalents (Board, Timeline, List). Project privacy settings map to Asana team visibility settings.

SmartTask Tasks map to Asana Tasks with title, description (rich text), start date, due date, priority, and status preserved. Checklist items in SmartTask map to Asana subtasks. Task dependencies (finish-to-start) in SmartTask map to Asana dependency arrows using the Asana dependency format (predecessor task GID).

SmartTask subtasks and checklists map to Asana subtasks. Nesting depth of two levels or fewer transfers directly; deeply nested hierarchies are flattened with a naming convention prefix to preserve the original structure. Completed-at timestamps on SmartTask checklist items become subtask completion markers in Asana.

SmartTask allows multiple assignees and multiple followers per task. Asana enforces exactly one assignee per task. We designate the primary SmartTask assignee as the Asana assignee, and we create a multi-select custom field called Original Followers (SmartTask) that carries all additional assignees and followers as a comma-separated list. This preserves the full team context for audit without requiring a schema change in Asana.

SmartTask custom fields (string, number, date, yes/no, dropdown) map to their equivalent Asana custom field types. We discover all custom field names and types per project before mapping because SmartTask allows per-project custom field schemas. Fields with the same name but different types across projects are flagged as anomalies and resolved to a single destination type chosen by the customer during scoping.

SmartTask task-level and project-level comments transfer to Asana Task comments and Project comments respectively. Author name, author email, timestamp, and rich text content preserve. Comments on deleted or orphaned SmartTask tasks are flagged for customer review before import to prevent dangling references.

SmartTask tags migrate to Asana Tags. Tag names transfer verbatim. We create tags in Asana before task import to avoid duplicate tag creation during bulk load. Tags used for content classification (not just task categorization) are noted in the migration inventory for the customer's admin to decide on a re-tagging strategy.

SmartTask recurring task rules (daily, weekly, monthly, yearly, custom) and the next-occurrence date transfer to Asana as a recurrence note in the task description plus a custom field Original Recurrence Rule. Asana's native recurrence is documented for the admin to apply manually to key recurring tasks post-migration since Asana recurrence requires explicit rebuild per task.

SmartTask time entries (Business plan and above) with start/end or duration transfer to Asana time tracking entries if the destination Asana workspace has the Timesheets add-on enabled. We map task GID, user, duration in minutes, and date. Time entries without a matching Asana user are held in a reconciliation queue. Note that Asana's native time tracking is an add-on feature not included in all plans.

SmartTask milestones (tasks with a milestone marker) map to Asana Milestones. The milestone name, due date, and associated parent project transfer directly. Custom status values on milestones map to Asana Milestone status options.

SmartTask Task Templates with default field values and checklist structures transfer to Asana as Project Templates. We map template names, default assignees (as placeholder text notes), pre-filled custom field values, and checklist structures (as Asana subtask skeletons). Automation triggers attached to SmartTask templates do not migrate; they are documented in the template inventory for the admin to rebuild in Asana Rules.

SmartTask attachments (Google Drive links, Dropbox links, direct uploads) are exported as file reference records with URL and filename. We flag attachments that require re-authentication to external storage for post-migration relinking. Actual file binaries are not downloaded during migration; the reference record enables the admin to reattach post-migration if needed.