Migrate from CAMMS to Asana

CAMMS Projects (top-level containers with sub-projects) map to Asana Projects. We preserve project name, description, start and end dates, status, owner, and cost centre. Sub-projects from CAMMS create child Asana Projects within a parent Project or, where the team prefers flat structure, become Sections within the parent Project. The mapping decision is made during scoping based on how the customer uses CAMMS project hierarchies. Cost centre is carried as a custom project field in Asana.

CAMMS Tasks map directly to Asana Tasks. We preserve task name, description (rich text), start and end dates, status, assignee, effort estimate (hours), and parent-child hierarchy (subtasks). Task-level attachments are held in the attachment pipeline. Assignee resolution uses email match against the Asana Workspace members list; any assignee without a matching Asana user is flagged in the reconciliation report for admin provisioning before production import.

CAMMS Risks contain likelihood, impact, owner, mitigation plan, and a risk score. Asana has no native Risk object, so we migrate Risks as Tasks with a custom field Risk_Status (enum: Open, Mitigated, Closed) and a custom field Probability (enum: Low, Medium, High) matching CAMMS likelihood. The mitigation plan migrates as task description. Risk register rows with multiple linked Issues carry a cross-reference note in the task description. Risk owner is resolved by email against Asana Workspace members.

CAMMS Issues are related but distinct from Risks and contain status workflow, priority, owner, and linked project context. We migrate Issues as Tasks with a custom field Issue_Status (enum: Open, In Progress, Resolved, Closed) and a custom field Priority (enum: Low, Medium, High, Critical) matching CAMMS priority values. Issue-to-risk associations from CAMMS are preserved as a text cross-reference note in the Asana task description because Asana does not support native cross-object linking without an integration.

CAMMS Budget entries track planned cost, actuals, cost codes, and variance per project or work package. Asana has no native budget-tracking object. We export the full budget register as a structured CSV with columns for project, cost code, period, planned amount, actual amount, and variance. During import, we create a dedicated Asana Project named '[Project Name] Budget Register' with one Task per budget line and carry the cost data as custom fields (Cost Code, Period, Planned, Actual, Variance). The customer uses these Tasks as a living budget register within Asana. Budget totals per project are computed and stored as custom fields on the parent Project.

CAMMS Meeting records contain agenda items, attendees, and minutes. We split this into an Asana Task (for the meeting itself, with agenda as description and a meeting date custom field) and a Notes document (attached to the Task). Attendee names are stored in a multi-user custom field. Meeting attachments (documents, PDFs) are extracted separately and linked to the Task via Asana's attachment API.

Documents attached to CAMMS Projects, Tasks, Risks, Issues, and Meetings are stored in CAMMS's document management layer. We run a parallel attachment export pipeline that downloads files in their original format, recreates the original folder hierarchy in our staging environment, and re-links each file to its matching Asana Task using Asana's attachment API endpoint. File naming preserves the original CAMMS document ID prefix so that provenance is traceable. Large portfolios with hundreds of attachments require additional storage provisioning and transfer time; we scope this separately during discovery.

CAMMS User accounts map to Asana Workspace members. We extract the full user roster including role, department, and active/inactive status. Role-based access assignments from CAMMS map to Asana Team membership and project-level access; Asana does not have a direct role-permission model so the customer's admin sets permissions in Asana based on the provided role inventory. Inactive CAMMS users are imported as inactive Asana members to preserve assignment history on historical records.

CAMMS custom fields are not governed by a stable export schema and cannot be retrieved via any programmatic interface. We do not auto-migrate custom fields from CAMMS. Instead, we ask customers to provide a written inventory of all active custom fields, their data types, and current values before scoping begins. We then map each one individually against Asana's custom field types (text, number, enum, multi-enum, date, user). Fields with no Asana equivalent are flagged as manual carry-over items and documented in the handoff report for the customer's admin to handle post-migration.

CAMMS approval chains and stage-gate workflows cannot migrate to Asana because they represent fundamentally different governance models. CAMMS workflows are governance structures tied to project type; Asana Rules are task-level automations (when task status changes, send notification). We deliver a written inventory of every active CAMMS workflow specifying the project type, stage gates, approval chain members, and escalation path. The customer's admin uses this inventory to rebuild equivalent Asana Rules or to adopt an Asana Enterprise approval solution. This is explicitly out of scope as a coded migration deliverable.

CAMMS executive dashboards consolidate project status, budget variance, and risk exposure across the portfolio. Asana Portfolios aggregate project status and custom field values. We map the CAMMS dashboard metrics to a set of Asana custom project fields (status RAG, budget variance, risk count, issue count) and configure a Portfolio to pull these fields. The customer rebuilds any complex chart or graph as an Asana Dashboard widget manually; we document the data source for each dashboard metric.

CAMMS workforce modules store resource allocations and utilisation data per user and project. Asana Business and Enterprise tiers provide a Workload view that displays task assignments by team member. We export the CAMMS utilisation data as a CSV and import it into Asana as custom fields on Tasks (allocated hours, utilisation percentage). The customer uses the Workload view to visualise capacity; the historical utilisation data is preserved as a reference document for the admin to cross-check against Asana assignments.