Migrate from Moovila to Jira

Moovila Projects map directly to Jira Software Projects as the top-level container. We migrate project name, description, start date, target end date, status (Active, On Hold, Completed), owner assignment, and budget where present. The Moovila project ID is preserved in a Jira custom field moovila_project_id__c as a reference anchor for reconciliation.

Moovila Tasks and subtasks map to Jira Issues with type mapping: Moovila standard tasks become Jira Stories by default, with the customer choosing whether high-level planning items become Epics or Stories during scoping. Nested subtasks in Moovila map to Jira Sub-Tasks. Task status (Not Started, In Progress, Completed, On Hold) maps to Jira Status with customer-defined workflow steps. Assigned owners resolve by email match to Jira User accounts. Task acceptance/rejection fields migrate as custom select fields.

Moovila base templates and mini-templates contain task structures, milestones, and resource placeholders that do not have a native Jira equivalent. Jira's Template functionality is limited to copying existing projects. We document the full template structure including task hierarchies, milestone anchors, and role-based resource assignments in a written template guide for the customer's admin to reproduce as Jira projects or Jira Automation rules. Template analytics data (Business/Enterprise tier only) does not migrate.

Moovila Resources (individual, role-based, and enterprise-level) map to Jira User accounts by email resolution. Moovila's resource utilization targets, capacity percentages, and cost rates are not native Jira fields; these migrate as Jira custom fields on the Issue (resource_cost_rate__c, resource_role__c, utilization_target__c) and are documented for admin configuration. Resources without a matching Jira user are held in a reconciliation queue for the admin to provision.

Moovila Milestones map to Jira Fix Versions (Releases). We preserve milestone name, target date, description, and the linked task list so that the admin can configure Version milestones in Jira that group the migrated issues by delivery target. Moovila milestone-to-task linkage migrates as Jira Fix Version assignments on the Issue records. Note that Jira Fix Versions lack Moovila's critical path anchoring; milestone-level dependency analysis is not preserved.

Moovila task-to-task dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish) map to Jira Issue Links. Jira's native link types (Blocks, is blocked by, relates to, duplicate of) are available out of the box; Moovila's less common dependency types are mapped to Blocks or is blocked by. We migrate the full predecessor-successor chain and document the original dependency type in a custom Jira field moovila_dependency_type__c for admin reference. Jira Advanced Roadmaps or a third-party app may be needed to visualize multi-project dependency chains at scale.

Moovila Risk Registers contain both manually entered risks and RPAX AI-generated predictions. There is no native Jira equivalent for a risk register. We migrate the manually entered risk records as Jira Issues under a dedicated Risk Issue Type scheme (created during schema setup), with risk severity mapped to Jira Priority, risk status to Status, and mitigation notes to Issue Description. RPAX AI-generated risk predictions do not migrate because they are computed values tied to Moovila's analysis engine; we flag these during discovery and advise the admin to regenerate risk analysis using Jira's native capabilities or a third-party risk management app post-migration.

Moovila custom fields on projects and tasks (text, number, date, dropdown select, multi-select) map to Jira custom fields of equivalent type. We run a type-compatibility check during scoping: Moovila text fields map to Jira Text Field (single-line) or Text Field (multi-line), number fields map to Number fields, date fields map to Date fields, and select fields map to Select List (single) or Labels. Custom field values migrate during the Issue import phase with field IDs resolved in the destination Jira instance.

Moovila time submissions (Business/Enterprise tier) map to Jira Work Logs with hours, date, description, and billable flag preserved. We use the Jira WorklogInputBean via REST API to insert work logs against the correct Issue after the parent Issue record exists. Moovila time approval workflow status does not migrate; Jira has no native approval model for work logs. Pro-tier customers have no time entry data to migrate; we confirm the tier during discovery.

Moovila User accounts map to Jira User accounts by email and display name. Moovila Teams (Business/Enterprise tier) map to Jira Groups for the purpose of granting project-level access. We preserve security roles as Jira project role mappings (Administrators, Developers, Viewers) where they correspond to Moovila's permission tiers. SSO and domain management settings are documented as configuration notes for the admin to reconfigure in Jira Identity Management post-migration.

Moovila attachments stored in Box, Dropbox, SharePoint, OneDrive, or Google Drive are referenced via cloud storage URLs. Jira attachments are stored within Jira's native attachment store. We extract the file reference URLs during extraction and attach them to the corresponding Jira Issues during import, using the Jira Attachment API. If the cloud storage URLs require authentication, we flag this during discovery and the admin configures the appropriate OAuth or share-link access for Jira to resolve the files.

Moovila cost codes, billing codes, and rate schedules (Business/Enterprise tier) have no native Jira equivalent. We document the full cost and billing code schema including code values, rate schedules by role and individual, and billing rate assignments per project as a written configuration guide. The admin creates corresponding Jira custom fields (cost_code__c, billing_code__c, billing_rate__c) and applies them to the relevant issue screens. Cost and billing reporting requires Jira add-ons or a data warehouse integration for revenue analysis.