Migrate from Conceptboard to Jira

Conceptboard Projects (containers for Boards) map 1:1 to Jira Projects. We create the Jira project during schema setup, selecting the appropriate project template (Scrum, Kanban, or Bug Tracking) based on the customer's delivery model. The Project name, description, and creation date migrate. Archived Conceptboard projects are noted separately and optionally imported as inactive Jira projects if the customer wants to preserve the historical workspace structure.

Individual Conceptboard Boards map to Jira Epics within the destination project, or to standalone Jira Projects if the board represents an independent delivery track. Board metadata (name, description, creation date, tags) migrates as Epic or Project fields. The spatial layout of sticky notes, shapes, and connectors is not representable as structured Jira issue data; we document the visual organisation as a written board map for the customer's admin to implement as Epic-Story-Task hierarchies in Jira.

Conceptboard Sections subdivide a board spatially and, as of January 2026, can contain items as child objects. Sections map to Jira Sprints if the customer uses Scrum mode and wants time-boxed delivery, or to Jira Labels (applied to issues) if the customer prefers Kanban with label-based grouping. We determine the mapping strategy during scoping and configure the Sprint or Label structure in Jira before migration. Section ordering is preserved as Sprint sequence or label application order.

Conceptboard Tasks (cards on a board with assignee, due date, status, and description) map directly to Jira Issues. Task name becomes the Issue Summary; task description text extracts from the board PDF and populates the Issue Description field; task assignee maps to Jira Assignee (resolved by email match to Jira User); task due date maps to Due Date; task status maps to the appropriate Jira status value within the configured workflow. Custom fields on Conceptboard tasks migrate to Jira custom fields of matching type if the Jira project schema includes them.

Files uploaded to a Conceptboard Board via the Attachments dialog are downloaded individually and re-attached to the equivalent Jira Issue during migration. Filenames and original upload dates are preserved. We use Jira's REST API to POST each file to the corresponding issue's attachments endpoint. Attachments with null filenames in Conceptboard are flagged during discovery and resolved before migration begins, per Jira's Cloud Migration Assistant guidance on null-filename handling.

Conceptboard comments on board elements are captured from the board-level PDF export and, where a comment is attributable to a specific task or section, migrate as Jira Issue Comments. Comment text is preserved; commenter identity maps to the Jira User by email match. Spatial comments (pinned to canvas coordinates rather than objects) are collected as a board-level comment thread on the corresponding Epic or Project in Jira, with their original position noted in the comment body.

Conceptboard licensed users (per-seat accounts) map to Jira Users by email address match. The Jira user must exist and be active before record import begins; we run owner reconciliation during the approach phase and flag any Conceptboard user without a Jira match for the customer's Jira admin to provision. Guest accounts (free, unregistered collaborators) are noted as non-billable contributors and do not receive Jira seats unless the customer requests it.

Conceptboard personal and team-shared templates migrate as Jira Project Templates if the customer wants to reuse board structures in future Jira projects, or as archived reference boards noted in the migration inventory document. Team templates on Conceptboard Advanced+ migrate as documented template patterns for the customer's admin to implement as Jira project templates or Automation rules post-migration.

Conceptboard Board Tags (introduced December 2025) used to categorise boards migrate as Jira Labels on the corresponding Jira Project or Epic. Labels are available on all Jira Software Cloud tiers and provide a lightweight classification mechanism that requires no schema configuration. Tag application is preserved at the board level; if tags were applied at the item level within a board, they are applied to the corresponding Jira Issue.

Board history (Advanced+), approval workflows (Corporate and Government tier), and audit logs (Corporate and Government tier) are tier-gated governance artifacts. Board history is an audit trail with no Jira equivalent; approval workflow state is a process variable that does not map to any Jira object; audit logs are administrative records outside user content. We document whether these features were in active use during scoping and flag their absence in the destination so the customer's admin can plan manual rebuilds or compensating controls in Jira.