Migrate from awork to Trello

awork Projects map 1:1 to Trello Boards. Project name becomes Board name, project description becomes Board description, and project start/end dates are noted in the Board description or as a custom date field on each Card. If the source awork workspace contains multiple projects targeting the same Trello Workspace, we create a Board per project and optionally group boards by client using Trello's Board organization features.

awork Clients are independent objects with no direct Trello equivalent. Trello does not have a native Client or Account object separate from Projects. We map Clients to Trello Board Labels (colored tags applied to Cards) so that cards can be filtered by client across boards. Alternatively, for accounts using Trello Enterprise with multiple Workspaces, Clients can map to separate Workspaces. The customer selects the strategy during scoping.

awork Tasks map 1:1 to Trello Cards. Task name becomes Card title, task description (rich text) becomes Card description, due date maps to the Card due date field, and assignee maps to Card member. Task priority maps to a Trello Label (e.g., High/Medium/Low labels pre-configured on the destination Board). The awork task status value maps to the Card's List position (which List it belongs to) rather than a custom field if the awork status vocabulary is small enough to map to existing Lists.

awork Subtasks map to Trello Checklists on the corresponding Card. Each subtask name becomes a checklist item. Checklist item completion status (checked/unchecked) migrates from awork. Trello supports multiple checklists per card, which covers awork's subtask nesting at one level of depth. If awork subtasks have their own subtasks beyond one level, we flatten to checklist items with a naming convention (e.g., '- Sub-subtask text') to preserve the hierarchy within a single checklist.

awork workspace users map to Trello Members by email address match. We extract the full user list during scoping and match against the destination Trello workspace members. If a Trello account lacks an invited user, we flag the discrepancy in the scoping report for the customer admin to provision before migration so that Card assignments resolve correctly on import.

awork per-workspace status values require value mapping to Trello Lists. We collect every unique status name, color, and order from the source workspace during discovery, then map them to existing Trello List names or create new Lists on each Board. Status ordering is preserved by setting the List sequence. If awork uses many statuses that exceed a reasonable number of Lists per Board, we map the most-used statuses to Lists and store remaining status values in a Card custom field.

awork time entries have no native Trello equivalent. We offer two strategies: (1) Custom number field on each Card holding the total logged time in hours, populated from the sum of time entries for that task; (2) Structured attachment (CSV or text file) on each Card listing individual time entries with date, user, duration, and billable flag. Strategy selection happens during scoping based on whether the team uses Trello Premium (required for Custom Fields) and whether they need granular time entry detail or just a summary.

awork workspace-level custom fields activated per project must be pre-configured in Trello before migration because Trello Custom Fields are defined per Board. During scoping, we list every activated custom field per project, check whether the corresponding Board has an equivalent Custom Field defined, and flag gaps. Supported Trello Custom Field types (Number, Date, Dropdown, Checkbox, Text) map from awork field types. Fields not supported by Trello (e.g., complex calculated fields) are documented as unmapped with a workaround recommendation.

awork Project Templates define reusable structures including default tasks, statuses, and custom field configurations. Trello does not have a native template-with-tasks feature (Trello's template feature duplicates cards, not full project structures). We document the template structure (tasks, subtasks, default field values, and status configuration) in a written template inventory that the customer's admin uses to recreate Board templates in Trello. Template mapping is not a data migration; it is a manual rebuild scope documented during migration.

awork Tags are key-value labels applied to tasks. We map tag names 1:1 to Trello Labels on the destination Board. Label colors are assigned based on Trello's default palette. If awork uses many tags relative to the number of available label colors (Trello limits Labels to a small set of predefined colors per Board), we normalize tag groups and document any overflow in the mapping notes for admin review.

Archived tasks in awork require explicit export during scoping because awork does not include archived records in standard Excel exports. We query the source for archived tasks and recreate them in Trello as archived Cards (Trello Cards can be archived after import). This step is opt-in and adds time to scoping because the customer's admin must confirm which archived projects or tasks are in scope. Archived cards not included in the export must be manually restored in awork before export or reconstructed manually in Trello post-migration.

awork Workflows (property-triggered automation rules) have no Trello equivalent as migrated code. We do not migrate Workflows as automation code. We deliver a written inventory of every active awork Workflow including its trigger, conditions, actions, and a recommended Butler rule equivalent with natural-language steps the customer can configure. The customer's admin rebuilds Butler rules post-migration. This inventory is included in the standard migration deliverables.