Migrate from Visma Severa to Asana

Visma Severa Cases are the primary business-unit container and map 1:1 to Asana Projects. We preserve Case number, Case name, status (Active/On Hold/Closed), responsible person (Case owner), Business Unit assignment, and project-level custom fields. Sub-tasks within a Case export as rows with parent-child relationships that we reconstruct as Asana Subtasks using the Case/task parent reference. The Case hierarchy (parent Case with sub-Cases) maps to Asana Portfolios or as Projects with a linked parent Project reference depending on customer preference during scoping.

Visma Severa Customer records (company name, contact details, address, associated Case assignments) transfer to Asana as Team members with a custom profile section holding the original Customer ID, company affiliation, and contact information. We preserve the Customer-Case linking by creating Asana Tasks or a Project section that references the linked Cases. Orphaned address data not linked to a Customer or Case requires a separate Severa support request per Severa's data portability documentation; we flag this during discovery.

Billable and non-billable Hour Entries map to Asana Tasks with custom fields capturing hours worked, date, approval status, hourly rate, and billable flag. We preserve the Case-CaseNumber reference as the parent Asana Project, the billing-flag as a checkbox custom field, and the approver context in a text field. Asana's native time tracking is not required for migration; the Hour Entry data becomes structured task metadata that the customer's team can report on using Asana's custom fields reporting in Business tier.

Expense records with amounts, currency, expense type, and linked Case transfer as Asana Tasks with custom fields for amount, currency, and expense category. Receipt attachments from Visma Severa migrate as files attached to the corresponding Asana Task. Expense categories map to Asana Tags or custom picklist fields. Note that Asana has no native expense approval workflow; we document the original approval chain as a manual rebuild item in the automation inventory.

Visma Severa Resource Allocations define who is assigned to a Case and for what time window. We map these to Asana Tasks with an Assignee field, a Start Date (or custom Start Date field), and a Due Date reflecting the allocation window. Asana's Workload view then surfaces team capacity per member. This is a functional equivalent rather than a feature-parity migration; Asana's Workload does not include the capacity planning, utilization percentages, or forecasting available in Severa's Resource Management module.

Visma Severa Business Units (departments or reporting groups) map to Asana Teams. Each Business Unit in Severa becomes a Team in Asana, and the Case assignments are preserved by associating the migrated Project with the corresponding Team. We map Business Unit reporting hierarchies to Asana Portfolios if the customer has multi-level department structures, though Portfolio nesting in Asana is shallower than Severa's organizational hierarchy.

Visma Severa Users and Employees map to Asana Members. Active/inactive status transfers from Severa to Asana, with inactive users set as Guests or deactivated depending on whether they need access post-migration. We resolve by email match. Any Severa User without a matching Asana workspace member goes to a reconciliation queue for the customer's admin to provision before record import completes.

Custom fields on Cases, Customers, and Hour Entries transfer as key-value pairs mapped to Asana custom field types (text, number, date, checkbox, picklist). We create the destination custom field schema in Asana before migration, matching the source field type to the nearest Asana custom field type. Multi-select or tag-based custom fields in Severa map to Asana Tags or multi-select picklist fields.

Invoices generated in Visma Severa do not migrate to Asana. Asana has no native invoicing or billing module. We transfer invoice metadata (linked Case, line items, total amount, payment status) as Asana Tasks with custom fields, but the customer must rebuild invoice generation using a dedicated tool (QuickBooks, Xero, Zoho Invoice) or manual processes post-migration. We flag this as a business-process gap in the migration inventory.

Project fees and subscription billing configurations in Visma Severa are billing setup records with no Asana equivalent. These do not migrate. The customer documents these separately as part of the billing-tool migration scope.

Signed documents stored in Visma Sign and linked from Visma Severa are not migratable. Visma Sign has its own data portability constraints and the actual signed PDFs reside in Visma Sign's cloud archive, not in Severa's data export. We flag these documents in the migration inventory with instructions to download them from Visma Sign directly before account closure.

Profitability margins, utilization percentages, project health scores, and forecast metrics in Visma Severa are machine-calculated at runtime from underlying transactions. These aggregated metrics have no underlying data rows to export. We preserve the raw source data (Hour Entries, Expenses, Billable Items) so the destination system can recompute equivalent metrics in Asana custom reports, but pre-migration dashboard snapshots do not carry over.