Migrate from Comidor to Trello

Comidor Issues map directly to Trello Cards. The Issue title becomes the Card name, and the Issue description maps to the Card description field as plain text. Assignee, due date, priority, and status map to Trello Card member assignments, due date, Label colors, and List position respectively. If the Comidor instance uses multiple App modules (each acting as a separate Comidor app), we create one Trello Board per App and use List names to replicate the Comidor workflow stage labels.

Comidor Apps are custom-built applications containing Issues, Forms, and Workflows. Each Comidor App maps to a Trello Board, with the App name becoming the Board name. We extract the app-level configuration as a JSON package and use it to define Board descriptions and default List structures during migration. Apps without Issues are imported as empty Boards with a note in the migration report.

Comidor globally reusable Custom User Fields map to Trello Custom Fields on a per-Board basis. Text fields become Trello text Custom Fields; numeric fields become number Custom Fields; date fields become date Custom Fields; dropdown or multi-select fields become dropdown Custom Fields with the same options list. Trello Custom Fields are scoped to each Board, so we recreate the field definition on every destination Board where the original Comidor field was referenced. Note that Trello Custom Fields require a Standard ($5/user/mo) or Premium plan; Free-tier accounts cannot use them.

Comidor files and documents attached to Issues migrate as Card attachments in Trello. We extract binary files from Comidor and upload them to the corresponding Trello Card via the Trello API, preserving original filename and file type. File size limits apply: 10 MB per file on Trello Free, 250 MB per file on Standard and Premium. We flag any file exceeding the target tier's limit for the customer's admin to host externally and link from the Card instead.

Comidor Knowledge Base articles are flattened and migrated. Articles associated with specific Issues become Card descriptions (with the article text appended to the existing description or set as the description if no other description exists). Standalone articles without an Issue association are migrated as a separate Board with one Card per article, using Card descriptions to hold the full article text and Labels to represent article categories. The Leia chatbot configuration and article-to-response associations cannot be extracted and are not migratable; we flag these in the knowledge_base_gaps.md deliverable.

Comidor BPMN 2.0 Workflows define business process sequences, conditional branches, and automated task assignments. These cannot be migrated as code because Trello Automations and Butler use a different rule-definition model (trigger-action rather than BPMN). We extract the full workflow configuration as a structured JSON package, produce a written step-by-step procedure for each workflow, and mark the rebuild as a manual handoff item. The customer's admin or a Trello partner rebuilds the automation in Butler or Trello Automations post-migration.

Comidor Process Scheduling defines recurring workflow execution and automated Issue creation on a cron-like schedule. This is an execution configuration that does not exist as a data record and cannot be migrated. We document each schedule as a natural-language rule (frequency, trigger, and action) and deliver it as a remediation item. Trello handles recurring cards via the Card Repeater Power-Up or native due-date automation, which the admin configures manually.

Comidor User Forms are data-entry interfaces embedding Custom User Fields and used inside Workflows. Conditional logic within Forms (show/hide rules based on field values) cannot be migrated to Trello's simpler data model. We extract the form schema (field list, field order, and required flags) and map the required field flags to Trello Custom Field required settings on the destination Board. The visual layout and conditional logic are documented in the forms_inventory.md deliverable for manual remediation.

Comidor Contacts and Accounts are used for organizational and collaborative purposes within Issues. Since Trello does not have a native CRM-style Contact or Account object, we map Contacts to Trello Card members or Board members depending on whether the Contact is an active project participant or an organizational stakeholder. Account-level information is preserved as Card description text or as a Board label for organizational grouping.

Comidor Users map to Trello Board members. We extract the user list (name, email, and Comidor role) and invite each user to the corresponding destination Board via Trello API. Teams map to Trello member groups if the destination Trello workspace supports them, or we document the team composition in a users_teams_inventory.csv for the admin to assign manually. Any Comidor user without an existing Trello account is flagged for manual account creation before migration.

Comidor file attachment metadata (filename, file type, upload date, uploaded by user) migrates as Trello Card attachment metadata. The upload timestamp becomes the Trello attachment date. We also extract Comidor's file version history as a comment on the Card noting the version timeline. Version history beyond the current file is preserved as text documentation rather than as individual versioned attachments due to Trello's flat attachment model.

Comidor discussion board entries and Issue comments map to Trello Card comments. Each comment preserves the original author (mapped to Trello member), timestamp, and body text. Rich-text formatting in Comidor comments is converted to plain text or basic markdown depending on content complexity. Attachments referenced in comments are re-attached to the Card separately and linked via comment text.