Migrate from raidlog.com to Asana

raidlog.com Projects are the top-level container for all RAID records. We map each Project to an Asana Project, preserving project name, description, start date, target date, and owner assignment. If the source has multiple Private Workspaces, we map each into an Asana Team so that access controls are preserved at the team level. The project hierarchy (projects nested under portfolios or groups) reconstructs as Asana Portfolios and Teams.

Each raidlog.com Risk record maps to an Asana task within a dedicated Risk project. We preserve ID, title, description, probability, impact, status, owner, and due date as custom fields on the task. The calculated risk score (probability multiplied by impact) migrates as a numeric custom field value since Asana does not support native formula fields on tasks. The owner assignment resolves via email lookup to an Asana user.

Each raidlog.com Action Item maps to an Asana task within an Actions project. We preserve assignee, due date, priority, status, and the linked risk or issue reference as a text field noting the original RAIDLOG linkage. Status values (Not Started, In Progress, Complete) map to Asana task completion state. If the source Action Item references a parent Risk or Issue, we create a linked-task reference in Asana by storing the original RAIDLOG record ID in a custom field.

Each raidlog.com Issue record maps to an Asana task within an Issues project. We preserve description, severity, status, owner, and resolution date as custom fields. Severity levels map to a custom picklist with values matching the source (Low, Medium, High, Critical). Resolution date migrates as a custom date field since Asana task completion does not capture a separate resolution timestamp.

Each raidlog.com Decision record maps to an Asana task within a Decisions project. We preserve owner, date made, date due, status, and rationale as custom fields. The rationale field (often a longer text description) migrates to the task description field in Asana. Linked project reference from RAIDLOG preserves as a custom field storing the source project name and record ID.

RAIDLOG Dependencies log inter-item relationships (e.g., Risk A blocks Action B). Asana has no native dependency object. We reconstruct each dependency as a linked-task reference stored in a custom text field on the dependent record, noting the type, title, and record ID of the blocking item. The customer's PMO team manually recreates these as Asana task dependencies if Asana's dependency feature is enabled on their plan.

Lessons Learned is a supplementary log type in RAIDLOG but has no dedicated API endpoint. We extract Lessons Learned from the All RAID endpoint and tag each entry with a Lesson tag. In Asana, we create a dedicated Lessons Learned project and add entries as tasks with the original source project name and context stored as custom fields. The AI Risk Predictor and Lessons Learned engine data from RAIDLOG Core does not migrate as structured data; narrative entries carry over as task descriptions.

Change Log entries capture project change requests with requester, date, status, and description. No dedicated Change Log API exists in RAIDLOG; we reconstruct entries from the All RAID endpoint. Each entry maps to an Asana task in a Change Log project with requester as assignee, date as start date, status as custom field, and description as task notes.

RAIDLOG tags apply to any RAID record. We extract the full tag taxonomy via the Tags API and apply explicit value mapping during Asana import. Tag naming conventions differ between platforms; we flag any naming conflicts and suffix duplicate names with an underscore. Tags used for RAID classification (Risk, Action, Issue, Decision) map to project-level tagging rather than task tags to match the migration architecture.

Users are referenced by ID across Risks, Actions, Issues, and Decisions as the assigned Owner. We map RAIDLOG user IDs to Asana users by email address match. Any Owner without a matching Asana user account goes to a reconciliation queue for the customer's admin to provision before record import resumes. Private Workspace membership maps to Asana Team membership based on the workspace-level access configuration.

The Contact and Stakeholder List is a supplementary RAIDLOG component. We export it as a distinct record set and map it to Asana team membership with stakeholder role noted in the user profile or a custom field. External stakeholders who do not need Asana access are flagged separately for the customer to manage outside the platform.

RAIDLOG's grid UI supports linking to external files but exposes no native file attachment API. We export the file reference URL and flag the record as requiring manual re-link in Asana. Any documents stored externally and linked in RAIDLOG migrate as a text URL field on the corresponding Asana task, and the customer's team manually attaches or links the actual files in Asana post-migration.