Migrate from ONES.com to Trello

ONES Project maps directly to a Trello Board. The project name becomes the board title, and project description maps to the board description field. We set the board visibility (private, team, public) based on any ONES project visibility settings, defaulting to private if no explicit setting exists. Each ONES Project with active tasks and bugs becomes a dedicated board; if the customer prefers consolidated boards by team, we offer a workspace consolidation strategy during scoping.

ONES Tasks migrate as Trello Cards. The task title becomes the card name, description migrates as card description (with ONES rich-text converted to Trello's markdown subset), assignees map to Trello members by email, due dates map directly, and priority labels map to color-coded Labels (High=red, Medium=yellow, Low=green). Subtasks in ONES become Checklist items on the parent Card in Trello, preserving the parent-child relationship. Task status in ONES (To Do, In Progress, Done) maps to card position within the relevant List, or to a dedicated Done list.

ONES Bugs migrate as Trello Cards with a Bug Label applied for visual differentiation. Severity (Critical, Major, Minor) migrates as a Trello Label color; steps-to-reproduce and environment fields migrate as card description sections. The link between Bug and parent Task in ONES maps to the Card's Checklist or to a Card link if Trello Card Peek is available. Bugs in ONES are often tracked on a separate Bug board; we offer either a dedicated Bug board or a Bug Label filter on the main board as the customer prefers during scoping.

ONES Sprints have start date, end date, goal, and task membership with no direct Trello equivalent. We map Sprint assignment in one of two ways, chosen during scoping: as Card due dates (set to the Sprint end date) with a Sprint name Label, or as a dedicated List per Sprint within the board. The Sprint start date is preserved in a custom field if the Trello Standard or Premium Power-Up custom fields are active. We note that Trello has no native sprint velocity or burndown tracking; these must be rebuilt in Trello reports or a third-party analytics Power-Up post-migration.

ONES Requirements are distinct work items capturing product specifications and linking to Tasks and TestCases. Trello has no native Requirements object, so we map Requirements to Cards with a Requirements Label. The linkage between Requirement and child Tasks in ONES is preserved by placing linked Tasks as Cards in the same List or by adding a Checklist on the Requirement Card listing linked task titles. Requirements with no linked tasks migrate as standalone Cards with a Requirements Label and description content preserved.

ONES TestCases contain test steps, expected results, and pass/fail history linked to Requirements and Builds. Trello has no native test-case management, so we map each TestCase to a Card with a TestCase Label. The test steps and expected results migrate as a Checklist with step number, description, and expected result as the checklist item text. Pass/fail status and last-run date migrate as custom fields (Standard or Premium Power-Up required). TestCase-to-Requirement links in ONES are preserved as a Checklist on the Requirement Card listing linked test case titles.

ONES Wiki pages migrate as Card attachments in Trello. We export page content as a Word (.docx) file rather than PDF because ONES Wiki PDF export silently truncates tables exceeding approximately 720px width. The .docx attachment links to the Card representing the related work item. If the Wiki page has no linked work item, we create a standalone Card with the page title as the Card name and the .docx as an attachment. Page tree structure in ONES Wiki is preserved as a Card checklist or a linked board structure if the customer requests it during scoping.

Project members in ONES map to Trello members by email address. We extract every distinct email referenced on Tasks, Bugs, TestCases, and wiki pages, then match against the Trello workspace members. Members without a matching Trello account go to a reconciliation queue for the customer's admin to provision before record migration. ONES role-based permissions (Owner, Admin, Member, Guest) do not map directly to Trello roles; we recommend a Trello workspace role audit post-migration to align with the customer's desired access model.

ONES custom fields on Tasks, Bugs, and TestCases (dropdown, text, number, date, user reference) map to Trello Power-Up custom fields if the customer has Trello Standard or Premium. Trello Standard includes custom fields as a native Power-Up; Premium adds additional field types and board-level custom fields. We flag during scoping whether the destination workspace has the required plan, and we note that custom field data that does not fit Trello's type model (for example, ONES multi-select user references) may require a text representation or a separate tracking approach in Trello. Custom fields are migrated as text if Trello Premium is not available.

Attachments on ONES Tasks, Bugs, and Wiki pages are downloaded from ONES storage and re-uploaded as Card attachments in Trello. We preserve the original filename and file type. Trello has a per-board attachment limit (10 MB on Free, 250 MB on Standard and Premium); we verify total attachment volume against the destination plan during scoping and flag any attachments that exceed the limit. File-size-over-limit items are noted in the migration inventory for the customer to address manually.

Automation rules in ONES Project (task status change triggers, assignee notifications, field updates) are not exposed via a migration endpoint and cannot be exported. We identify all active automation rules during discovery and deliver a written automation inventory listing each rule's trigger, conditions, and actions with a recommended Trello Butler equivalent. The customer's admin rebuilds these in Butler post-migration. We do not migrate automation logic as code.

CI/CD pipeline definitions in ONES Build and ONES Pipeline are tightly coupled to the ONES execution environment and connected repositories. These configurations do not port across platforms and must be rebuilt in the destination CI/CD system (GitHub Actions, GitLab CI, Jenkins, or similar). We migrate the ONES Build and TestCase records as data but flag that pipeline definitions require a separate CI/CD rebuild project post-migration.