Migrate from Azor to Asana

Azor projects map directly to Asana projects. We preserve the project name, description, creation date, and any folder or group labels as project Tags or a project-level custom field. Because Azor has no workspace or team concept, we ask the customer during scoping which Asana Team or workspace each project belongs to before import. Projects are loaded first as the top-level container so that task imports have a valid parent project ID.

Azor tasks map 1:1 to Asana tasks with title, description, due date, and assignee preserved. The Asana API requires a valid project_gid at task creation, which we resolve from the project mapping. Tasks with no assignee are flagged and left blank or assigned to the migration service account pending reassignment in Asana. Task completion status migrates as a boolean to Asana's completed field.

If Azor's source data contains flattened sub-task records identifiable by a naming convention (e.g., parent task title as prefix) or by a project-specific attribute, we reconstruct the parent-child relationship and import as Asana sub-tasks under their parent task. We flag which records were flattened and document the naming convention used so the customer's admin can verify the hierarchy post-migration. If no identifiable sub-task structure exists in Azor, all tasks are imported as top-level Asana tasks.

Azor tags migrate to Asana Tags. We extract tags as a comma-separated string or array from Azor's export and map each unique tag to an Asana Tag with the same name. Tags that do not already exist in Asana are created at import time. Tags serve as the primary vehicle for carrying Azor attribute data forward since Azor has no native custom field layer.

Azor user display names and email addresses map to Asana Users. We resolve users by email match against the destination Asana organization's user table. Any Azor user without a matching Asana User is flagged in the reconciliation queue for the customer's admin to provision before task import resumes. Role and permission levels are not exposed in Azor's data model and cannot be migrated; we document this gap in the scope document.

Azor's fixed status set per project (To Do, In Progress, Done) maps to Asana Sections within the project or to a custom task-status field depending on the customer's preference. We confirm the preferred mapping during scoping. Any non-standard Azor statuses are flagged for manual review before import to prevent Asana validation errors.

Azor tasks assigned to a single user map to Asana's assignee field. Azor does not support multi-assignee tasks, so no split or merge logic is required. Unassigned tasks in Azor migrate as unassigned in Asana. We resolve assignee references using the User email mapping established in the User object step.

Azor due dates migrate directly to Asana due_date in ISO 8601 format. Tasks with no due date in Azor migrate as null in Asana. We do not migrate time-of-day (due_at) since Azor does not expose time components in its date fields. If the customer needs time tracking on due dates, we recommend setting the due date to the task start and using a custom time field in Asana.

Azor uses a simple project list hierarchy with folder or group labels. We map these labels to Asana Project Tags for visibility, or to Team membership if the customer prefers organizing by Asana Teams. We confirm the organizational preference during scoping. Projects within a folder group maintain their relative order during import.

Azor has no native custom field layer. Any customer-specific attributes stored in text fields, notes, or custom columns in Azor are identified during scoping, documented in a field map provided by the customer, and pre-created in Asana as custom fields before import. We request this field map at least five business days before the migration start date to allow time for Asana custom field schema setup.

Azor does not expose comments via any documented export or API. We cannot migrate task-level discussion history. We include a pre-migration checklist item requiring the customer to acknowledge this data gap and consider a manual export of critical comment threads before the engagement begins. Asana comment history on migrated tasks will start fresh post-migration.

Azor does not expose file attachments via any documented export format. We do not migrate attachments and flag this gap in the scope document. If the customer has attachments stored in Azor, we recommend they download them manually or export them to a shared storage location before migration and re-attach them in Asana post-migration.