Migrate from Blueprint to Trello

Blueprint Projects map to Trello Boards as the top-level container. The Project name becomes the Board name, and Project-level custom fields map to Board custom fields if the destination Trello workspace is on Premium. We preserve the original Blueprint project identifier in the Board description for audit and cross-reference during the reconciliation phase. If Blueprint has an organizational hierarchy of Projects (e.g., programs containing projects), we create multiple Boards and use Board labels or a prefix naming convention to preserve the grouping relationship.

Blueprint Scopes represent AI-generated work breakdowns within a Project. Each Scope maps to a Trello List within the destination Board. The Scope name becomes the List name, and the original Scope description or metadata is appended to the List description. Scopes that contain no child Tasks are preserved as empty Lists to maintain the original structural hierarchy. Scopes with hierarchical sub-scopes are flattened into sibling Lists at the same level since Trello Lists do not support nesting.

Blueprint Tasks are atomic work units within Scopes. Each Task maps to a Trello Card placed in the List corresponding to its parent Scope. Task title, description, status (e.g., open, in-progress, completed), and timestamps (created date, due date if present) migrate directly. Task status is mapped to the Card's List position: completed Tasks are placed in the rightmost List or in a dedicated Done column; open Tasks remain in their parent Scope List. The Blueprint Task identifier is preserved in the Card description for cross-reference.

Blueprint role-based user assignments on Tasks map to Trello Card Assignees. We extract all unique users referenced in Blueprint Task assignments and provision them as Board Members in the destination Trello workspace (requiring that each user has a Trello account or accepts a workspace invitation). Card Assignees are set during migration using the Trello REST API. Users without a resolvable Trello identity go to a reconciliation queue for manual assignment post-migration.

Blueprint custom fields on Projects and Tasks require schema discovery before migration since field names and types vary by customer configuration. We extract the custom field definitions during discovery, map them to Trello Custom Field types (Text, Number, Date, Checkbox, Single-Select, Multi-Select) based on data type, and create the corresponding Custom Fields in the destination Trello workspace. Custom Fields require Trello Premium; if the destination workspace is on Standard or Free, we append custom field values to the Card description as structured text instead.

Blueprint file attachments associated with Projects or Tasks are referenced by URL or stored object ID. We preserve attachment links by migrating them as Card Attachments in Trello. If Blueprint attachments are stored in external cloud storage (Google Drive, Dropbox, S3), we preserve the original URLs as Card attachments pointing to the source. If attachments are stored within Blueprint's own storage, we attempt to download and re-upload to Trello if the file size is within Trello's 10MB attachment limit. Files exceeding the limit are noted in the migration report for manual handling.

Blueprint automation rules stored as structured configuration do not migrate as code to Trello. Trello uses Butler for automation with a different trigger-action syntax. We document every Blueprint automation during discovery with its trigger conditions, rule logic, and actions, then deliver a written Butler translation specification mapping each Blueprint rule to its Trello Butler equivalent with step-by-step configuration instructions for the customer's admin to implement post-migration.

Blueprint's role-based access model assigns users to roles (e.g., Admin, Editor, Viewer) at the Project and Scope level. Trello uses workspace-level permission levels (Admin, Normal, Observer) and Board-level member roles (Admin, Member, Observer). We map Blueprint roles to the closest Trello Board permission level during migration: Blueprint Project Admin maps to Trello Board Admin; Editor maps to Member; Viewer maps to Observer. The customer configures the specific role mapping during scoping since the semantics differ between platforms.

Blueprint task creation dates, last-modified timestamps, and any historical state records are preserved in Trello as Card creation dates and modification timestamps. Due dates from Blueprint Tasks map to Trello Card due dates. We preserve the original Blueprint timestamp values as Card description footnotes to maintain the full historical audit trail even after the Trello modification timestamp advances post-migration.

Blueprint Project metadata including project description, start date, status, and any project-level custom fields are migrated as Board description text and Board custom fields (if Premium). We format the original Blueprint metadata as structured markdown in the Board description so that project context is preserved and visible to all Board members without requiring access to Blueprint.

Blueprint Scopes with parent-child hierarchy are mapped to Trello Lists with a label-based convention to indicate the hierarchy level. Parent Scopes receive a specific label (e.g., 'Parent Scope') and child Scopes receive a corresponding child label. This preserves the structural relationship without requiring nested Lists, which Trello does not support. The customer reviews and approves the label naming convention during the scoping phase.

If Blueprint Tasks contain sub-task checklists (not present in all customer configurations but common in complex planning setups), we migrate each sub-item as a Trello Card Checklist item. The Checklist is attached to the parent Card with each sub-item as a Checklist entry. Checklist completion status is preserved. This mapping is optional and activated only for Blueprint configurations that include sub-task structure.