Migrate from Baton to Jira

Baton Projects map to Jira Projects as the top-level container. Each Baton Project becomes a Jira project with the same name, description, and start/due dates translated to Jira Project lead and Start Date / Due Date fields if those Jira features are enabled. Jira project keys (e.g., PROJ) are auto-generated or customer-specified during scoping. We map Baton's project-level custom fields to Jira project properties or custom fields.

Baton Tasks map to Jira Issues. The task name becomes Issue Summary, task description becomes Issue Description (with Markdown preserved if the destination supports it). Task status (To Do, In Progress, Done) maps to Jira status categories and specific status values that we configure in the target project during schema setup. Task assignees map to Jira Assignee via email lookup against the Jira user directory.

Baton Subtasks map to Jira Subtasks (Issue type = Subtask). Baton's arbitrary-depth subtask nesting flattens into Jira's two-level hierarchy (Issue > Subtask) by default. If your Baton instance uses subtask chains deeper than two levels, we map the deepest subtask to a Jira Subtask and surface the intermediate levels as linked issues with a 'parent-of-subtask' issue link type that your admin documents for future consolidation.

Baton Milestones map to Jira Versions (Releases) within each project. Milestone name, description, and start/due dates map directly to Version name, description, start date, and release date. Version status (upcoming, released, archived) is set based on Baton's milestone completion state. Jira Versions appear in Fix Version/s fields on issues, which provides a similar filtering and reporting surface to Baton's milestone-based date filtering.

Baton's Date Formula custom field type computes days between two date pickers and auto-updates when either date changes. Jira does not have a native calculated custom field type without a plugin. We export the current computed value as a static Jira Number custom field at migration time. The customer chooses during scoping whether to re-implement the calculation logic in Jira Automation for Jira (free) or a third-party app like ScriptRunner.

Baton custom fields of type free text, dropdown, and date map to Jira custom fields of the equivalent type. Dropdown options map to Jira select/multi-select options. Date fields map to Jira Date or DateTime fields. We pre-create all custom fields in the target Jira project before migration so that the field IDs are resolved at import time rather than requiring post-migration remapping.

Baton's native predecessor/successor dependency tracking maps to Jira Issue Links. We translate Baton dependency direction to Jira link types: a Baton 'blocked by' dependency becomes a Jira 'is blocked by' link; a 'precedes' dependency becomes a 'blocks' link; a 'related to' dependency becomes a 'relates to' link. Link direction is validated during scoping because Jira link types are directional. Your admin configures the active link types in the target project before migration.

Baton documents attached to Tasks and Projects migrate as Jira Attachments linked to the corresponding Issue. We migrate attachment metadata (filename, upload date, uploader, file size) and the actual file blob via Jira's REST API attachment endpoint. Storage location and quota (Jira cloud has per-site attachment storage limits) require attention during scoping for migrations with large attachment volumes. We flag any attachments that exceed Jira's 10MB per-file limit for customer action.

Baton's client-facing portal is a view-layer permission setting, not a data object. We migrate the underlying project and task data; the portal's shareable links and permission settings do not have a direct Jira equivalent. We deliver a written inventory of each client user's current access scope (which projects, which milestone views) for your Jira admin to re-implement using Jira project roles, permission schemes, and issue security levels. External collaborators without Jira accounts require user provisioning before migration.

Baton assignees on Tasks and Subtasks map to Jira Users by email match against the target Jira project's user directory. External collaborators and client-portal users in Baton may not have Jira accounts; we hold unmapped assignees in a reconciliation queue and flag them for user provisioning before migration. Jira guest access (available on Premium and above) accommodates external stakeholders without a full Jira seat license.