Migrate from ]project-open[ to Jira

]project-open[ Projects (project_id inheriting from acs_objects) map directly to Jira Projects. The project_id becomes the Jira project key prefix (3-character uppercase alphanumeric). Project status lifecycle (potential, active, closed, on-hold) maps to Jira project category or we flag statuses requiring Jira Status mapping configuration. The acs_rels join table stores project-to-project parent-child relationships which we reconstruct as Jira Epic-Project or Project hierarchy links.

Tasks in ]project-open[ are stored as task_id records keyed against the project tree. We extract parent-child task nesting from the task tree (task_p_id parent reference), resolve the status transitions via status_id enumeration, and assign users and teams from acs_rels memberships. Jira Issue creation uses the parent key to establish sub-task hierarchy, and task priority maps from ]project-open[ priority_id to Jira Priority field.

Ticket records (im_tickets) store ticket_status_id and ticket_type_id as integer keys. We map these enumerations to Jira Status values and Issue Type (Bug, Task, Story) during the transform. Ticket description, conversation threads from im_tickets_and_invoices and associated message tables, and assignee from the im_ticket_assignee_map all migrate as Issue body, comments, and Assignee field. We traverse acs_rels for any ticket-to-project or ticket-to-company links to set the Jira Project and Reporter.

]project-open[ Companies (im_companies objects) with company_name, company_status_id, and object_type_id (customer or provider classification) map to Jira Organizations. We resolve all company-contact relationships from acs_rels and set the Organization as the primary entity with associated user accounts as Jira users. Companies without a Jira-matched Organization are created during the Organization load phase before any Issue import that references them.

Financial records in ]project-open[ (im_costs) store invoice amounts, cost types, and billing status with variable_cost_p as a 't'/'f' char. Timesheet entries (cost entries linked to users and projects) merge into Jira Issue Worklog records. We convert the cost amount, billing type, and effective date to Jira Worklog fields (timeSpentSeconds, started, author), and resolve the cost's project_id and user_id to Jira Issue and User references. ]project-open[ cost approval workflows and invoice generation are not migrated; we document the financial approval chain as a written handoff for the customer's Jira admin to configure in Jira Automation or a third-party billing integration.

Timesheet hours are stored as cost entries in im_costs linked to users and projects. We extract hours_logged, date, and billing type for each entry, resolve the user_id to a Jira User account, and resolve the project_task_id to the target Jira Issue. Effective-dated entries are supported via the object creation timestamp preserved as the Jira Worklog started field.

User accounts span acs_objects and application-specific tables in ]project-open[. We extract user_id, names, email, and group memberships from the OpenACS auth hierarchy. Resolution to Jira Users happens by email match. Users without an active Jira account are held in a reconciliation queue for the customer's Jira admin to provision before the main migration batch begins. Permissions and role hierarchies in ]project-open[ are not migrated; Jira project role configuration is a separate administrative step documented in the handoff.

Dynamic custom attributes in ]project-open[ are not stored as columns in the main tables; they exist in a separate dynamic attribute storage that requires per-object-type field discovery queries. We run a full attribute discovery pass across all object types before designing the Jira custom field schema. Each discovered custom attribute is provisioned as a Jira custom field of the appropriate type (text, number, date, select, multi-select) before migration, and the attribute values are loaded as custom field values in the same migration batch.

Office objects in ]project-open[ store physical location data linked to companies and projects via acs_rels. We extract office name, address, and the acs_rel associations, then attach address data to the corresponding Jira Organization record. If Jira Organizations are not in use, the location data attaches to the Project description or a custom Project field.

Categories are stored in a hierarchical category system used to classify objects (ticket type, project sector, cost type). We map category IDs to string labels during the transform phase and reconstruct the taxonomy as Jira Components (per-project) or Labels (cross-project). The customer's Jira admin chooses the categorization strategy during scoping.