Migrate your OpenProject data

Projects are the top-level workspace containers in OpenProject. They control permissions via Member-Role assignments and host activated Modules. We map them 1:1 across migrations, preserving project hierarchy (parent-child relationships) and project-level custom fields. As of v17, Projects share the workspace concept with Programs and Portfolios.

Work Packages are the core task/issue object in OpenProject. They carry Type, Status, Priority, Assignee, Responsible, Dates, Estimated/Hours, custom field values, and parent-child relationships. We preserve all standard fields and map custom fields as name-value pairs. Attachment references are carried over; actual file migration depends on file storage handling.

OpenProject supports unlimited custom fields of various types (text, number, list, user, date, boolean, etc.) per project or globally. Since custom field definitions are instance-specific, we handle them as dynamic schema during migration—discovering available fields per project and mapping values to the destination's equivalent definitions.

Boards (Kanban-style views) in OpenProject are derived from work package queries and store column configuration as view metadata. We preserve board structure and column-to-status mappings during migration. Advanced Action Boards with auto-assignment rules are migrated as configuration blocks.

Time Entries are logged against Work Packages with hours, cost type, and rate. Time entry display is restricted to hours (days-only is not natively supported). We map hours correctly but flag any day-based calculations as requiring post-migration adjustment. Enterprise time-entry field restrictions apply based on plan tier.

Cost Entries track unit costs and rates against work packages. Cost types are configurable per instance. We preserve cost entry amounts and associated cost types but require explicit cost type mapping when source and destination use different currency or cost type configurations.

Versions (milestones or sprints in OpenProject) group Work Packages and carry target dates. We map Versions 1:1 and preserve their date ranges and associated work package counts. Version sharing across projects is supported and preserved.

Wiki pages within Projects store formatted content and can embed work package lists. We migrate wiki content as structured text blocks and preserve embedded work package references as cross-document links. File attachments within wikis follow the standard attachment migration path.

Documents are project-level file containers with title, description, and attached files. We migrate document metadata and their attached files. Large binary files may require out-of-band transfer with reference remapping.

Forums and their Messages (forum posts) are migrated preserving thread structure, author, and post timestamps. Forum permissions inherit from project membership and are mapped accordingly.

Attachments on Work Packages, Wiki pages, and Documents are stored either in the database (for small files) or on disk (for larger files). We migrate attachment metadata and handle disk-path remapping when moving between self-hosted instances. File size limits may apply based on destination configuration.

Users in OpenProject carry email, name, login, admin status, and global roles. We map user accounts 1:1 and reassign work package ownership, time entries, and comments to the corresponding migrated user. Enterprise plans include LDAP group sync and 2FA as add-ons.

Members are user-project assignments carrying a Role. Roles define permission sets. We preserve the Member-Role mapping per project, ensuring that permission structures survive migration intact.

Types (Task, Bug, Feature, Phase, Milestone, etc.) are customizable per project. We map Type names and preserve Type-specific field configurations (which fields are visible/required per Type). When the destination has different Type names, we create a Type mapping table during scoping.

Statuses (New, In Progress, Closed, etc.) and their workflow transitions are configurable per Type. We map Status values and preserve workflow rules. Custom statuses require explicit mapping to destination Status IDs.