Migrate from SMART Project Control to Asana

SMART Project Control Programs act as top-level grouping containers for related Projects. We map each Program to an Asana Portfolio, preserving the Program name and using Portfolio custom fields to carry any rollup status or description. Portfolio Goals can be linked post-migration if the customer uses Asana Goals on Enterprise or Enterprise+.

Projects migrate 1:1 to Asana Projects. Core attributes — project name, start and finish dates, status, and calendar — map to Asana Project fields. Project-level custom properties migrate as Asana project-level custom fields. We flag any project-level earned value fields for manual validation post-cutover since Asana does not calculate EV natively.

SMART Project Control Baselines store the approved schedule snapshot referenced by earned value and variance. We migrate the latest approved baseline as a static schedule copy by creating a Section named 'Baseline Reference' within the Asana Project containing task-level date snapshots from the baseline. Secondary baselines are not migrated unless explicitly scoped; we document them as items requiring manual comparison post-cutover.

Activities are the core scheduling unit in SMART Project Control and map directly to Asana Tasks. We preserve task name, planned start and finish dates (migrated as Start Date and Due Date in Asana), duration, and the original activity ID as a custom field for reconciliation. Predecessor and successor relationships from SMART Project Control convert to Asana dependencies using the Asana Dependents API.

Work Breakdown Structure elements define hierarchical accountability in SMART Project Control. Asana does not have a separate WBS object, so we flatten the WBS hierarchy into Asana Sections (representing WBS level 1 or 2) with Subtasks nested under each Section for deeper WBS levels. We preserve the original WBS code as a custom field on each Task. Any WBS-level custom properties migrate as Section or Task custom fields based on customer mapping instructions.

Labor, material, and equipment Resources migrate as named assignments in Asana. We map Resources to Asana Users by email match where possible. Resource roles and billing rates have no native Asana equivalent; we preserve these as custom fields on the Project (for project-level rates) or as custom fields on Tasks (for assignment-level rates). Resource unit-of-measure is stored as a custom field reference.

Cost CBS levels and cost accounts map to Asana custom fields on the Project or Task. Time-distributed cost data (period buckets) converts to a structured data table format that Asana supports through the data table API or is stored as repeating custom field rows per period. We flag any cost rollup formulas that cannot be expressed in Asana's custom field model for manual post-cutover validation.

Custom activity, project, and resource fields export with their current values and types. We map SMART Project Control field types to Asana field types: text fields to Asana text, picklists to Asana enum, dates to Asana date, and numbers to Asana number. We require explicit customer mapping instructions for picklist value translation and any format conversions before migration.

Cumulative S-curves export as time-phased data rows per project. On import, we convert them to Asana data table rows or create a dedicated Section named 'Progress Curves' with date-stamped milestone Tasks representing curve points. Trend reporting using S-curve data requires post-migration setup in Asana's reporting layer or a connected BI tool.

Critical path and float values in SMART Project Control are computed by the CPM engine and stored as derived fields. Asana does not calculate CPM natively, so we preserve these as static custom fields on each Task. If the customer requires ongoing critical path visibility post-migration, we recommend exporting to a CPM-capable tool (Primavera P6, MS Project, or SmartPM) for analysis and importing updates as custom fields or data table rows.

SMART Project Control notes attached to Activities migrate as Task-level comments in Asana. We preserve the note author, timestamp, and rich text body. Attachments linked to notes migrate as Asana Task attachments via the Asana attachments API.

Risk registers and issue logs in SMART Project Control are often stored as separate grid or sub-entity records. We map these to Asana by creating a Section named 'Risks and Issues' with Tasks representing each risk or issue, using custom fields for probability, impact, status, and owner. Asana's native risk management features (if used) are documented separately for the customer to configure post-migration.