Migrate your ]project-open[ data

Projects are the central Business Object in ]project-open[, keyed by project_id and inheriting from acs_objects. We preserve the full project hierarchy, status lifecycle (potential → active → closed → deleted), and all parent-child relationships via acs_rels join tables.

Tasks are stored as a separate task_id key referencing the project tree. We maintain parent-child task nesting, status_id transitions, and assignments to users or teams by querying the task and acs_rels tables together.

Companies are im_companies objects supporting both customer and provider roles via object_type_id. We map company_name, company_status_id, and the type classification. All company-contact relationships are preserved through acs_rels.

Tickets (im_tickets) use ticket_status_id and ticket_type_id integer keys. We map status/type enumerations, ticket descriptions, assignees, and conversation threads from the ticket and associated message tables.

Financial records live in im_costs with variable_cost_p as a boolean 't'/'f' char field. We extract invoice amounts, cost types, billing status, and any associated project or company references for accurate financial reconstruction.

Timesheet hours are stored as cost entries linked to users and projects. We preserve the hours logged, date, billing type, and user assignment. Effective-dated entries are supported via the object creation metadata in acs_objects.

User accounts are stored across acs_objects and application-specific tables. We map user_id, names, email, permissions, and group memberships. Role-based access control uses privilege hierarchies that require careful mapping to the destination's permission model.

Custom fields are stored per-object as dynamic attributes beyond the standard schema. Since the platform allows unrestricted custom field creation, we perform field-level discovery before migration and build a mapping table to align custom attribute names and data types with the destination system.

Office objects store physical location data and are linked to companies and projects via acs_rels. We preserve office name, address, and associations to the relevant business objects.

Categories are stored in a hierarchical category system used to classify objects (e.g., ticket type, project sector). We map category IDs to their string labels and reconstruct the taxonomy in the destination, flagging any categories that lack a direct equivalent.

Documents are stored as separate objects with references in acs_objects. Binary files may be stored in the filesystem or database depending on configuration. We identify file storage locations during discovery and ensure attachment references are updated after migration.

Configuration items track IT assets and their relationships, stored as typed Business Objects. We map the CI type, attributes, and any dependency relationships to the destination's asset or configuration management schema.