Migrate from TaskRay to Trello

Each TaskRay Project maps to a Trello Board. Project Name maps to Board name (80-character limit enforced). Project Start and End dates map to optional Board start date and due date fields via a Power-Up if the customer licenses Standard or above. Archived Projects map to archived Trello Boards with a customer-confirmed decision on whether to include archived boards in migration scope. Owner from TaskRay maps to a Trello Workspace member by email lookup.

TaskRay Task Groups map directly to Trello Lists within the parent Board. Task Group Name maps to List name. The Task Group-to-Project parent linkage is represented by the List's membership in the Board. The ordering of Task Groups within the Project determines the left-to-right List order in Trello. Sub-Projects in TaskRay can either create their own child Board (if the customer wants full isolation) or become a Trello List (if the team prefers a single-board view). We confirm the strategy during scoping based on Task count and team structure.

TaskRay Sub-Projects introduce a structural challenge because Trello has no Sub-Project equivalent. We offer two strategies during scoping: (1) Sub-Project becomes a Trello List within the parent Board, with Tasks under the Sub-Project becoming Cards in that List, preserving visual hierarchy within one Board; (2) Sub-Project becomes a separate Trello Board linked via a Power-Up or Butler rule to the parent Board. Strategy selection depends on Task volume per Sub-Project and whether the customer wants cross-Board dependency tracking. Projects with deeply nested Sub-Project chains (more than two levels) are flattened per TaskRay's own depth limitation.

TaskRay Tasks map directly to Trello Cards within the parent List. Task Name maps to Card name. Due Date, Description, Assignee, Status (blocked, completed), Blocked flag, and Repeating flag all map to native Card fields or Checklist items. Custom fields on TaskRay Tasks map to Trello custom fields via the Custom Fields Power-Up on Standard and above; Free tier does not support custom fields and we flag this tier requirement upfront.

TaskRay Milestones are a distinct Task record type with a milestone flag and a single-day date. We migrate Milestones as Trello Cards with the Card name prefixed by a Milestone label (e.g., '[MILESTONE]'), the milestone date set as the Card due date, and the milestone flag stored as a Card label. Trello has no native Milestone concept, so this is a visual convention that the customer's team adopts post-migration. Alternatively, the customer can use a dedicated Power-Up like Project Manager or Chrono to render milestone views.

TaskRay Task Dependencies (predecessor/successor links) have no native Trello equivalent. We migrate dependency references as Card links (Trello's native cross-card linking via the card URL in Card Description) and flag that the customer should evaluate the Dependencies Power-Up or a Butler rule-based dependency tracker for ongoing dependency management. The migration does not build a full dependency graph in Trello; we document the complete dependency chain in a CSV deliverable for the customer's admin to implement via Power-Up if needed.

TaskRay Checklist Groups and their Checklist Items map to Trello native Card Checklists. Each Checklist Group becomes a Trello Checklist on the parent Card. Checklist Item name maps to Checklist item text, and completion state (checked/unchecked) migrates as the item completion flag. Trello Checklists are flat (one level only), so any nested Checklist Item structure from TaskRay flattens at import time. The parent Task's Checklist container structure is preserved as a named Checklist per TaskRay's Checklist Group naming convention.

TaskRay Template Projects (available on Starter and above, with Template Migration feature on Premium) cannot migrate directly as Trello templates because the template structure is Salesforce-object-based and Trello uses a different template model. We export template structure as a written specification (object names, Task Group order, Task count, Milestone dates) and deliver it to the customer's admin for manual recreation as a Trello Board Template. Template-based Stitching rules (automated project creation via Flow) do not migrate and are documented in the automation inventory.

TaskRay files are stored on the Salesforce ContentDocumentLink model and attached to Project or Task records. We export files by querying ContentDocumentLink for each TaskRay record, download the ContentVersion binary, and re-attach to the corresponding Trello Card via the Trello API. Files with no parent TaskRay record (Project-level attachments) attach to the parent Board description or a dedicated Card designated as the project assets card. File type preservation (PDF, image, document) is maintained. Very large files (above Trello's 10 MB per attachment limit) are flagged for the customer's admin to store externally and link.

TaskRay custom fields on Project, TaskGroup, and Task objects are standard Salesforce custom fields and migrate as field-value pairs. In Trello, custom fields require the Custom Fields Power-Up which is available on Standard ($5/user/month) and above. We map text, number, and date custom fields to Trello Custom Fields; checkbox fields map to Card labels; picklist fields map to Trello dropdown Custom Field type. Free-tier destinations are flagged as incompatible with custom field migration. The customer's admin must install and configure the Power-Up in the destination Trello Workspace before migration begins.

TaskRay Resources represent individual users who own and complete work. Roles serve as placeholder owners without an assigned user. We map Resources to Trello Workspace Members by email address lookup. Any TaskRay Resource without a matching Trello member email is held in a reconciliation queue for the customer's admin to provision before Task assignment import resumes. Role placeholders are documented separately as a CSV deliverable for manual assignment post-migration because Trello does not have a native Role concept.

TaskRay's Field Trickler propagates Account and Opportunity lookups from Project level to all Tasks within that project automatically. Trello has no native CRM lookup or cross-object reference capability. We extract the Field Trickler configuration (which fields are propagated from which source object) during export and deliver it as a written specification. The customer's admin rebuilds the equivalent behavior using Butler rules (if-when conditions) or a Power-Up integration with the CRM system. We do not build CRM integrations as part of standard migration scope.