Migrate from Visma Severa to Jira

Visma Severa Cases are the primary business-unit container, equivalent to Jira Projects. We map Case number, Case name, Case status, responsible person, Business Unit assignment, and start/end dates directly to Jira Project fields. The Jira Project key is derived from the Case number prefix. If the customer used multiple Business Units in Severa, each becomes a separate Jira Project, which aligns with Jira's native multi-project structure and enables per-project permission schemes.

Visma Severa has a native Customer object with full contact details, address, and Case assignments. Jira has no native Customer or Account object — it is project-centric, not CRM-centric. We map Customer name to a Jira custom field (Customer__c) on the Project or to the Label field using a naming convention like Customer:[Name]. Customer contact details (email, phone, address) are stored as custom text fields on the Project or linked via a Jira Service Management-style customer record if the destination org includes Jira Service Management. Orphaned Customer address data not linked to a Case requires a separate Severa support request and is flagged during discovery.

Visma Severa supports an unlimited phase nesting hierarchy (Case → Phase → Sub-phase → Sub-phase). Jira enforces a two-level hierarchy: Issue at the parent level and Sub-task as a child, with Sub-task nesting disabled by default. We flatten Severa phase depth into Jira's Issue-Sub-task model using a depth-first traversal: the top-level Phase becomes a Jira Issue (Story or Task), and Sub-phases become Sub-tasks. Deeply nested sub-phases at the third level or beyond require a flattening decision — typically merged into the parent Sub-task description as a structured list or migrated as Comments. We document this decision during scoping and present it to the customer's project manager before migration begins.

Visma Severa Hour Entries include hours, allocated Case and Phase, approval status, billable flag, hourly rate, and date. We map these directly to Jira Issue worklog entries using the Jira REST API Worklogs resource. Each Hour Entry becomes a Jira worklog record on the corresponding Issue (resolved via the Phase-to-Issue mapping). The billable flag, hourly rate, and approver context are stored as custom fields on the worklog or as Issue custom fields. Approval status from Severa does not have a native Jira equivalent and is recorded in a custom field for the customer's admin to action post-migration.

Visma Severa Expense records include amount, currency, expense type, linked Case, and approval status. Jira has no native expense object. We map expense data to Jira Issue custom fields (Expense_Amount__c, Expense_Type__c, Expense_Currency__c) attached to the corresponding Issue. If the customer uses a Jira Marketplace expense app (Expense Tracker, Invoice for Jira), we create the equivalent custom objects and map the expense records accordingly during migration. Expense attachments and receipt files are migrated as Jira Issue attachments.

Visma Severa Resource Allocations define person-to-Case assignments with start/end dates and allocated hours. Jira's assignee field maps the person, and Fix Version or Sprint maps the time window. We resolve the assignee by matching the Severa user's email to the Jira User account. Allocated hours and duration map to the Jira Issue's original estimate or remaining estimate fields. If the customer used Severa's Capacity Planning view, the Jira Tempo Timesheets app can replicate the resource utilization view post-migration.

Visma Severa Business Units organize reporting across Cases and Users. In Jira, Business Units map most naturally to separate Jira Projects, which each have their own issue types, workflows, and permissions. For customers with fewer Business Units or those who prefer a unified project structure, Business Unit assignments can also be stored as a Jira Label (e.g., BU:[UnitName]) on Issues. We determine the preferred mapping during scoping based on the number of Business Units and the customer's Jira governance model.

Visma Severa Users and Employees are synced bidirectionally with Visma Business when integrated, but for migration we treat them as a user list with role and Business Unit assignment. We extract all active and inactive Users, match them to Jira Users by email address, and assign Jira project roles based on the Severa role. Inactive Severa users can be set to Jira inactive status. Jira requires each migrating user to have a valid Atlassian account; we flag any Severa users without email addresses for the customer's admin to resolve before migration.

Visma Severa Invoices are generated from tracked hours and expenses and sent via Visma.net Financials or Maventa. Jira has no native invoicing capability. We transfer invoice headers, line items, amounts, currency, and payment status to a Jira custom object (Invoice__c) with a lookup to the Jira Project or Issue representing the Case. Invoice PDF attachments migrate as Jira attachments. If the customer intends to use the Invoice for Jira app (Atlassian Marketplace), we align the custom object schema to that app's data model during migration. The Maventa e-invoicing integration does not replicate in Jira and must be replaced by a Nordic e-invoicing solution compatible with Jira.

Visma Severa custom fields on Cases, Customers, and Hour Entries transfer as Jira custom fields. We create the Jira custom fields during schema design, matching field types where possible (text fields, date fields, number fields). Multi-select or checkbox custom fields map to Jira multi-select or checkbox custom fields. Any Visma custom field that has no direct Jira equivalent is preserved as a structured JSON value in a Jira text field, with a note in the migration manifest for the customer's admin to surface if needed. Jira requires project-level association of custom fields, which we configure per Project during schema deployment.