Migrate from Project.co to Trello

Project.co Projects map directly to Trello Boards. We extract project name, description, status (active/archived), created date, and custom field values. The Board title uses the Project name. Project status is mapped to Trello Board state: active Projects become open Boards; archived Projects are created as closed Boards. If the customer uses multiple Project.co Workspaces, we group the resulting Trello Boards by Workspace. Custom field values on Projects become Custom Fields on a template Card or are stored as Board-level labels per the customer's scoping preference.

Project.co Tasks map to Trello Cards within the Board corresponding to their parent Project. We migrate task title, description (as card description), status, assignee, due date, and custom field values. Project.co task status (To Do / In Progress / Done) maps to List position within the Board; we create Lists matching the customer's Project.co status flow or a standard three-list To Do / Doing / Done structure during scoping. Subtasks are stored as checklist items on the parent Card.

Project.co Discussions are per-project threaded message feeds. We flatten each Discussion thread as a chronological sequence of Card Comments on the corresponding Trello Card, with author name, timestamp, and body text preserved in each comment. If a Discussion is associated with a specific task rather than the project overall, we route the flattened comments to that task's Card. Thread structure is lost in the merge; we add a top-level comment noting the original Discussion title for traceability.

Project.co Files uploaded to project-level folders are downloaded individually (no bulk export) and re-uploaded to the corresponding Trello Card as attachments via the Trello API. We preserve the original file name, binary content, and upload date. Folder path from Project.co is recorded as a comment on the Card for reference. Large attachment counts significantly extend the export timeline; we flag total file volume during scoping so the customer can plan the migration window accordingly.

Project.co Notes are standalone rich-text documents attached to projects. We create a Trello Card named after the Note title and place the note body in the Card Description. Formatting (bold, lists, headings) is preserved as plain text with structural markers where the destination supports it; HTML-heavy formatting is flattened to plain text with a markdown-style fallback. Alternatively, the Note can be exported as a PDF and attached to the Card if rich formatting fidelity is critical, determined during scoping.

Project.co time entries record duration, date, billable flag, and task association. Trello has no native time tracking object. We create a checklist item on the parent Card with the format '[billable] HH:MM - YYYY-MM-DD' in the item name, and optionally add a card label (Billable / Non-billable) using a pre-created Trello label. If the customer uses the Time Tracking Power-Up on Trello, we instead map time entries to that Power-Up's data structure via its API. The lack of hourly rate in Project.co (a known platform gap) is surfaced in the scoping report.

Project.co recurring tasks store a recurrence rule and next-run date. Trello has no native recurrence model. We create the Card with the task details and add a checklist item documenting the original recurrence rule (e.g., 'Recurrence: weekly on Monday'). For any Power-Up-based recurrence solutions (Planyo, Scheduled Card Creator, or similar), we note the recurrence rule in the card description for the customer to configure in their chosen Power-Up post-migration.

Project.co custom fields exist on Projects and Tasks across all tiers. We create matching Custom Fields in Trello's native Custom Fields Power-Up, using the same field name and mapping the type: Project.co text fields map to Trello text custom fields; number fields map to number; date fields map to date; dropdown/select fields map to Trello dropdown with options preserved. Trello's Custom Fields Power-Up is free and available on all tiers, but fields are per-card, not globally on a Board — we apply them to the relevant Cards during migration.

Project.co Clients access projects via a client portal link without consuming paid seats. We extract client email addresses and names from Project.co and provision them as Trello Workspace Members (Standard tier or above) or as Board Guests (Free tier, limited to 1 Board per guest). The customer's Trello tier determines whether we can grant Workspace-wide access or must scope guest access per Board. Role mappings (viewer vs editor) are recorded in the scoping report for the customer to configure post-migration.

Project.co Freelancers are external team members with per-project access. We extract freelancer accounts and map them to Trello Workspace Members or Board Members depending on the customer's chosen access model. Freelancer permissions (full task access vs comment-only) are documented from Project.co role settings and mapped to Trello Board permissions during scoping. The customer may need to send invitations post-migration if two-factor or SSO is enforced on the Trello Workspace.

Project.co team members map to Trello Workspace Members. We extract all internal team member accounts and match them by email. Admin-level team members in Project.co map to Workspace Admin in Trello; standard members map to Workspace Member. Owner status in Project.co maps to Workspace Primary Owner. User provisioning is coordinated with the customer so that Trello Workspace membership is established before Cards are assigned.

Project.co uses granular per-user roles scoped to individual projects (Admin, Member, Client, Freelancer). We extract role assignments for each user on each project. Trello's permission model is Board-level with four levels (Board Admin, Normal, Observer, Private) and Workspace-level roles (Workspace Admin, Workspace Member). We map Project.co roles to the closest Trello equivalent and document any gaps — for example, a Project.co role with comment-only access on a project maps to a Trello Board Observer or a Card-level restriction that the customer configures manually post-migration.