Migrate from Project.co to monday Work Management

Each Project.co Project maps to a monday.com Board at migration. The Project name becomes the Board name, the description becomes the Board description, and the project status (Active / Archived) maps to the Board state. We create Boards in monday.com before any Items are imported so that the Board ID is available as a foreign key during Item migration. If the customer prefers a single monday.com account-level Board with Groups per project, we restructure at scoping time based on the customer's preferred organizational model.

Project.co Tasks map to monday.com Items. Task title becomes Item name, description becomes the Item description field, assignee maps to monday.com person column, due date maps to the Date column, and status maps to the Status column with stage labels matched to the destination board's Status options. Subtasks in Project.co are not a distinct object but are linked tasks; we create them as separate Items in monday.com within the same Group and optionally link them using the Dependencies column if the Standard+ tier is in scope.

Project.co Discussions are per-project threaded message feeds. We flatten each thread as a chronological list of Update entries on the corresponding Item in monday.com. Each comment preserves author, timestamp, and body text. File attachments referenced in Discussion threads are downloaded separately and re-uploaded to the relevant Item's Files section. The chronological ordering of the thread is preserved by setting Update timestamps to the original comment timestamps.

Project.co Files are uploaded to project-level folders. We download the binary file content and re-upload to monday.com on the corresponding Item or Board with the same folder path preserved in the file name. File metadata (uploader, upload date) is preserved in the File description field. Large file counts extend the export timeline significantly because each file requires individual download from Project.co's UI; we flag the total file volume during scoping.

Project.co Notes are standalone rich-text documents attached to Projects. We create Items in monday.com with the Note title as the Item name and the Note content in the description field. Rich-text formatting is preserved where the destination supports it; complex formatting is converted to plain text with headings and bullet points preserved as structural markers.

Project.co time entries (duration, date, billable flag, task association) map to the monday.com Time Tracking column if the destination account is on Standard+ tier. The billable flag maps to a Status or Label column in the same Item. Hourly rates are not stored in Project.co and therefore cannot be migrated; we surface this gap in the scoping report and document the manual rate configuration required per user or per project in monday.com. Duration data is preserved in HH:MM format in the Time Tracking column.

Project.co recurring tasks store a recurrence rule and next-run date. We create the Item in monday.com and document the recurrence pattern in the Item description. monday.com does not have native recurring task functionality on the free or Basic tiers; on Standard+ the customer can create a monday automation to recreate the recurrence, which we document in the post-migration rebuild inventory. Recurring task rules require manual rebuild in the destination.

Project.co custom fields on Projects map to monday.com columns on the Board. We map text fields to Text columns, number fields to Numbers columns, date fields to Date columns, and dropdown fields to Label or Dropdown columns. The column is created at the Board level before Items are imported so that values map correctly during insert.

Project.co custom fields on Tasks map to monday.com Item columns. The field name and type are matched to the closest monday.com column type. Multi-select checkbox fields map to Label columns with multiple selections; single-select dropdown fields map to Dropdown columns. Custom field options are preserved as column option values in monday.com.

Project.co uses granular per-user roles scoped to individual Projects (Admin, Member, Client, Freelancer). monday.com does not have an equivalent per-project role model. We map Project.co Admins and Members to monday.com Board Members, and Project.co Clients to monday.com Guest access. Guest limitations (no Item creation on some tiers, no dashboard access) are documented in the scoping report for the customer to review against their permission requirements. Full granular role mapping requires post-migration manual configuration.

Project.co Clients access Projects via a client portal link and are not counted as paid seats. We create Guest accounts in monday.com and map their Project invitations to Board invitations. Client email addresses and names migrate; the customer must send new board invites post-migration. Note that Guest billing on monday.com varies by tier (included on some tiers, limited seats on others), which is surfaced in the scoping report.

Project.co Team Members map to monday.com Members. We extract all active team member accounts from Project.co and provision corresponding accounts in monday.com before migration. The seat count is reconciled during scoping: if the customer is at or near the Project.co tier ceiling (3 / 10 / 30 / 100), any migration-assist users must be added before the export window opens. Owner assignment on tasks migrates by email match to monday.com Members.