Migrate from OpenProj to monday Work Management

Each OpenProj Project maps to a monday.com Board, with the project name becoming the board title. For organizations with many OpenProj projects, we create monday.com Workspaces as top-level containers to group related boards by department or portfolio. Project description migrates as a Long Text column or board-level Workdoc. Active and archived status is preserved; archived OpenProj projects become archived monday.com boards.

OpenProj Work Packages map 1:1 to monday.com Board Items. Subject becomes Item name; description migrates to the Item's Long Text column or summary section. Type (Task, Feature, Bug, Milestone, Phase, Epic) maps to a Status column with one status value per OpenProj type, preserving the type label so that filtering by type remains possible in monday. Assignee migrates to the Person column by resolving the OpenProj user's email against the monday.com member list.

OpenProj's parent-child Work Package relationships with unlimited nesting depth require a structural decision during scoping. monday.com supports exactly one level of Subitems per Item. We flatten multi-level hierarchies by creating subitems for direct children; grandchildren and deeper levels are evaluated for inclusion as subitems of the parent subitem or are consolidated into a notes column listing the remaining hierarchy. The customer confirms the flattening strategy during scoping because it affects what is visible and filterable in the destination board.

OpenProj's global type definitions (Task, Feature, Bug, Milestone, Phase, Epic, and any custom types) migrate as named values in a monday.com Status column. We create one Status column per OpenProj type set per board. Teams that rely on type-based filtering in OpenProj can replicate this in monday by grouping or filtering the board by the Status column that holds the type value.

OpenProj's globally-defined statuses (New, In Progress, Resolved, Closed, and any custom statuses) migrate as Status column values in monday.com. Workflow state per type is not preserved as a monday.com feature because monday.com does not have per-type workflow state restrictions; we document the original OpenProj type-status workflow matrix so the customer's admin can decide whether to recreate any gating rules as automations.

OpenProj Enterprise custom fields (text, integer, float, Boolean, list, date, user, hierarchy) map to monday.com column types: Text to Text column, numbers to Numbers column, Booleans to Checkbox column, dates to Date column, user references to Person column, and list values to Dropdown or Status column. We pre-create all columns before data migration begins. Any custom field referencing a User (Enterprise-only) requires that the referenced user exists in monday.com, which we resolve during the User mapping phase.

Time entries linked to OpenProj Work Packages require monday.com Pro for a dedicated Time Tracking column. For Standard and Basic plans, we create a Numbers column named 'Hours Logged' and write the total spent time as a decimal value per Work Package. During scoping, we confirm whether the destination account is on Pro and whether individual time entry records (as opposed to aggregate totals) must be preserved; individual entries can be modeled as Subitems with a Time Tracking column on Pro plans.

OpenProj file attachments (stored metadata: filename, mime type, author, created-at) have no native monday.com equivalent because monday.com does not host files. We establish a Google Drive or Dropbox integration on the destination account, upload source attachments to a shared Drive folder organized by project, and create a Link column on each Item pointing to the corresponding Drive file or folder. We preserve filename, upload date, and original author in a column named 'Original File Metadata' for audit purposes.

OpenProj user accounts (name, email, admin flag) migrate to monday.com workspace members by email match. Global OpenProj roles (Admin, Standard Member, Guest) and per-project role assignments do not have a direct monday.com equivalent because monday.com uses workspace-level roles (Admin, Member, Viewer) and board-level permissions. We preserve the original OpenProj role structure in a User Role Map document delivered with the migration so the customer's admin can assign appropriate monday.com roles after migration.

OpenProj wiki pages (Markdown content with attachments) have no native monday.com equivalent. We create a Workdocs board linked to each destination Project board, convert wiki Markdown to Workdoc pages, and link each Workdoc to the corresponding board via a Link column on the board or a Workdocs section. If the destination account does not have Workdocs enabled, we create a Long Text column on the board named 'Project Wiki' with wiki content migrated as formatted text. The customer selects the strategy during scoping.

OpenProj Meeting records (title, date, duration, location, attendees, minutes) map to monday.com Items on a Meetings board. Title becomes Item name; date and duration map to Date and Numbers columns; attendees map to Person column values; location maps to a Text column; minutes map to a Long Text column. A separate Attendees column stores the attendee list as text for quick reference. We create one Meetings board per OpenProj project or a centralized Meetings board if the customer prefers.

OpenProj Versions (sprints, release milestones) carry a name, description, status, and target date. We map versions to monday.com Board Groups with the version name, optionally using a Status column value for the version status (scheduled, active, closed). Target date maps to a Date column. For teams using OpenProj's sprint velocity and burndown features, we note that these are not reproducible in monday.com without a third-party integration or a separate analytics dashboard.