Migrate from 24SevenOffice to Jira

24SevenOffice Projects map directly to Jira Projects. We migrate project name, description, status, start/end dates, owner (mapped to Jira User by email), budget fields (where present), and milestone dates. PMI-standard audit workflow data in 24SevenOffice becomes project description or Jira custom fields; Jira does not support audit workflows natively. Projects are created first in Jira before any child Issues are imported so that the Jira project key is available for issue key generation.

24SevenOffice Tasks and Subtasks map to Jira Issues with the appropriate Issue Type. Parent-child task hierarchy from 24SevenOffice becomes Jira sub-task links (issuelinks type: Parent) or Epic-Story-Task structure depending on the customer's scoping choice. Assignee, due date, status, estimated hours, and custom task fields transfer directly. 24SevenOffice's task priority values map to Jira Priority values (Highest, High, Medium, Low, Lowest) via a configurable translation table.

24SevenOffice Time Entries linked to Projects map to Jira Issue Worklogs. We extract the entry date, time spent (duration), description, billable/non-billable flag, and user attribution. The billable flag becomes a Jira custom field (billable__c) since Jira's native worklog does not carry a billable flag. Worklogs are attributed to the Jira User resolved by email from the 24SevenOffice User reference. Time entries without a linked Jira User are held in a reconciliation queue.

24SevenOffice Users map to Jira Users by email address. We extract display name, email, and role from 24SevenOffice and provision Jira Users in the destination site before any project or issue migration begins. Users on the 24SevenOffice Standard tier with no access to advanced project fields are mapped to Jira users with the appropriate Jira role (Admin, Member, Viewer). Inactive or archived 24SevenOffice users become Jira users with the account status matching their source state.

24SevenOffice Companies have no direct Jira equivalent because Jira does not have a CRM-style Organization object. We migrate company names as Jira Labels on related Issues (prefixed with company:), or as plain text in a custom field company_name__c. The customer's admin chooses the strategy during scoping. If the team uses Jira with a linked Confluence space for account documentation, we can map company records to Confluence pages instead.

24SevenOffice CRM Contacts (individuals with name, email, phone, address, lifecycle stage) are external to Jira's project management model. We migrate contact email and display name to Jira Users if the contact will interact with Jira as a user (External Contributor role). Otherwise, contacts are exported as a CSV with the same fields for ingestion into a separate CRM tool post-migration. Custom contact properties map to Jira custom fields of the matching type (text, dropdown, number, date).

24SevenOffice Deals and Pipelines have no direct Jira equivalent because Jira is not a sales CRM. We extract Deals with deal name, value, stage, owner, associated company, and close date as a structured CSV export. The customer uses this export to re-ingest deal data into their chosen finance or CRM tool. Stage values from 24SevenOffice pipelines are preserved in the CSV so the customer can apply them to any downstream system.

24SevenOffice Invoices carry line items, tax codes, payment status, and invoice numbers that vary by country edition (Norway, Sweden, UK accounting standards). Jira has no invoicing module. We extract invoice data as a country-specific CSV with the correct tax code schema applied per the source edition, so the customer can import into their replacement accounting system. Invoice attachments (PDFs) are downloaded and uploaded to a shared storage location or Confluence space designated by the customer.

Vendor invoices and AP records use country-specific chart-of-accounts structures in 24SevenOffice. We extract vendor name, invoice amount, due date, and account code as a CSV mapped to the source country edition. Jira does not support AP records. The customer uses this CSV for ingestion into their replacement accounting platform (Xero, QuickBooks, Visma, or equivalent).

Open AR records (unpaid customer invoices) migrate as a CSV with customer reference, amount, currency, and aging bucket. Currency conversion is handled as a pre-export step if the source uses a different base currency from the destination reporting currency. Jira has no AR module. We deliver the AR CSV alongside the AP and Invoice exports as a unified accounting records package for downstream ingestion.

24SevenOffice custom fields on Projects and Tasks require type-compatibility mapping before Jira import. A 24SevenOffice property named priority might store values as text (High, Medium, Low) or as integer codes. We inspect the source schema during discovery, determine the actual stored type, and create the matching Jira custom field type (Select, Multi-select, Text, Number, Date Picker, User Picker) before migration. Custom fields that cannot be type-mapped (e.g., a mixed-type field storing both text and dates) are flagged for the customer to resolve.

File attachments on 24SevenOffice Projects and Tasks are referenced by URL in the API. We download attachments to temporary storage, then upload to Jira as issue attachments linked to the corresponding Jira Issue. Jira enforces a 256 MB per-file size limit and supports the same attachment types as 24SevenOffice (PDF, images, documents, spreadsheets). Attachments exceeding the Jira size limit are flagged and delivered as a downloadable archive. Jira does not support attachments on Projects directly; all file attachments attach to Issues.