Migrate from Intervals to Jira

Intervals Clients are top-level organizational units with name, status, and contact references. Jira has no Client object — we map each Client to a Jira Project and add a Client Name custom field (text or select) to the Project's default Issue type scheme so that every Issue carries the client context. If the customer uses multiple Projects per Client, we document the split and set the Project key prefix convention during scoping.

Intervals People are user accounts with timesheet permissions and roles (active or inactive). We map each Person to a Jira User by email address lookup. Inactive Intervals people map to Jira users with the Deactivated status, preserving historical attribution on Time Entries without granting active access. Any Person with no matching Jira User goes to a reconciliation queue for the customer's admin to provision before the migration resumes.

Intervals Projects carry budget, start/end dates, status, and owner. We map each Project to a Jira Project, preserving the project name and using the Intervals Project ID as a reference field. Start and end dates migrate to the Jira Project's start date and a custom end date field (Jira does not enforce a project end date natively). The Project-to-Client ownership link is preserved through the Client Name custom field added at the Project level.

Intervals Milestones are date-driven checkpoints within a Project. Jira has no Milestone object — we map each Milestone to a Sprint within the target Jira Project, setting the Sprint start and end dates to the Milestone's target dates. If the customer's workflow uses milestones as reference dates rather than time-boxed iterations, we alternatively map them to Fix Version with a custom Milestone Name field, and the customer chooses during scoping which Jira construct best matches their usage pattern.

Intervals Tasks belong to Projects and optionally to Milestones, carrying status, estimated vs actual hours, assignees, and comments. We map each Task to a Jira Issue. We choose Issue type (Task vs Story) based on the presence of a milestone link: Tasks without a milestone link map to Jira Task; Tasks with a milestone link map to Jira Story so that the Sprint membership reflects the original milestone context. Status, assignees, estimated hours, and actual hours migrate to the corresponding Jira Issue fields or custom fields.

Intervals Task-level comments are threaded text entries attached to Tasks. We map them to Jira Issue Comments, preserving the author (via User email resolution), the original timestamp, and the comment body. Comment threading in Intervals is flat; Jira's comment model is also flat, so no structural transformation is required.

Intervals Milestone comments are standalone threaded entries tied to a Milestone but not to a specific Task. Jira Sprints do not have a native comment object. We map these to Project-level Notes using a custom field or a dedicated Jira Project wiki page created during migration, and we flag this constraint to the customer so they can decide whether to move milestone comments into a related Issue or leave them as project documentation.

Intervals Project Notes are standalone text entries scoped to a Project but not tied to Tasks or Milestones. We map these to the Jira Project's Description field (if brief) or to a Confluence project page linked from the Jira Project, depending on length and formatting complexity. If the customer uses Confluence, we recommend a linked page; if not, we use a Jira project description custom field.

Intervals custom activity fields are user-defined properties attached to time entries, visible only via the API (not CSV export). We enumerate all active custom activity fields during the discovery phase by querying the Intervals API, then map each to a Jira custom field on the target Issue type. Field type mapping follows: text inputs to Jira Text Field, numeric values to Jira Number Field, date values to Jira Date Field, and picklist values to Jira Select Field. Jira does not support custom fields on Worklog records — if a custom activity field is time-entry-specific with no natural Issue-level equivalent, we store it on the parent Issue and flag this constraint during scoping.

Intervals Time Entries are the primary data object — each records hours, a date, task association, billable status, and optional custom activity fields. We map each Time Entry to a Jira Worklog record linked to the corresponding Issue (via the Task-to-Issue mapping). The Intervals entry date and duration map to Jira worklog started and timeSpent. We set the worklog author to the resolved Jira User. If the Intervals entry has no associated Task (unbilled or overhead time), we flag it during scoping — Jira requires a parent Issue for every worklog, so these entries require either a catch-all Issue or a custom handling approach agreed upon with the customer.

Intervals Documents are attachments stored per Task or Project. Intervals explicitly does not support bulk document export — only individual downloads are possible, and there is no API-based bulk retrieval method documented. We scan the Intervals API during discovery to collect every document URL, document name, associated Task, and file type. We then produce a manual-download checklist organized by Project and Task for the customer's team to execute before cutover. On the Jira side, we upload downloaded files as Jira Issue Attachments via the Jira REST API using the collected document URLs. This is a manual-step gap — we do not attempt to script document extraction from Intervals because the platform provides no bulk export mechanism.