Migrate from Coda to Microsoft Project

Each Coda Doc that contains a task-structured table becomes a Microsoft Project file (.mpp) or a Planner Plan depending on the destination environment. We identify candidate Docs during discovery by scanning for tables that contain both a date-type column and an assignee or status column — the presence of both indicates a project management use case rather than a reference database. Docs that contain only reference tables, wiki content, or formula-driven dashboards without task structure are documented as out-of-scope and flagged for manual handling.

Coda tables with date columns, assignee columns, and status columns map to the task list within a Microsoft Project. Each table within a Doc becomes a separate task list if multiple tables exist in one Doc; if the customer prefers consolidated scheduling, we merge tables and add a custom WBS prefix to preserve the original table origin. Table column metadata (column type, options for select fields) is extracted via the Coda API and mapped to Project field types.

Individual Coda rows in a task-structured table map to Microsoft Project task records. We extract the row's text values for the task Name field, date values for Start and Finish fields, and status values for the Status or PercentComplete field. Coda row IDs are preserved in a custom Project field as a migration reference key for reconciliation. The row creation timestamp becomes the Task Notes field for historical audit.

Coda's parent-child row nesting (rows indented under other rows) maps to Microsoft Project's outline hierarchy where subtasks are summary tasks in the outline structure. We traverse the full row tree via the Coda API to capture the parent-child ID relationships, then construct the outline level in MS Project by inserting tasks with the correct indentation using the Outline Level and Indent fields. Outline levels 1-9 are supported; deeply nested hierarchies beyond level 9 are collapsed and the overflow noted in the migration report.

Coda assignee columns (user reference type) map to Microsoft Project resource assignments on the corresponding task. We extract all unique user values from the assignee column, create a Resource record in MS Project for each unique user, then create an Assignment record linking the task to the resource with units derived from the Coda column value (1.0 for a single assignee, fractional for multi-select). Coda does not store resource capacity or cost rates, so we initialize Project resources with default availability (100% units, standard rate) and flag for the customer's admin to populate cost rates post-migration.

Coda columns of type Date map to Microsoft Project Start fields. If the Coda column name contains 'start', 'begin', 'kickoff', or 'due' (for a start date), we map it to the appropriate Start or Finish field. When Coda stores only a due date without a start date, we set the Project task to Fixed Duration = 1 day and derive the Finish from the due date, flagging the task for manual scheduling review. All date formats are normalized to ISO 8601 before insertion.

Coda columns of type Date mapped to task due dates become Microsoft Project Finish fields. When both a start and finish date are present in Coda, the task is scheduled as Fixed Duration with the dates preserved. When only a finish date exists, we calculate duration from the start date (defaulting to one working day) and flag the task as date-constrained for the customer's PM to validate.

Coda select columns with named status options (e.g., Not Started, In Progress, Blocked, Complete) map to Microsoft Project Task Status. Percent Complete is computed from the status value if Coda does not store an explicit percentage column. For Coda select columns that represent non-status metadata (e.g., Priority, Category, Stage), we create a custom Task field (Text or Flag type) and migrate the select option labels as field values.

Coda Relation column types that link rows between tables map to Microsoft Project predecessor-successor dependencies. We resolve the cross-table reference by extracting the source Row ID and target Row ID, then look up the corresponding Project task GUIDs. The dependency type defaults to Finish-to-Start (FS) which is the most common Coda relation pattern. If the Coda relation represents a lead or lag scenario, we capture the offset days and set the predecessor link's Lag field accordingly. Orphaned relations (where the target row does not map to a Project task) are flagged in the dependency report.

Coda attachments stored in rows are extracted via the Coda API before URLs expire, re-uploaded to the destination storage (SharePoint, OneDrive, or the project file's embedded storage), and linked to the corresponding Project task as a Hyperlink or as a Document field reference. Inline images embedded in Coda canvas sections are not migratable as task attachments since they lack a row-level association; we document them separately for manual reattachment. The Coda API session is used directly to pull attachments, bypassing the expiring-URL problem that affects CSV-based exports.

Coda formula columns (calculated expressions referencing other columns in the same table) do not have a direct Microsoft Project equivalent because Project tasks do not support inline formula fields except in Project Desktop via custom fields with formulas. We evaluate each formula at migration time and write the computed value as a static custom Task field (Number or Currency type). Cross-table and cross-doc formulas are documented in the formula audit report as unsupported for migration and flagged for manual verification post-import.

Coda columns of type Text, Number, Currency, URL, Checkbox, and Rating that do not map to a standard MS Project field become custom Task fields. We create the custom field in the destination Project environment before migration using the Coda column name as the field label and the Coda column type as the Project field type (Text, Number, Cost, Flag, or Date). Select column options with fewer than 30 values are migrated as custom Picklist fields; options beyond 30 values become Text fields.