Migrate from Artemis 7 to Asana

Artemis 7 Projects map directly to Asana Projects. Project name, description, status, start date, and target end date migrate as-is. We use the Asana Projects API (POST /projects) to create each project. Active/inactive status in Artemis 7 maps to the project's archived flag in Asana.

Artemis 7 Tasks migrate to Asana Tasks with name, assignee, start date, due date, estimated hours, and status preserved. Parent-child relationships in Artemis 7 (subtasks) migrate as Asana Subtasks (a task within a task) using the subtask nesting structure. We reconstruct the full task tree during import and verify parent_id references are resolved before committing.

Artemis 7 Milestones are date-driven markers associated with a Project. We create Asana Milestones using the Asana Milestones API (POST /milestones) linked to the parent project. Milestone name and due date migrate directly; Artemis 7 milestone owner maps to an Asana task assignee on the milestone task itself.

Artemis 7 Resources contain user name, role, and availability (hours or percentage). Asana does not have a dedicated resource pool; instead, assignments are made directly on tasks via the tasks/addProject or membership endpoints. We map resource availability to task assignments in the workload view. Availability hours convert to estimated hours on tasks; percentage allocation maps to a workload entry.

Artemis 7 time entries (hours logged against a task and user) migrate to Asana time tracking entries using the Asana time tracking API. We ask the customer to confirm whether billing rates and billable flags should migrate as custom fields on the time entry or remain in a separate sheet. Asana's time tracking is per-task and per-user.

Artemis 7 stores Gantt dependencies as relationship metadata (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish). Asana Timeline supports Finish-to-Start dependencies natively. Start-to-Start and Finish-to-Finish are not native; we flag these as unsupported, convert them to Finish-to-Start with an adjusted offset date where possible, and deliver a dependency change-log so the customer can manually verify the adjusted dates.

Artemis 7 custom fields are defined per-project. We consolidate unique field names across all active projects during scoping, resolve data type conflicts (e.g., two fields named Priority but one is text, one is picklist), and create global Asana custom fields for each unique, non-conflicting field. Conflicting fields are renamed with a project prefix and mapped per-project during import.

Artemis 7 user records (name, email, role) map to Asana Workspace members. We match by email. The customer must provision Asana accounts for any Artemis 7 user without an existing Asana account before migration. Inactive Artemis 7 users are imported as deactivated Asana users for historical record continuity.

Artemis 7 task groupings or task lists within a project map to Asana Sections. Section name and task ordering migrate directly. Sections provide grouping in Asana List view equivalent to Artemis 7's task list view.

Artemis 7 task tags migrate to Asana Tags using the tags API. Tags are workspace-level in Asana and can be applied to multiple projects. Tag names migrate as-is; tag colors are not preserved unless the customer provides a color map.

Artemis 7 stores attachments as URLs to its own internal file service. These URLs expire or break when the account is deprovisioned. We do not include attachment URLs in the migrated dataset. We extract every attachment reference, map it to the parent task, and deliver a CSV listing task name, file name (from URL), and file type so the customer can manually re-upload each file to Asana or a linked storage service.

Artemis 7 includes risk tracking as a standard feature. Asana has no native risk object. We ask the customer to choose: risks migrate as tasks in a dedicated Risks project with a risk-type custom field, or risks migrate as a custom field on the related project task. We do not assume the data model.