Migrate from awork to monday Work Management

awork Projects map directly to monday.com Boards. Each awork project becomes a board with the project name as the board title. The project description, start date, and end date migrate to the board's name and optional description field. Project status (a per-workspace value) maps to the monday.com board's status column options, which we configure before migration. Budget data from awork has no native monday.com equivalent and migrates as a custom number column.

awork Tasks map to monday.com Items within the target Board. Task name becomes the item title, description migrates as the item's text column, due date maps to the date column, and priority migrates to a label or number column. Assignee resolves by matching awork user email to monday.com user email. Task status from awork (a per-workspace value) maps to a monday.com status column configured per-board with a value map collected during discovery.

awork Subtasks map to monday.com Sub-items. Sub-items are available on monday.com Standard, Pro, and Enterprise plans. We flag any board migration that includes subtasks if the destination monday.com account is on the Basic plan, as sub-items are not available at that tier. The parent-child relationship is preserved by linking sub-items to their parent item in monday.com. We flag subtask ordering if the destination account uses a view where ordering is not natively preserved.

awork Time Entries have no native monday.com equivalent. We create a dedicated time-tracking board or add time-tracking columns to each project board. Each time entry becomes an item with columns for user (linked to the monday.com user), start time, end time, duration (calculated), billable flag (yes/no label column), and task reference (text or link column). The billable flag from awork preserves billing categorization. Time entries with no task association in awork become items in the dedicated time-tracking board with a project reference column.

awork workspace members map to monday.com User accounts by email address. We extract all distinct awork users referenced on tasks, projects, and time entries and match by email to the monday.com user list. Any awork user without a matching monday.com account is flagged for admin provisioning before migration. User roles and workspace permissions in awork have no direct monday.com equivalent and are documented for the admin to configure post-migration.

awork Custom Fields map to monday.com columns. The critical constraint is that awork custom fields must be activated per-project before they appear at the task level. We audit every custom field's project-level activation status during scoping and flag any field that is not active for a given project. These fields will not appear in export for tasks in that project. The customer either activates the missing fields before export or accepts that those fields will not migrate. We do not infer or fabricate values for inactive fields.

awork Project Statuses are defined per-workspace with custom names, colors, and ordering. There is no global status vocabulary. We collect the complete status schema during discovery and create matching monday.com status column options per-board with corresponding colors and ordering. If awork workspaces have conflicting status names (same concept with different labels), we build a normalization table during scoping.

awork Tags are key-value labels applied to tasks for categorization. We map tag names 1:1 to monday.com tag column values. If the destination board uses the new monday.com column types, tags appear as label options within the tag column. We flag any tag normalization required if the destination board has existing tag labels that conflict with awork tag names.

awork Project Templates define reusable project structures including default tasks, statuses, and custom field configurations. monday.com does not have a native project template import. We document the template structure (task names, default assignees, default due dates, custom field values, and status definitions) in a written template inventory. The customer uses monday.com's duplicate board feature or manually creates boards from the inventory. This is not a direct data migration.

awork Clients are top-level records that cannot have time entries logged directly against them. Teams migrating to monday.com frequently restructure by creating a Board per client. We map awork Client records to monday.com Boards and link project-boards as sub-boards or group them by client name. The customer decides during scoping whether clients become top-level boards or a client tag column on existing boards.

awork Notes attached to tasks map to monday.com Item Updates. We preserve the note body, author (matched by email to monday.com user), and creation timestamp. If the note contains structured content, the author and timestamp migrate with the note body as plain text. Notes with attachments migrate the attachment references separately if they are accessible URLs; binary file attachments have no direct monday.com equivalent and are flagged for manual re-upload.

awork Workflow Automations have no direct monday.com equivalent. We audit every active awork workflow (trigger type, conditions, actions) and document it in a written automation inventory with recommended monday.com automation equivalents. The customer's admin rebuilds automations in monday.com's Automation Builder. This inventory is a deliverable, not a migrated artifact.