Migrate from ]project-open[ to monday Work Management

]project-open[ projects (project_id, inheriting from acs_objects) map to monday.com Boards. Each project becomes a Board, and the project's status lifecycle (potential → active → closed → archived) maps to Board-level status columns or a dedicated Status column on the board's items. We extract the full project hierarchy from acs_objects and acs_rels to preserve parent-child relationships, mapping sub-projects to Groups within the parent Board. The project_name and project_nr fields become the Board name and an identifier column respectively.

Tasks in ]project-open[ (task_id referencing the project tree) map to monday.com Items. Parent-child task nesting maps to monday.com's Subitem structure or to Group-level item organization within the board, depending on nesting depth. Status transitions (task_status_id) map to monday.com Status column values. Assigned user_id resolves to a monday.com Team Member via email lookup. Multiple task assignees in ]project-open[ create multiple Item Assignees in monday.com. We flatten deeply nested task trees (more than 2 levels) into grouped items with a Parent Task reference column rather than attempting sub-sub-item chains.

]project-open[ Companies (im_companies) with customer and provider roles map to monday.com Locations. Company name, address, and contact details become Location fields. Company-Contact relationships are preserved as Location assignments on Items and Boards. For organizations that use ]project-open['s CRM module for account tracking rather than project management, we recommend setting up a separate monday.com Board for account management with Company records as Items, using the Locations integration for physical office and address data.

]project-open[ Tickets (im_tickets) map to monday.com Items on a dedicated Support or Operations board. Ticket status and type enumerations (ticket_status_id, ticket_type_id) map to monday.com Status and Label columns. The ticket subject becomes the Item name, and the ticket description maps to an Item's Text column. Conversation threads migrate as a structured JSON log in a Long Text column with timestamps and author attribution preserved. Assignee user_id resolves to a monday.com Team Member.

Financial records in ]project-open[ (im_costs with variable_cost_p as 't'/'f' char) require custom column reconstruction in monday.com because monday.com has no native financial object. We extract cost amounts, cost types (expense, revenue, hours), and billing status as separate number and date columns on Items or as board-level numeric columns. The customer configures these column types during board setup. Costs associated with a specific project link to the project Board via a Connect Board column. Invoice numbers and billing status become text and status columns respectively.

Timesheet hours stored as cost entries in ]project-open[ (linked to users and projects via im_timesheet_* tables) migrate as Number columns on Items representing the logged work. Each timesheet entry becomes a row with the user, date, hours, and billing type stored as separate columns. monday.com's Workload View then allows managers to visualize logged hours per person. We preserve the original date, user assignment, and billing type from the source records.

]project-open[ user accounts (across acs_objects and im_employees) map to monday.com Team Members. We match by email address and map user_id, names, and active status. Role-based permissions in ]project-open[ (privilege hierarchies in acs_permissions) do not migrate directly; we document the role structure for the customer's admin to configure in monday.com's Team management settings. Inactive users become Guest accounts if historical assignments must be preserved.

]project-open[ dynamic attributes beyond the standard schema require a full pre-migration attribute discovery pass against all target object types. We query the dynamic attribute storage for projects, tasks, companies, and tickets, then map each discovered attribute to a monday.com column of the closest matching type (Text, Number, Date, Dropdown, or Checkbox). Custom fields with picklist values map to monday.com Labels or Dropdown columns. The customer reviews and approves the column configuration before migration.

Office objects in ]project-open[ (im_offices) storing physical location data linked to companies and projects via acs_rels map to monday.com Locations. We preserve office name, address, and associations to relevant business objects. Locations are created in monday.com during the board setup phase and linked to Items via the Location column.

Configuration items tracked as typed Business Objects in ]project-open[ map to Items on a dedicated IT Operations or Assets Board in monday.com. CI type, attributes, and dependency relationships migrate as separate columns (CI Type as a Label column, attributes as Text columns, and dependencies as a Connect Board column linking related items). The customer defines the exact column schema during board configuration.

Hierarchical categories in ]project-open[ used to classify objects (ticket type, project sector) are extracted as category_id to label mappings. We map category IDs to string labels and create monday.com Label or Dropdown columns with the category taxonomy as option values. The customer selects the target column type during scoping based on whether multi-select or single-select classification is appropriate.

Documents stored as separate objects in ]project-open[ (with references in acs_objects) may reside in the filesystem or database depending on configuration. We identify file storage locations during discovery, extract file references, and create monday.com File Upload column entries for each document linked to the relevant Item. Binary file contents are preserved as attachments. Large file attachments (over 10 MB per monday.com's limit) are flagged for the customer to migrate manually or store externally with a link stored in the Item.