Migrate from Demand Metric to Trello

Demand Metric Projects map 1:1 to Trello Boards. We preserve project name as board title, project description as the board description field, and start/due dates as card due dates re-applied during migration. Each board is created under the destination Trello workspace. If the customer uses multiple workspaces in Trello, we recommend a board-per-project structure with workspace selection made during scoping.

Demand Metric Tasks map 1:1 to Trello Cards. We preserve task title as card name, task description as card description, due date as card due date, priority as a Trello label with priority color coding, and assignee as card member resolved by email. Subtasks in Demand Metric map to Trello Checklist items on the parent card, maintaining the parent-child relationship within a single card rather than as separate records.

Demand Metric subtasks become Trello Checklist items on the parent card. We preserve the subtask title and completion status as checklist item checked state. Checklist ordering is preserved based on the original subtask sequence. Note that Trello checklists do not support due dates independently; if subtasks have due dates in Demand Metric, we flag them for manual re-entry on the destination card or note them in the migration delta report.

Demand Metric tag labels migrate as Trello Labels on the destination board. Tag color coding is preserved where it exists; untagged labels inherit the board's default label colors. Cross-project tag filters from Demand Metric are view-level metadata and do not transfer to Trello, which scopes labels to individual boards. We extract the full tag vocabulary during discovery and recommend applying tags to the corresponding destination boards post-migration or using a label management Power-Up for cross-board label consistency.

Demand Metric assignees are resolved by email match against the destination Trello workspace members. We build a lookup table during scoping and flag any assignee with no matching Trello workspace member for manual re-assignment. Active Demand Metric users who are not yet Trello workspace members are noted in the reconciliation report for the customer's admin to provision before migration begins.

Demand Metric marketing calendar milestones migrate as Trello cards with the milestone date set as card due date. We set the card name to the milestone title and the card description to the milestone description. The marketing calendar view layout itself is not migratable since it is a display-level construct in Demand Metric with no stored data object. Milestone cards are grouped by board during migration based on the project or campaign they belong to.

Demand Metric custom fields added to tasks require field-level mapping against Trello custom field types. We identify all custom property names and data types during discovery and build a custom field map before migration. Trello supports Number, Text, Date, Dropdown, Checkbox, and Label custom field types. We map Demand Metric text fields to Trello Text, numeric fields to Number, date fields to Date, and picklist-equivalent fields to Dropdown. Custom fields that have no Trello equivalent are flagged for manual re-entry.

Demand Metric's 1,000+ templates, playbooks, toolkits, and training resources are platform-hosted content library objects, not customer project data. They cannot be exported via any API or CSV mechanism. We treat them as reference material for the customer to manually re-download on the destination platform post-migration. We do not attempt to migrate template content as project data.

Demand Metric's calendar view is a display-level layout that organizes existing tasks by date. The underlying task data migrates with its due dates intact, but the calendar view configuration itself is not a stored data object and cannot transfer. Trello's Calendar Power-Up (Premium tier) provides calendar visualization for cards with due dates, but the view must be reconfigured by the customer's admin after migration.

This entry clarifies the destination-side automation model. Trello Butler automations are configured within the Trello platform and are not part of the migration payload. We do not migrate Butler configurations as data records. We deliver a written inventory of any active Butler rules from the destination Trello workspace (if pre-existing) and a recommended rebuild guide for the customer's admin to apply after migration cutover.

Trello Power-Up settings (Card Aging, Custom Fields, Calendar, Map, Dashboard, and third-party Power-Ups) are platform-level configurations that do not migrate as part of the standard data payload. We flag Power-Up dependencies during discovery so that the customer's admin can re-enable and reconfigure Power-Ups on the destination boards post-migration. Custom Fields Power-Up must be enabled before we load any custom field data into a board.

Demand Metric attachments embedded in tasks can be extracted and re-uploaded to Trello cards as card attachments. We perform a separate extraction-and-upload pass for attachments, using the card's destination URL to resolve the target. Attachment file type and size are preserved. Note that Trello Standard limits attachment size to 250MB per file; files exceeding this are flagged for manual re-upload or alternative hosting with a link placed in the card description.