Migrate from Wrike to Jira

Wrike Spaces are top-level organizational containers that group Folders and define access boundaries. Jira does not have an equivalent Space object. We map Space assignments to Jira Projects grouped by a naming convention (e.g., [Space Name] prefix on Project key), and we document every Space-to-permission-group mapping for the customer's admin to rebuild in Jira's permission schemes and project roles. This is a manual rebuild step—not automated during migration.

Wrike Folders sit above Projects in the hierarchy and can contain sub-Folders or Projects. Jira has no Folder equivalent. We evaluate the Folder depth: single-level Folders map to Jira Projects; nested Folders are flattened and mapped to Jira Project keys with a descriptive naming convention that preserves the original hierarchy path in the Project description field.

Wrike Projects map 1:1 to Jira Projects using the project title, description, start and due dates, status, and custom field values. We preserve the Wrike project key in the Jira Project description for traceability. The Jira Project must be created and configured (Issue Types, Workflow, field layout) before any Issues are imported.

Wrike Tasks are the primary work unit and map to Jira Issues with the Issue Type selected during scoping based on task content analysis (bug reports become Bugs; deliverables become Stories; administrative work becomes Tasks). Assignee, reporter, priority, due date, and custom field values migrate directly. The Jira Issue Type schema must be configured per project before import.

Wrike Subtasks inherit the parent Task's context and can carry independent assignees and dates. Jira Sub-Tasks are typed as Sub-Task Issue Type and linked to a parent Issue. We preserve the parent-child hierarchy explicitly so nesting depth is maintained. The Sub-Task Issue Type must be enabled in the destination project's Issue Type scheme.

Wrike supports 14+ custom field types (DropDown, Numeric, Date, Currency, Percentage, Contacts, Checkbox, Calculated). We map these to equivalent Jira custom fields by type: DropDown to Select List, Numeric to Number, Date to Date Picker, Currency to Number or Currency (Jira does not have a native Currency field on Standard). Calculated fields from Wrike are exported as static values at migration time and flagged for the admin to recreate as Jiracalculated field apps or manual static values post-migration.

Wrike Workflows define status sets and transition rules per project or globally. Jira Workflows are project-scoped and use Status Categories (To Do, In Progress, Done) that constrain which statuses can be in each column on an Agile board. We export the Wrike Workflow definitions and map statuses to Jira Status Categories, then deliver a written mapping matrix and a Jira Workflow configuration guide for the admin to implement. This is a configuration step, not an automated migration.

Wrike User accounts (name, email, role) are exported via the API and matched by email to Jira Users in the destination site. Deactivated Wrike users are held in a reconciliation queue. Active users without a matching Jira account go to a provisioning queue for the customer's Jira admin before record import resumes.

Wrike time logs with hours, dates, and billing categories map to Jira Worklog entries. Jira's native worklog is available on Standard and above without an app. If the customer uses Jira Free (no native worklog), we document the Tempo plan required and migrate time entries as a separate deliverable to be loaded after the Tempo installation. Duration-based Wrike entries are converted to start-and-end timestamps.

Wrike attachments are referenced by URL. We preserve the original download URLs and re-link them to the corresponding Jira Issues as Jira-native attachments where the URLs remain accessible post-cutover. For attachments stored in Wrike's DAM, we flag any that will become inaccessible after the Wrike account is deprovisioned and recommend a pre-migration bulk download.