Migrate from ONES.com to Microsoft Project

Each ONES.com Project maps to one Microsoft Project file (MPP) or one Project Online project. We extract the project name, description, start date, and target end date and create the destination project structure before any tasks are inserted. Multi-project organizations with shared resource pools may need a Project Server or Project Online Enterprise Resource Plan (ERP) configured, which we flag during scoping.

ONES.com Tasks map directly to Microsoft Project Tasks. We preserve the task name, start date, finish date, percent complete, priority, assignee (mapped to Project Resource), and the parent-child hierarchy by setting the WBS outline level. Subtasks in ONES.com become indented tasks under their parent summary task. Predecessor dependencies (Finish-to-Start, Start-to-Start, etc.) from ONES.com task links migrate as Project predecessor relationships using the predecessor task ID.

Microsoft Project has no native Sprint object. We handle this in one of two ways depending on the customer's reporting needs: (1) create a summary task per Sprint with its start and end date as the task start/finish, and nest the sprint's assigned Tasks under it, or (2) add a custom Text field (Sprint Name) and two date fields (Sprint Start, Sprint End) to the task template and populate them from the ONES.com Sprint assignment. We agree on the approach during scoping based on whether the customer uses sprint velocity or burndown reporting in Microsoft Project.

ONES.com Requirements are distinct work items capturing product specifications. Microsoft Project has no native Requirements object. We map Requirements to either Milestone tasks (if the Requirement has a single deliverable date) or Summary Tasks (if it wraps multiple child Tasks) with a custom Text field (Requirement ID) and a custom Text field (Requirement Status) carrying the original ONES.com status. TestCase linkage from ONES.com does not migrate; we document TestCase-to-Requirement links in the handoff report for the customer's QA team to reassign manually.

ONES.com Bugs map to Microsoft Project Tasks with a custom Text field (Work Item Type) set to 'Bug' and a custom Text field (Bug Severity) carrying the ONES.com severity value. Steps-to-reproduce and environment details from ONES.com are stored in the Task Notes field as structured text. We flag any Bug that was linked to a Task in ONES.com by adding the predecessor Task ID to a custom Text field (Linked ONES Task) in the Microsoft Project file.

ONES.com project members map to Microsoft Project Resources. We extract the member name and email, create a Resource record in the destination project, and map the ONES.com assignee field to the Resource Assignment. If a member in ONES.com has no corresponding user in the destination Microsoft Project environment (common for .mpp file migrations without a PWA connection), we create the Resource as a generic resource with the name and note it for the admin to link to an Active Directory account post-migration.

ONES.com custom fields on Tasks (text, number, date, dropdown, user reference) map to Microsoft Project custom fields. We use the equivalent Microsoft Project custom field type: Text fields for string values, Number fields for numeric values, Date fields for date values, and Flag or Outline Code fields for dropdown selections. We define the custom field set in the destination project template before data import and preserve the ONES.com field label in the column header name.

ONES.com Wiki pages do not have a migration path to Microsoft Project. Microsoft Project (desktop and PWA) has no native wiki or documentation storage. We extract the page tree and content during discovery and deliver it as a Word (.docx) export organized by project folder. The customer's admin stores these alongside the .mpp file in SharePoint or a document management system. Wide-table pages are exported as Word to avoid the PDF truncation issue documented in the ONES.com source platform context.

ONES.com TestCases managed in ONES TestCase are not migrated to Microsoft Project. TestCases contain test steps, expected results, and pass/fail history that have no equivalent in Microsoft Project. We extract TestCase records as a structured CSV export organized by Requirement ID so the customer's QA team can import into their chosen test management tool (Azure Test Plans, qTest, TestRail, or Zephyr) post-migration.

ONES.com automation rules (trigger-action logic for task status changes, assignments, notifications) are not exposed via any documented export endpoint and cannot be migrated. We identify all active automation rules during discovery and deliver a written inventory listing each rule's trigger, conditions, and actions with a recommended manual rebuild approach. Microsoft Project does not have native automation; rebuild options are Microsoft Power Automate (for Project Online) or VBA macros (for Project Desktop), scoped separately.

Pipeline definitions in ONES Build and ONES Pipeline are tightly coupled to the ONES execution environment and connected repositories. These cannot be exported or migrated. We migrate Build and TestCase records as data but note that the CI/CD pipeline definitions must be rebuilt in the destination platform (GitHub Actions, Azure DevOps Pipelines, or Jenkins) post-migration. This is documented in the handoff report with a pipeline reconstruction checklist.