Migrate from InLoox to Trello

InLoox Projects map directly to Trello Boards. We pull the project name, description, status, start/end dates, and custom fields via the InLoox web API and create a corresponding Trello Board in the target workspace. Project-level custom fields (budgets, documents) are preserved as board-level Custom Fields if the destination Trello workspace is on Standard or above. The InLoox project URL is stored as a Custom Field (text type) on the first card of each board for audit reference.

InLoox Phases are sequenced sub-containers within a Project. We create one Trello List per Phase, preserving the phase order using the position index from InLoox. If the customer used InLoox Phases as a top-level planning layer above tasks, we create a List per phase and nest all Phase-level tasks inside that List. Milestone flags from InLoox are carried as a Label (named 'Milestone') on each card in the milestone phase.

InLoox Milestones are time-bound markers with a due date. We map milestones to a Trello Card with a 'Milestone' label, the milestone due date stored in the card's due date field, and the milestone title as the card name prefixed with 'MS: '. Because Trello has no native milestone object, the milestone card remains distinct from task cards and the customer should set a Power-Up rule (Butler or similar) to alert when the milestone card approaches its due date.

InLoox Tasks map to Trello Cards. We map task name to card title, task description (rich text) to card description, due date to card due date, priority (high/medium/low) to card labels, completion status to card archival (completed tasks archived, open tasks active), and assignee to card member. Task-level custom fields migrate as Custom Fields on the card if the workspace supports them.

InLoox Subtasks are nested under a parent task. Trello does not support nested cards, so we flatten the subtask hierarchy by creating a Checklist on the parent card with one item per subtask. The subtask name becomes the checklist item text, subtask completion state becomes checklist item checked state, and subtask assignee is stored as a prefix in the item text (e.g., '[Jane Doe] Fix navigation bug'). No separate subtask cards are created.

InLoox Resources are user assignments on tasks or projects. We match by email address against Trello workspace members. Any InLoox resource without a matching Trello member is held in a reconciliation queue and flagged for the customer to invite the user or assign a proxy before migration completes. Resource allocation percentages (not natively supported in Trello) are stored in a Custom Field (number type) on each card.

InLoox Time Entries carry hours, date, user, task association, and optional description. Trello has no native time-tracking object. We map billable hours to a Custom Field (number type) on the associated card named 'Hours Logged'. For non-billable entries or entries with rate details, we provide a companion CSV export (Date, User, Hours, Description) alongside the main migration so the customer's finance or PMO team can import into a spreadsheet or a time-tracking Power-Up separately. Rate-based billing fields do not map directly to any Trello construct.

InLoox links to SharePoint Online document libraries or file server paths. We export the document URL and metadata (file name, linked date, linked by user) and store the URL in the Trello card description as a formatted link. Actual file content migration depends on SharePoint permissions; if the customer grants read access to the SharePoint library, we attempt to attach the file directly to the Trello card. File server paths with no external access cannot be migrated as attachments.

InLoox budgets contain line items with amounts, categories, and cost tracking. Trello has no budget object at any tier. We extract the budget total and top-level line item values and store them as Custom Fields (number type) on the board named 'Budget Total' and 'Budget Lines (CSV)'. For detailed line items, we provide a companion CSV export that the customer's PMO uses outside Trello. Budget tracking against actuals does not transfer and requires manual reconciliation or a third-party Power-Up.

InLoox custom fields are created per project and scoped to specific areas (budgets, documents, line items, mind maps). We extract the per-project custom field definitions during discovery and create matching Custom Fields at the Trello board level. The field type maps as follows: text to Trello text, number to Trello number, date to Trello date, checkbox to Trello checkbox, dropdown to Trello dropdown. If the customer uses multiple InLoox custom field definitions across projects, we create separate Custom Fields per board, noting that Trello Custom Fields apply board-wide and cannot be scoped to specific cards.

InLoox stores Gantt task dependencies as predecessor/successor relationships with date ranges. Trello has no native Gantt chart. We extract the dependency chain and reconstruct it using Trello Card Links (one card linking to its predecessor via a 'Depends on:' prefix in the card description) and optionally configure Butler rules to set due dates relative to predecessor completion. The dependency graph itself is delivered as a companion CSV mapping card IDs to predecessor card IDs. For customers needing a visual Gantt, we recommend enabling a Power-Up like Gantt by Corendo post-migration.

InLoox Kanban board column definitions are project-specific. We export the column names and card positions as a structured list and map them directly to Trello Lists within the corresponding board. Column order is preserved by position index. If the customer used more columns than Trello's practical limit per board (typically 20-25), we flag the excess columns and recommend consolidation or splitting across boards.

InLoox Risk objects include title, description, probability, impact, and status. Trello has no native risk management object. We extract all risk fields and store them as a separate Trello board named 'Risk Register' with one card per risk, using Labels to encode probability (Low/Medium/High) and impact (Low/Medium/High), and card description to carry the full risk narrative. The customer should assign a team member to own each risk card post-migration.

InLoox inline checklists on tasks are stored as structured list items with completion state. We map each InLoox checklist to a Trello Checklist on the corresponding card, preserving item text, completion state, and parent task association. Checklist items with assignees store the assignee name as a prefix in the item text.

InLoox departments control project visibility and permissions. Trello permissions operate at the Workspace level and board level (private vs public). We map InLoox departments to separate Trello Workspaces or to board-level visibility settings. Departmental permissions that do not map directly to Trello's model are documented in the migration report for the customer to reconfigure in Trello Workspace settings post-migration.

InLoox supports up to 10 customizable project roles per project on Enterprise/Unlimited. Trello has admin, normal, and observer member roles at the board level. We map InLoox role names to the closest Trello board role and flag any roles that have no equivalent. Detailed role definitions are documented in the migration report.

InLoox Mind Maps are stored as a proprietary structured format with no public API export endpoint. We detect mind map nodes in the data export, flag their existence in the migration report, and recommend the customer capture screenshots or use a third-party export tool before the migration cutover. We do not block the migration due to mind maps but note the exclusion explicitly in the final migration report.