Migrate your OpenProj data

Projects are the top-level container in OpenProject. They hold members, roles, and a configurable set of Modules (work packages, wiki, meetings, documents, costs). Both Community and Enterprise editions support unlimited projects. We preserve project hierarchy, member assignments, and active module configuration during migration.

Work Packages are the core task entity, with a fixed schema of type, status, priority, subject, description, assignee, responsible, start/due dates, estimated hours, and spent time. Each belongs to a single project. We map work packages 1:1 and preserve custom field values where the target schema includes matching fields.

Types (Task, Feature, Bug, Milestone, Phase, Epic, etc.) are defined globally and assigned per work package. OpenProject allows creating custom types. We migrate the full type list and map each work package's type assignment to the destination equivalent.

Statuses (New, In Progress, Closed, etc.) are defined globally. OpenProject allows custom statuses and full workflow configuration per type. We preserve the status name and, where the destination supports custom statuses, the workflow mapping.

Custom fields are an Enterprise add-on (Basic tier and above). They support text, integer, float, Boolean, list, date, user, and hierarchy formats. Community editions have no custom fields, so any migration into a Community target will drop custom field data. We flag all custom field values during scoping and map them to the destination custom field schema where supported.

Time tracking is available in Community. Each entry is linked to a work package and stores hours, rate, and cost. We preserve the full time entry history per work package including spent-hours totals that feed into cost reporting.

Files are attached to work packages, wiki pages, or projects. OpenProject stores file metadata (filename, mime type, author, created-at) alongside the file content. The API limits file link creation to 20 per request. We batch large attachment sets and preserve file associations to their parent work package.

Users have a fixed schema (name, email, login, admin flag, avatar). Memberships assign a user to a project with a specific role. Roles and permissions are global. We map user accounts and preserve the project-role assignments; role names may differ in the destination and require mapping.

Wiki pages belong to a project and support Markdown content with attachments. We migrate page content and link attachments to the correct wiki page. Wiki formatting is preserved as raw Markdown.

Documents are a project-scoped module storing files and descriptions. They are separate from work package attachments. We map document entries and their linked files, noting that some destination PM platforms do not have a native Documents object and will consolidate documents into a project-level attachment set.

Meetings belong to a project and hold title, date, duration, location, attendees, and minutes text. We preserve the full meeting record including attendee list and minutes content as Markdown.

Cost tracking is available via the Costs module. Labour costs, unit costs, and budget values are stored per work package. This module is not available on all hosting modes; we flag missing cost data during scoping and do not replicate it to targets without a cost module.

Versions (or milestones) group work packages and carry a name, description, status, and date. We preserve version assignments so sprints and release milestones retain their work package memberships in the target system.