Migrate from Meegle to Trello

Each Meegle Workflow becomes a Trello Board within the destination workspace. We map the Workflow name to the Board title and preserve the Workflow description in the Board description field. The visual node graph and layout coordinates are not transferable; Trello does not support spatial canvas layouts. We set Board visibility (Public, Workspace, Private) based on the Meegle Workflow's space access settings. If the source has multiple Workflows referencing the same project scope, we consolidate them into a single Board with labeled Lists rather than separate Boards to avoid fragmentation.

Meegle task Nodes map directly to Trello Cards. The Node title becomes the Card name, Node description becomes the Card description, assignee maps to Trello Card members, due date maps to the Card due date, and status maps to List position or a colored label. We preserve the original Node ID as a Card label for audit trail purposes. Node completion status (marked done in Meegle) translates to moving the Card to a Done or Complete List.

Meegle milestone Nodes do not have a native Trello equivalent. Milestones represent project checkpoints or phase gates. We create a Card with the milestone name, set its due date to the milestone target date, and add a checklist named 'Milestone Tasks' containing links (as text URLs) to all Cards that feed into the milestone. This preserves the milestone concept as a Trello Card that can be tracked in the timeline view. If the milestone has no child tasks, we create a Card with a 'Milestone' label and a note explaining the completion criteria.

Meegle group Nodes (containers that organize related tasks) map to Trello Lists within the Board. The group name becomes the List name, and child Nodes within the group become Cards within that List. This preserves the organizational grouping without requiring a separate Card. If the group Node has no child Nodes, we skip it rather than creating an empty List.

Meegle subtasks are nested node relationships within a parent task Node. These map to Trello Checklist items on the parent Card. The subtask title becomes the checklist item text, assignee maps to a checklist item member (using the Card Members field note), and due date maps to the checklist item due date if the destination Trello plan supports due dates on checklist items (Premium feature). We preserve subtask completion status as checklist item checked/unchecked state. Subtasks nested two or more levels deep are flattened into a single checklist level since Trello does not support nested checklists.

Meegle custom fields (text, number, date, formula, multi-select) have no equivalent on Trello Standard. On Trello Standard, we map custom field values to Trello Labels: text and number fields become a single 'CF: [fieldname]=[value]' label; date fields become a 'Due: [date]' label; multi-select fields become one label per selected option using the field name as prefix. On Trello Premium, we use Trello's native custom fields for text, number, date, and dropdown types, and map formula fields to a read-only custom field populated with the computed value during migration. We export the full custom field schema as a written reference document for the customer to review and validate after migration.

Meegle's advanced dependencies include finish-to-start (FS), start-to-start (SS), and custom dependency types. Trello has no native dependency tracking. For finish-to-start dependencies, we compute the due date of the successor Card as the predecessor's due date minus a configurable buffer (default one business day). For start-to-start dependencies, we set the successor Card's start indicator (as a 'Start: [date]' label) matching the predecessor's due date. We create a 'Dependency Chain' label family to visually group linked Cards. Complex multi-node dependency trees are exported as a written dependency map for manual rebuild in Butler or a project-management tool native to the destination.

Meegle attachments stored on Nodes are extracted and re-uploaded to the corresponding Trello Cards as attachments. We use the Trello API attachment endpoint (max 10MB per file on Standard, 250MB on Premium). Files exceeding Trello's limit are flagged with a reference URL pointing to the source Meegle file. If the attachment is an image, we optionally embed it in the Card description as an image tag for visibility. The original attachment filename and uploader metadata are preserved in the Card description for audit.

Meegle workspace members are mapped to Trello workspace members by email address. We invite each Meegle member to the Trello workspace at the Standard Member level by default. If a Meegle member has node-level Role assignments, we evaluate the highest-privilege role and grant that member Board Admin access on boards where they were explicitly assigned to critical Nodes. This is a simplification; Trello's three-tier permission model (Standard Member, Workspace Admin, Board Admin) cannot capture the full granularity of Meegle's cross-space authorization.

Meegle Role definitions (which nodes and fields a user can access) cannot be directly mapped to Trello permissions because Trello uses workspace-level and board-level roles without field-level access control. We document every Meegle Role as a written permission matrix and map it to the nearest Trello equivalent: nodes restricted to specific Roles become Cards on Boards with that Role invited as Board Admin; nodes visible to all become Boards with Workspace visibility. This requires manual validation by the customer's admin after migration.

Meegle View configurations (sort order, grouping, visible fields) do not migrate to Trello because Trello has one native view: the Board. We export each Meegle View as a written configuration record describing the sort field, grouping, and visible columns. For Kanban-equivalent views, the Trello Board itself is the Kanban view. For Gantt-equivalent views, we recommend Trello's Calendar Power-Up or a third-party Gantt integration (such as Deck, Infinity, or TeamGantt) and provide the timeline data in a CSV export. Table-equivalent views are available through Trello's default Board view with list filtering.

Meegle automation rules with triggers (task status change, field update, date trigger) and operations (create, update, notify) do not migrate to Trello Butler as code because the trigger-event and condition models differ. We deliver a written inventory of every active Meegle Automation Rule including its trigger type, conditions, and actions, and map each to a recommended Butler command or a Butler Power-Up rule that the customer's admin can rebuild. The customer validates and enables these after cutover.