Migrate your Redmine 3.3 data

Projects are the top-level container in Redmine 3.3, supporting subprojects with independent module enablement per project. We export the full project tree, including public/private flags and per-project enabled modules (wiki, repository, issue tracking), then reconstruct the hierarchy at the destination preserving membership inheritance where the target supports it.

Issues are the core work item in Redmine, with fields for subject, description, status, priority, tracker, assignee, due date, start date, done ratio, and estimated hours. We map the full issue schema and preserve parent-child subtask relationships by resolving parent_issue_id references during the import phase.

Trackers define issue types (e.g. Bug, Feature, Support) and have per-role permission restrictions introduced in Redmine 3.3. We export tracker definitions and workflow state mappings so the same issue-type categorization is available at the destination.

Custom fields in Redmine 3.3 apply to specific customized_types (issue, time_entry, project, user, version). List-format custom fields store internal IDs not display values. We query the custom_field definitions via the admin REST endpoint and resolve ID-to-label mappings before writing to the destination to avoid importing raw numeric references.

Time entries record hours spent against a project or specific issue, with fields for activity, hours, comments, and custom fields. We export time entries with their issue association intact and reconstruct the link on the destination so time reports and billing records are preserved.

Versions (or Targets) represent milestones or releases within a project, with fields for name, effective date, description, and status. We migrate versions as standalone objects and re-associate them with issues referencing the version by name at the destination.

Redmine wikis are project-scoped and store content in a wiki_format attribute with page hierarchy. We export wiki content as raw text or HTML depending on the destination format, but page-level permissions and attachment cross-links require manual review post-migration.

Files uploaded to issues, wiki pages, or documents are stored on the Redmine server filesystem or object storage. We extract attachment metadata and file content via the REST API and re-upload to the destination, but the file must be accessible from the source Redmine instance during the migration window.

Redmine user accounts include login, firstname, lastname, email, admin flag, and custom fields. We export users and their project memberships with role assignments. Where the destination uses a different identity model (e.g. SSO or external directory), we map to existing destination users by email during the import phase.

Redmine supports typed issue relations (blocks, blocked by, relates to, duplicates, etc.) defined by internal IDs. We export the full relation graph and resolve target IDs after issue migration so relation semantics are preserved rather than silently dropping cross-issue dependencies.

Project-level documents store a title, description, and category. We export documents as standalone objects, but document categories vary by installation and may require custom field mapping for specific deployments.

Project news posts include a title, summary, content, and author. News is lower-priority for most migrations but we include it in the scope if explicitly requested; otherwise it is omitted to reduce migration scope and risk.