Migrate from ]project-open[ to Trello

]project-open[ Projects map to Trello Boards. The project_id becomes the board identifier, and the project_name becomes the board title. Project status (potential, active, closed) requires a mapping decision: we recommend using board visibility (public, private, workspace) or a dedicated status label column rather than separate boards per status, since Trello has no native project status lifecycle. We preserve the project description as the board description. If the customer maintains a parent-child project hierarchy in ]project-open[, we document the structure as a board-naming convention for the Trello admin to implement post-migration.

]project-open[ Tasks and sub-tasks map to Trello Cards. Parent tasks become cards at the top-level List, and child tasks become Checklist items on the parent card. This is the standard Trello pattern for hierarchical task decomposition. Task status_id (not started, in progress, completed) maps to a combination of card due dates, labels, or List placement depending on the customer's workflow preference. We preserve task description as the card description, priority flags as colored labels, and assignees as card Members.

Trello has no native Company or Account object. We provide two options during scoping. Option one: migrate company names as a Card Custom Field (Company Name, text type) attached to every relevant card if the Trello plan supports Custom Fields. Option two: deliver a structured CSV export of all im_companies records (company_name, company_status_id, company_type) as a reference document for the customer to maintain in a separate system. We recommend the CSV approach if the source has more than 200 companies because Trello's Custom Fields apply per-card and do not support lookup relationships.

]project-open[ Tickets migrate to Trello Cards with a Ticket-type label applied for visual filtering. The ticket_status_id maps to a label color (for example, Open = blue, In Progress = yellow, Resolved = green, Closed = gray). Ticket description, assignee, and conversation threads migrate as card description, member assignment, and card comments respectively. Conversation threads from the im_tickets and im_ticket_message tables are flattened into chronological comments on the card.

Timesheet data in ]project-open[ has no direct Trello equivalent. If the customer's Trello plan is Standard or above (Custom Fields enabled), we create a numeric Custom Field (Hours Logged) per card and map timesheet entries from tasks that have time tracking. We sum hours per task and write the total to the card. For detailed timesheet history (user-level, date-level, billing type), we deliver a CSV export of im_costs timesheet entries mapped by project and user for offline financial reporting.

Invoice and financial cost records in ]project-open[ do not have a migration path into Trello because Trello has no financial object model. We extract im_costs records with cost_type_id indicating invoice or billable cost, preserve the full financial metadata (amount, currency, cost_status_id, project reference, company reference), and deliver as a structured CSV export. We map project_id and company_id to their migrated Trello Board and Company Custom Field values respectively so the financial export references the correct destination records.

]project-open[ User accounts map to Trello Members by email match. We extract user_id, name, and email from the acs_users table and resolve against Trello workspace members. The challenge is that Trello membership is workspace-level and invitation-based, whereas ]project-open[ user records include permission hierarchies and group memberships. We map users by email, flag any user without a Trello account for the customer to provision before migration, and note that ]project-open[ role hierarchies do not transfer to Trello (which uses workspace Admin, Member, and Observer roles).

]project-open[ allows unrestricted dynamic custom attributes per Business Object. We perform field-level discovery during scoping, extract the full set of attribute names and data types per object type, and map each to a Trello Custom Field of the closest matching type (text, number, date, dropdown, checkbox). Custom Field availability is plan-dependent: Standard plan and above only. We map text fields as text, numeric fields as number, date fields as date, and enumerated fields as dropdown with their option values preserved. Max 50 Custom Fields per board and max 50 options per dropdown field in Trello apply; we flag any attribute that exceeds these limits and propose a consolidation approach.

Documents in ]project-open[ are stored as separate objects with acs_objects references. Binary files may be in the filesystem or the database depending on configuration. We identify file storage locations during discovery, extract file references, and create Card Attachments in Trello. Trello enforces a 10MB per-file limit; any attachment exceeding this threshold is flagged and the customer decides whether to compress, split, or host externally with a link card comment substituting for the attachment.

]project-open[ Categories stored in the hierarchical category system (used for ticket types, project sectors, and object classification) map to Trello Labels. We extract category_id and category labels, filter to the relevant classification sets the customer wants to preserve in Trello, and create Label records per Board. Category hierarchy (parent-child) does not transfer since Trello Labels are flat; we preserve the full category label string as the label name and document the hierarchy as a label-naming convention (for example, Project Type: Software, Project Type: Infrastructure) for the customer to implement post-migration.

Office objects in ]project-open[ store physical location data linked to companies and projects via acs_rels. Trello has no location or office concept. We extract office records (name, address) and preserve the relationship metadata (which companies and projects reference which offices) as a structured reference document. For organizations that need location context in Trello, we recommend a Card Custom Field (Location) to capture this at the project or card level.

Configuration items tracking IT assets and dependencies in ]project-open[ do not have a native Trello equivalent. We map configuration items to Cards on a dedicated IT Assets Board with a CI-type label applied, preserve the CI attributes as card description text and Custom Fields, and document the dependency relationships (stored in acs_rels) as a CSV export for the customer to reference when rebuilding dependency tracking in their new IT management system.