Migrate from Accolade to Asana

Accolade Portfolios are top-level organizational containers with linked Projects, budget allocations, and strategic alignment tags. We map these to Asana top-level Projects within a designated Team. Portfolio metadata (description, strategic alignment tags, budget values) migrates as Project Description and custom fields on the Project. Portfolio roll-up reporting (portfolio-level KPIs) does not migrate as a native report; we deliver a custom field schema and documentation for rebuilding in Asana Dashboards.

Accolade Projects are the primary execution units linked to a Portfolio. We map these to Asana Projects (or Sections within the parent Portfolio-Project) depending on the customer's desired hierarchy depth. Project metadata (stage, status, owner assignment, start and end dates, custom properties) migrates to Asana Project fields and custom fields. Project-Project parent-child lineage from Accolade's portfolio structure is preserved as Section nesting or tag-based grouping.

Accolade Innovations represent early-stage ideas with originator, submission date, scoring attributes, and workflow state. Asana has no native Innovation object; we map Innovations to Tasks with custom fields capturing originator (Asana assignee), submission date, scoring values, and workflow state (custom field). Innovations linked to a parent Project migrate as Tasks within that Project. Innovations without a parent Project are placed in a dedicated 'Innovation Pool' Asana Project.

Accolade's Innovation-to-Project promotion does not always preserve the parent-child link in exports. During schema analysis, we detect this pattern by matching on creation date, originator, and naming convention. We reconstruct the lineage and present orphaned records to the customer for manual review. For confirmed parent-child pairs, we create a Task in the original Project representing the Innovation and link it to the newly created Project via a custom field innovation_parent_project__c.

Accolade Business Units are organizational entities used for segmentation and reporting. We map these to Asana Teams. Multi-level BU hierarchies are flattened during export; the top-level BU becomes the Team name, and sub-BUs are preserved as tags or custom fields for cross-referencing. Each Team in Asana contains its own Projects and tasks, preserving data isolation preferences if the customer chooses team-scoped visibility.

Accolade supports user-defined fields on Projects and Innovations with field types including text, number, date, picklist, and multi-select. We extract the full schema including field type, required flag, and picklist options. At import time, we create matching custom fields in Asana's organization field library. Since Asana custom fields are organization-wide (not per-project), we add them to the relevant project views. Fields that exist in Asana but not in Accolade for a given BU are left null and logged in the field-coverage report.

Accolade allows different Business Units to define different custom property sets on the same object. A single migration must reconcile these schemas. We merge all unique custom fields into a superset. For each record, we populate whichever fields apply based on its BU assignment. Fields that apply to one BU but not another appear empty for records from the BU that doesn't use them. The field-coverage report documents which fields are populated per BU for the customer's admin to act on.

Documents and files attached to Accolade projects and innovations are exported with original filenames, MIME types, and content. Files under 100MB transfer via Asana's file upload API and re-attach to the corresponding task. Files over 100MB are chunked during extraction and reassembled on the destination side with SHA-256 checksum verification. Transfer manifest logs all files including chunked ones. Note: Asana does not support attachments over 100MB; any file exceeding this limit is flagged in the pre-migration audit and held for customer decision.

Accolade uses configurable workflow stages with gate approvals. Each stage has a name, order, and optional approver assignment. Asana has no native workflow stage gate object; we map stages to Sections within a Project, ordered to match the original stage sequence. Gate approvals do not migrate as logic; we document each gate (name, approver, criteria) in a written Workflow Inventory for the customer's admin to rebuild using Asana Rules or a third-party approval tool.

Accolade user accounts include name, email, role, and BU assignment. We export the user roster and match by email against the Asana destination workspace. Accolade roles map to Asana roles as follows: Administrator → Organization Admin, Portfolio Manager → Team Admin, Project Manager → Project Admin, Innovator → Member, Viewer → Member (Guest for external users). Inactive Accolade users are provisioned as inactive Asana users to preserve historical assignment references.

Accolade audit comments and activity history are stored as timestamped entries linked to a project or innovation. We export these as a flattened feed and migrate them to Asana Task Comments on the corresponding task. Each comment retains its timestamp, author, and text body. Activity log entries that represent system events (stage change, status change, approval) are added as comments with a [System] prefix so the admin can identify them during review.

Accolade tracks quantitative metrics against projects such as budget consumed, schedule variance, and custom KPIs as numeric time-series values. We export them as structured key-value records. In Asana, we create numeric custom fields on the Project and populate the current metric values as field values. Historical time-series data is exported as a separate CSV and documented as a supplemental data file for importing into a BI tool or Asana's native reporting if the customer adopts a reporting integration.

Accolade governance gates enforce approval at stage transitions. Asana has no native gate approval object. We do not migrate governance gates as logic. We extract every gate definition (name, stage, approver, criteria, rejection action) and deliver a written Governance Gate Inventory listing each gate with its recommended rebuild approach using Asana Rules, a third-party approval tool (like Nintex or a Zapier-based approval flow), or manual process. The customer's admin rebuilds gates post-migration.