Migrate from ONES.com to Asana

ONES Project maps directly to Asana Project. Project name, description, template origin (Scrum, Kanban, general), and created/modified timestamps migrate. Project-level member roles map to Asana project membership. The project template type is preserved in a custom field project_template__c so the customer's admin can reapply the appropriate template structure in Asana if desired.

ONES Task maps to Asana Task with parent-child hierarchy preserved through Asana's subtask structure. Task fields that migrate directly include name, description (rich text), assignee, priority, status workflow, due date, start date, time tracking values, and created/modified timestamps. Custom fields on Tasks translate to equivalent Asana custom fields by type: text fields to Asana Text, numeric fields to Number, date fields to Date, dropdown fields to Multi-select or Enum picklist.

ONES Bug is a specialized work item with severity, steps-to-reproduce, and environment fields. We map Bugs to Asana Tasks with a custom Boolean field is_bug__c set to true, a custom Enum field bug_severity__c (Critical, High, Medium, Low), and steps_to_reproduce__c as a Text field. Bug status workflows map to Asana task sections or a dedicated Status Enum. Bugs can be isolated into a separate Asana Project if the customer prefers a dedicated bug board.

ONES Requirements are distinct work items capturing product specifications and linking to Tasks or TestCases. Asana has no native Requirements object, so we map Requirements to Tasks with a custom Boolean field is_requirement__c set to true, and the requirement body migrates to the task description. Links to downstream Tasks and TestCases are preserved as Asana subtasks or custom field references (requirement_links__c) so traceability is not lost.

ONES TestCase records contain test steps, expected results, and pass/fail history linked to Requirements and Builds. Asana has no native test-case record type. We map TestCases to Tasks with a custom Boolean field is_test_case__c, a Text field test_steps__c holding the step sequence, and a Text field expected_results__c. Test run history migrates as subtasks or as comments on the parent TestCase task. If the customer requires a dedicated test management tool post-migration, we note this as a separate tooling decision.

ONES Sprint is a time-boxed iteration containing a set of Tasks with start/end dates and goal description. Asana has no native sprint object. We preserve sprint associations by applying ONES Sprint start and end dates to the relevant Tasks using Asana Start Date and Due Date fields, enabling Timeline view visualization of sprint scope. Sprint goal description migrates as a custom Text field sprint_goal__c. Active versus completed sprint status is tracked via a custom Enum field sprint_status__c.

ONES Wiki pages migrate to Asana Goals if they represent project-level documentation, or to Project Description fields for project-level context. Rich-text content, headings, and lists transfer directly. Complex tables that exceed Asana's rendering width are flagged during audit and exported as Word (.docx) attachments to preserve layout. ONES wide-table PDF export truncation is a known issue; we use the Word export path for table-heavy pages.

ONES Project members assigned to Projects, Tasks, Bugs, and TestCases map to Asana Users by email address. We resolve every distinct ONES Owner referenced across all migrating records and match by email against the destination Asana organization's user list. Any ONES user without a matching Asana User goes to a reconciliation queue for the customer's admin to provision before record import proceeds.

Attachments on Tasks, Bugs, and Wiki pages are downloaded from ONES storage and re-uploaded to Asana via the Asana API. Asana's API enforces a 100MB per-file attachment limit. Any attachment exceeding this threshold is flagged during audit, and we provide a list of oversized files with their record association so the customer's admin can either store them externally and link, or proceed without them. Standard-sized attachments migrate in batched API calls with retry handling.

ONES Project custom fields (text, number, date, dropdown, user reference) map to Asana custom fields of equivalent type. Text maps to Asana Text, numbers to Number, dates to Date, single-select dropdowns to Enum, multi-select dropdowns to Multi-select Enum, and user references to Assignee or Members. Custom field values are mapped to the newly created Asana custom fields during data load. Fields without an Asana equivalent (rare, but noted during discovery) are listed in the migration report for the admin to address.

ONES Project automation rules (task status triggers, assignee actions, notification rules) have no documented export or migration API. We do not attempt to migrate automation rules. During discovery, we inventory every active automation rule and deliver a written rules inventory document with each rule's trigger conditions, actions, and a recommended Asana Rules equivalent. The customer's admin rebuilds rules in Asana Rules (available on Premium and above) post-migration.

CI/CD pipeline definitions in ONES Build and ONES Pipeline are tightly coupled to the ONES execution environment and connected repositories. These configurations are not portable across platforms. We do not migrate pipeline data. We flag the existence of ONES Pipeline records during discovery and note that pipeline definitions must be rebuilt in the destination CI/CD platform (GitHub Actions, GitLab CI, Jenkins, or similar). Build records that are referenced by TestCases are noted as read-only historical data.

Comments on Tasks, Bugs, Requirements, and TestCases in ONES migrate as Asana Comments on the corresponding Tasks. Comment author is resolved by email match to the destination Asana User. Comment timestamp is preserved. Rich-text formatting in ONES comments is simplified to plain text in Asana Comments where the formatting model differs.