Migrate from .STUDIO to Jira

.STUDIO projects map directly to Jira projects as the top-level container. The project name, description, status, start date, and end date transfer as standard Jira project metadata. Each Jira project requires a project template (Scrum Software, Kanban Software, or Business) selected during schema setup; we map the customer's .STUDIO project type to the nearest Jira template during scoping. Projects with multiple task lists may be split into multiple Jira projects if the customer uses separate projects for distinct workflows rather than a single project with issue types.

.STUDIO tasks map to Jira issues of the appropriate type. We use a configurable mapping: tasks with a story-like description (client deliverables, milestones) map to Jira Story; tasks with a clear action item map to Jira Task; tasks flagged as bugs map to Jira Bug. Assignee, due date, estimated hours, status, and description migrate directly. Jira's Summary field takes the task name; Description takes the task body with basic formatting preserved. Parent-child task hierarchy in .STUDIO maps to Jira's subtask or linked issue model depending on the depth.

.STUDIO clients are separate records linked to projects. Jira has no native client object, so we create a custom field (Client__c or labeled as Client) on the Jira project and populate it with the client company name or contact name from .STUDIO. For cross-project client reference, we create a dedicated Jira project named after the client and link all client-related issues to it via issue links. The customer chooses the strategy during scoping. Client contact details (email, phone, address) are stored as custom fields on the client-linked issue or in a Confluence space configured as the client extranet.

Time entries in .STUDIO map to Jira Worklog records on the migrated issues. Each worklog carries the original duration (converted from .STUDIO's 0.1-hour increments to seconds for Jira's raw-second format), the date, the user who logged the time, and the notes field. We flag the rounding behavior during scoping: .STUDIO rounds to the nearest 6-minute increment by default, while Jira stores raw seconds. The customer chooses whether to preserve the rounded values or re-import raw durations if the source platform supports it. Billable flag and hourly rate from .STUDIO do not map to Jira native fields; we store them as custom fields on the worklog or the issue for downstream billing integration.

User records from .STUDIO (name, email, role, hourly rate) map to Jira users. We match by email against the Jira destination site's user directory. Users without a matching Jira account go to a reconciliation queue for the customer's admin to provision before record import. Hourly rate migrates as a custom field on the Jira user profile (if the Jira Workforce Management app is in use) or remains as a custom field on the project for reference. Jira requires an active user license for each assignee; we flag any inactive .STUDIO users so the admin can choose whether to provision a Jira account.

.STUDIO per-workspace custom field definitions vary across the platform, including text, number, date, dropdown, and multi-select types. We read the active custom field schema at .STUDIO export time and generate a field map before migration begins. Jira custom fields are configured per project with an issue-type context, so we pre-create the Jira custom field with the matching type (Text Field, Number Field, Date Picker, Select List, Labels for multi-select). Formula fields or cross-field dependencies from .STUDIO do not map directly; we store the computed value as a static custom field and note that Jira Automation or a post-migration script can reproduce the formula logic.

Tags in .STUDIO are flat string labels applied to tasks and projects. Jira's Labels field accepts multiple labels as a text array, so we split comma-separated .STUDIO tags and upsert them as Jira labels. Labels that represent a category rather than a free-text tag can be mapped to a Jira Select List (single-choice) or Labels field (multi-choice) depending on the use case, decided during scoping. Jira labels are project-scoped by default; global labels require the Labels SM app or equivalent.

File attachments from .STUDIO are exported with their parent record context (filename, URL, size, MIME type). We re-attach files to the migrated Jira issue using the Jira REST API's attachment endpoint. Files over 10MB or unsupported MIME types (executable files, certain binary formats) are flagged during the manifest review and excluded from the automated migration; the customer receives a manifest of excluded files for manual handling. Jira Cloud has a 10MB attachment limit per file; Jira Data Center allows configurable limits up to 50MB.

Task comments in .STUDIO migrate to Jira issue comments with author, timestamp, and text body preserved. Jira's comment format accepts plain text and basic wiki-style formatting. If .STUDIO comments contain @-mentions or formatted blocks, we convert them to plain text with the mention preserved as a text reference. Comment threading in .STUDIO (if present) is flattened into sequential comments on the Jira issue. Rich media attachments within comments are exported separately and re-attached to the issue.

Project and task templates from .STUDIO store the template structure (task names, descriptions, estimated hours, assignee roles) as reusable blueprints. We export the template schema as a structured JSON manifest rather than populating Jira project templates, because Jira's built-in project templates (Scrum, Kanban, Bug Tracking) differ architecturally. The manifest lists each template with its tasks, custom fields, and default values so the customer's admin can use Jira's project template feature or a third-party template app (Structure for Jira, Project Template for Jira) to recreate the blueprint.