Migrate from ]project-open[ to Asana

Projects in ]project-open[ are the central acs_objects entity keyed by project_id with status governed by object_status_id. We preserve the full project hierarchy by traversing acs_rels to resolve parent-child project assignments, then map each distinct hierarchy level to a separate Asana Project. Project status (potential, active, closed) maps to a custom status field in Asana since Asana Projects do not have a native status property beyond archiving. The project_name becomes the Asana Project name and description maps directly.

Tasks in ]project-open[ are stored as separate task_id records referencing the project tree with parent-child nesting. We traverse the task hierarchy and flatten sub-tasks into Asana Subtasks linked to the parent Task via the parent_id reference. Task assignment, priority, and due date map to assignee, Custom Field priority enum, and due_on respectively. Any ]project-open[ Task custom attributes are discovered during the pre-migration attribute pass and mapped to Asana custom fields before import.

Companies in ]project-open[ are im_companies objects with company_name, company_status_id, and type classification stored via object_type_id. Asana has no native company or account object. We map company records to Asana Teams (one Team per company) using company_name as the Team name, with company status and type stored as custom fields on the Team or as custom fields on the Projects where that company is relevant. Customer admin reviews and approves the company-to-team mapping strategy during scoping.

Tickets in ]project-open[ use im_tickets with ticket_status_id and ticket_type_id integer keys, plus threaded message history via associated tables. Asana has no dedicated ticket object. We map each ticket to an Asana Task with a ticket_type custom field (single-select enum matching the ]project-open[ ticket_type_id labels), a ticket_status custom field, and assignee from the ticket owner. The conversation thread migrates as Task comments in chronological order. If Service Cloud is active in the destination environment, Case is a better fit and we adjust the mapping accordingly.

Financial records in ]project-open[ live in im_costs with variable_cost_p as a boolean 't'/'f' char field, plus amount, cost_type, and billing_status columns. Asana has no native financial or invoicing object. We map cost and invoice data as custom fields on the Asana Task that represents the corresponding work package: cost_amount (number), cost_type (enum), billable (boolean), and invoice_status (enum). The customer configures these custom fields on the relevant Projects during scoping. Actual invoice PDFs from ]project-open[ are not migratable as standalone records and are delivered as a file inventory for manual re-upload.

Timesheet hours in ]project-open[ are stored as cost entries linked to users and projects, with date, billing type, and hours logged. Asana has no native timesheet object; the Timesheets feature in Asana is a paid feature that tracks time entries without financial cost modeling. We map timesheet data as custom fields on Tasks (hours_logged, timesheet_date, billing_type) and preserve the user-to-project linkage as task assignees. Asana's native time tracking can be enabled if the customer wants time logged within Asana post-migration, but the historical cost values from ]project-open[ are preserved only as metadata.

Users in ]project-open[ are stored across acs_objects and application-specific tables with permissions and group memberships via acs_rels privilege hierarchies. We map user_id, names, and email to Asana Members by email match. The customer's admin provisions Asana user accounts before migration. We flag any ]project-open[ permission or role that has no direct Asana equivalent (OpenACS privilege hierarchies vs Team Member/Admin/Guest roles) in the reconciliation report for admin review. Inactive users are imported as Asana guests if historical assignment records must be preserved.

]project-open[ allows unrestricted dynamic custom attributes per Business Object stored beyond the standard schema columns. These are discovered only by querying the dynamic attribute storage for each object type. We run a full attribute discovery pass against all target object types before designing the mapping specification. Each discovered custom attribute is typed (text, number, date, boolean, enum) and recreated as an Asana custom field. Any formulas, cross-object validations, or computed defaults in ]project-open[ do not migrate — we note them in the handoff document for the admin to implement as Rules or custom fields post-migration.

Offices in ]project-open[ store physical location data and link to companies and projects via acs_rels. Asana has no native location entity. We preserve office name, address, and timezone as text or enum custom fields on the relevant Projects or Teams. The customer decides during scoping whether location is stored per-project or per-team based on their reporting structure.

Categories in ]project-open[ are stored in a hierarchical category system used to classify objects across ticket types, project sectors, cost types, and more. Each category tree has integer category_id values that map to string labels. We resolve all category_id references to their string labels during transformation, then create Asana custom fields of enum type (single-select or multi-select depending on the category usage) with options matching the source labels. Parent-child category hierarchies in ]project-open[ flatten to a flat option list in Asana since Asana does not support hierarchical custom field options.

Documents in ]project-open[ are stored as separate objects with references in acs_objects; binary files may be in the filesystem or database depending on configuration. We identify file storage locations during discovery, extract file references, and migrate document URLs as Asana Task Attachments or as Link fields pointing to the original document repository. Binary file migration requires customer approval and may involve file transfer logistics beyond the standard migration scope.

Configuration items in ]project-open[ track IT assets and their relationships as typed Business Objects with custom attributes. Asana has no native CI or asset management object. We map CI type, key attributes, and any dependency relationships as custom fields on the relevant Task, along with a CI identifier field for reference. The full dependency graph from ]project-open[ is documented separately as a written inventory for the customer's IT team to implement in a dedicated CMDB or asset management tool if required.