Migrate from Allegra to Asana

Allegra Items map directly to Asana Tasks. Item name becomes Task name; Item description becomes Task notes (rich text). We resolve the parent-project context from Allegra's folder or workspace structure and create a corresponding Asana Project before inserting Tasks. Subtasks within Allegra Items map to Asana subtasks via the parent_task relationship. Item status (active, completed, archived) maps to Task completion status in Asana.

Allegra attributes belong to Items natively and differ from form fields. We query the Allegra schema endpoint to retrieve all attribute definitions and their data types, then configure corresponding Asana custom fields within each destination Project. Text attributes map to Asana text custom fields; date attributes map to date custom fields; numeric attributes map to numeric custom fields; list attributes map to enum (single-select) or multi-enum (multi-select) custom fields based on whether the Allegra list allows multiple selections.

Allegra form fields belong to input forms rather than Items. We extract form field definitions separately from Item attributes and treat them as Asana Forms (for intake workflows) or custom fields scoped to the relevant Project. Form field types map to Asana custom field types. Note that Asana Forms require manual setup in the UI; we create the form structure in our written inventory and the customer's admin builds the form from that template post-migration.

Allegra attachments reside on the filesystem under ALLEGRA_HOME and are not stored in the database. We export the ALLEGRA_HOME attachments directory alongside the database export, preserving the directory structure that maps Items to their file references. During Asana import, we upload each file via the Asana attachments API (POST /tasks/{task_gid}/attachments) and associate it with the correct Task by matching the original Allegra Item identifier embedded in the file path. We validate that file sizes are within Asana's 100 MB per-attachment limit and flag any files exceeding that threshold.

Allegra custom lists with list entries accessible via GET /v2/lists map to Asana enum (single-select) or multi-enum custom field options. We retrieve all custom list definitions and entries via the Allegra REST API and create corresponding option sets in Asana custom fields. If the custom list is used across multiple Projects, we create the field as a portfolio-level or team-level custom field in Asana to avoid duplicating option sets.

Allegra users and roles export from the database with user identifiers and role assignments. We match users by email address against the destination Asana workspace. Any Allegra user without a matching Asana user account is added to a reconciliation queue; the customer's admin provisions the missing Asana accounts before record migration resumes. Role assignments (admin, member, viewer) map to Asana team membership levels.

Allegra Items support parent-child relationships for multi-level hierarchies. We traverse the Item hierarchy during extraction and map top-level Items to Asana Tasks, child Items to Asana subtasks (via the parent_task field), and any further nesting to subtasks of subtasks. Asana supports up to four levels of subtasks natively. We flag any Items with more than four levels of nesting and collapse the deepest level to maintain hierarchy within Asana's constraint.

Allegra can import Microsoft Project (.mpp) and Project Libre files and attempts to recognize existing tasks. We handle MS Project file parsing separately: we extract tasks, task hierarchy (summary tasks and subtasks), start dates, finish dates, and resource assignments from the exported Allegra structure. These map to Asana Tasks with subtasks and start/due dates. MS Project task assignments map to Asana Task assignees resolved against the User mapping.

Allegra does not expose a public API endpoint for activity history or comments, and internal engagement records are not guaranteed to be accessible via the REST API in all deployments. We attempt to extract Item-level notes and activity entries from the Allegra database where available. These map to Asana Stories on Tasks. If the database schema does not expose comment records, we document this gap in the migration report and note that activity history requires manual export from the Allegra UI.

Allegra organizes Items within folders and workspaces. We extract the folder and workspace hierarchy and map it to Asana Projects and Teams. A top-level Allegra workspace maps to an Asana Team; Allegra folders within workspaces map to Asana Projects. We preserve the folder order as project order within the Team.

Allegra workflows and status definitions do not have a migration equivalent in Asana's data model. We do not migrate workflows as code. We extract the Allegra workflow state definitions (status names, transitions, and any conditional logic) and document them as a written specification for rebuilding in Asana Rules or as a custom status field with section-based workflows. The customer's admin uses this specification to configure Asana sections and status-tracking custom fields post-migration.

Allegra form definitions (input forms with field sets, field types, and conditional visibility) do not migrate directly to Asana Forms. We extract form definitions including field names, types, and conditional logic from the Allegra schema and deliver them as a written form template. The customer's admin recreates the form in Asana's Form builder using the template. Form responses stored as Item records in Allegra migrate as completed Tasks with the form field values stored in corresponding custom fields.