Migrate from Zoho Projects to Trello

Each Zoho Projects container becomes one Trello Board. We preserve the project name, description, status (active or on hold), and start/end dates as board metadata. Since Trello Boards do not have a native status field, we map active projects to open Boards and archived projects to Boards archived via the Trello API. Custom fields on Zoho Projects cannot map to Trello custom fields (Trello has no native custom field object on Standard tier), so we append a structured text block to the Board description listing each custom field name and value for reference.

Zoho Task Lists map directly to Trello Lists within the parent Board. We preserve the Task List name and its relative order within the project. Trello does not enforce a maximum list count, but teams typically structure boards with 3-8 active lists representing workflow stages (To Do, In Progress, Review, Done). We map the Task List ordering as the List ordering at import time.

Zoho Tasks map to Trello Cards within the appropriate List. Standard fields migrate directly: name, description (rich text preserved), start date (stored as a Card custom field or due-date label), due date, priority (mapped to coloured Labels: Low=Grey, Medium=Yellow, High=Orange, Urgent=Red), and assignee (mapped to Board members). Task status in Zoho (open, on hold, completed) maps to Card position within Lists or archived Card status in Trello.

Zoho subtasks are stored as a separate API endpoint within each Task. We flatten subtasks into a Trello Checklist named 'Subtasks' on the parent Card, with each subtask name as a Checklist item. Subtask status (completed or open) maps to the Checklist item checked state. If a subtask has its own assignees or due dates, we append this metadata to the Checklist item name string as a reference note. Trello's Checklist model supports unlimited items per Card but does not support nested subtasks within subtasks, so any Zoho subtask that has its own subtasks is flattened to the parent Card's Checklist.

Zoho Milestones are date-bound markers that can group multiple tasks. Trello has no native milestone object. We create a Label named after the milestone (with a distinct colour) and apply it to every Card linked to that milestone. Alternatively, if milestones have distinct due dates, we set a milestone-level due date on each linked Card and use a Label to identify which milestone the date belongs to. We document the full milestone-to-Card mapping in a CSV delivered alongside the migration so the admin can verify coverage post-import.

Zoho time logs are linked to tasks and include hours logged, date, user, and billing rate. Trello has no native timesheet object. We append a structured time log summary to the parent Card description, formatted as a markdown table with columns: User, Date, Hours, Billing Rate, and Notes. If the customer has the Trello Power-Up Time Tracking by Coruzant or a similar integration already active, we can map time entries to that Power-Up's data model instead. Time entry data is preserved as readable text in all scenarios.

Zoho Issues are tracked in a separate workflow from Tasks with their own status values (Open, In Progress, Resolved, Closed) and severity picks (Low, Medium, High, Critical). We map Issues to Trello Cards with a mandatory Label named 'Issue' and a severity sub-label (e.g., 'Severity: High'). The Issue status workflow does not map to a native Trello equivalent, so we document the status mapping for the admin to apply manually or through Butler rules post-migration.

Zoho Forums are project-level discussion threads with replies, timestamps, and author attribution. Trello has card-level comments but no project-level forum equivalent. We consolidate each Forum thread into a Card comment on the relevant Card (or the Board description if no single Card is appropriate), preserving the thread author, timestamp, and full reply text. If multiple Forum threads are spread across many tasks, we merge them into the most relevant Card per thread and document the remainder in a CSV. Thread ordering is preserved chronologically within the comment block.

Zoho Comments on tasks, issues, and milestones migrate as Trello Card Comments. We preserve author, timestamp, and body text. Author mapping requires a Zoho-to-Trello user lookup by email; if a Zoho commenter has no matching Trello Board member, we use their Zoho display name prefixed with 'External:' as the comment author in Trello.

Zoho Tags applied to tasks and issues map to Trello Labels on the corresponding Card. Tag names migrate as Label names; the existing Zoho tag colour assignment is preserved if the destination supports custom label colours, otherwise a default colour is applied. Trello Label names are case-insensitive and have a 48-character maximum, so long Zoho tag names are truncated to 48 characters.

Zoho Documents and file attachments are stored in Zoho's file store and referenced by file ID. We export attachment metadata (filename, size, upload date, uploader) via Zoho's documents endpoint and re-upload file binaries to the Trello Card as attachments where the destination Trello plan permits. Trello Standard caps attachments at 10 MB per file; Premium and Enterprise raise this to 250 MB. We filter attachments over the destination plan limit and flag them in the reconciliation report for the admin to handle via an alternative file host (Google Drive, Dropbox, SharePoint) linked in the Card description.

Zoho supports custom fields on Projects, Tasks, and Issues with field types including text, number, date, dropdown, checkbox, and user lookup. Trello Standard does not have a native custom field object. On Trello Premium and above, we create Trello custom fields matching the Zoho field type (text, number, date, dropdown, checkbox) and populate values per Card. On Trello Standard, we append custom field values as a structured block in the Card description. We deliver a custom field inventory CSV documenting each field's source name, type, and destination placement.

Zoho Users are exported with their email, display name, and project-level role. We map each Zoho user to a Trello Board member by email invitation. If the destination Trello Workspace already has members with matching emails, we grant them Board access directly. New members are added to the Workspace and then to each relevant Board. Inactive Zoho users are added as Board observers if their historical task assignments need to be preserved in the Card activity log.

Zoho finish-to-start task dependencies are exported as a dependency reference per task. Trello has no native dependency model, so we represent blocking dependencies as a Label named 'Blocked by: [Task Name]' applied to the dependent Card, and document the full dependency matrix in a CSV for the admin to validate. For teams that use Trello Power-Ups that support card linking (such as card dependency plugins), we can structure the data for import via those Power-Up APIs instead.

Zoho Workflow Rules are configuration-level automation records with triggers, conditions, and actions defined in Zoho's rule engine. We do not migrate Workflow Rules as functional automation code because the rule structure does not translate to Trello Butler syntax. We deliver a written inventory of every active Zoho Workflow Rule with its trigger, conditions, actions, and the corresponding Butler action type (card moved to list, due date reminder, label applied) as a rebuild guide for the customer's admin.