Migrate from SmartTask to Jira

SmartTask Projects map directly to Jira Projects. Each SmartTask workspace can contain multiple projects with distinct views (Kanban, List, Timeline). We map each SmartTask Project to a Jira Project and configure the Jira Project's Issue Type Scheme to match the task type distribution in SmartTask. If the SmartTask workspace contains more than 10 projects, we recommend splitting across multiple Jira Projects to preserve the service-team segmentation that SmartTask uses.

SmartTask Tasks map to Jira Issues. During scoping, we identify the distribution of task types (feature requests, bug reports, support items) and configure Jira Issue Type Scheme to support Story, Task, and Bug. SmartTask task priority (Low, Medium, High, Urgent) maps to Jira Priority (Low, Medium, High, Highest) with the value preserved in a custom field st_original_priority__c for audit. The SmartTask task description migrates as the Jira Description field in plain text.

SmartTask Milestones are deadline markers that group tasks under a shared due date. In Jira, we configure these as Fix Versions (releases) if the milestone represents a delivery target, or as Epics if it represents a large work grouping with child stories. The customer chooses during scoping. We preserve the milestone name and due date on the Jira Fix Version or Epic.

SmartTask Task Templates define reusable structures with pre-filled fields and checklists. Jira has no direct template object, but we configure Issue Type Schemes that pre-populate default labels, components, or custom field defaults per issue type. The template checklist items migrate as a separate Checklist custom field (via third-party app) or as child subtasks. Template automation triggers (if any) do not migrate and are listed in the rebuild handoff document.

SmartTask Assignees map to Jira Users. We resolve by email match against the destination Jira site's user directory. Any SmartTask assignee whose email does not have a matching Jira user goes to a reconciliation queue for the customer's admin to provision before record import resumes. Jira accounts must be active (or have a specific license) to appear in the assignee picker at import time.

SmartTask Followers (team members who receive notifications without assignment) map to Jira Watchers. We export the follower email list per task and add each email as a Jira watcher on the corresponding issue. If the watcher email does not have a Jira account, we flag the entry and skip the add rather than creating an orphaned watcher reference.

SmartTask custom fields (string, number, date, yes/no) map to Jira custom fields of equivalent type. The critical step is schema discovery: SmartTask allows custom field definitions to vary per project, so a single workspace may have field_A defined in Project 1 but not in Project 2. We catalog every distinct custom field name and type across all projects before creating Jira custom fields, ensuring all migrated tasks have a matching destination field. Jira custom fields are global by default; we restrict scope to the relevant projects during configuration.

SmartTask task comments migrate to Jira Comments on the corresponding issue. Author, timestamp, and comment body transfer directly. Jira renders comment body as Atlassian Document Format (ADF); we convert plain-text SmartTask comments to ADF format. Mentions and @-references in SmartTask comments are preserved as text and flagged for the customer's admin to re-link post-migration.

SmartTask attachments (direct upload, Google Drive, Dropbox links) export as file references and URLs. Jira attachments migrate by re-uploading the file content via the Jira REST API if the file is accessible, or by preserving the URL as a Jira comment with a link reference if re-authentication is required for external storage. Jira does not support null filenames; we verify every attachment has a valid filename before import and flag any null-filename entries from the SmartTask export for customer review.

SmartTask Tags map to Jira Labels. We export the full tag vocabulary from SmartTask, create matching labels in Jira (creating them if they do not exist), and assign label values to the corresponding issues. Jira labels are not hierarchical; if SmartTask tags have a hierarchical structure (e.g., client-name > deliverable-type), we flatten them to hyphenated label strings.

SmartTask time tracking entries (duration or start/end) map to Jira Worklog records on the corresponding issue. Jira requires the user performing the worklog import to have the Work On Issues permission. We map SmartTask time entry author (by email) to Jira User and preserve the original duration or computed duration in seconds on the worklog. Note that not all SmartTask tiers expose time tracking; we verify time entry availability during discovery.

SmartTask Recurring Tasks (daily, weekly, monthly, yearly, custom) preserve their recurrence rule and next-occurrence date in a custom field st_recurrence_rule__c. Jira has no native recurring issue concept. We migrate the recurrence metadata as a text field and deliver a written inventory of every recurring task with its schedule for the customer's admin to recreate in Jira Automation (or a third-party recurring issue app) post-migration.