Migrate from Viewpath to Jira

Viewpath Projects map to Jira Projects. Project name, description, start date, end date, status, and owner assignment migrate. Viewpath did not have a structured portfolio or program object, so no portfolio-level aggregation migrates. We create Jira Projects in the destination instance using the Jira REST API, setting the project type to Software (Jira Software Cloud). If the customer uses Jira Service Management or Business projects, that designation is made during scoping.

Viewpath Tasks map to Jira Issues. Task name, description, planned start and end dates, duration, percent complete, and assignment migrate to Jira Issue summary, description (stored as Jira rich text), due date, and assignee. Viewpath's percent complete does not map to Jira's native completion model (Jira does not track percent complete on Issues by default; we store it in a custom number field p_complete__c for reporting). We flag any Task that was locked in Viewpath's UI and do not set an equivalent lock flag in Jira.

Viewpath dependency links (finish-to-start, start-to-start, finish-to-finish, start-to-finish) map to Jira Issue Links. Jira's default link types include Blocks, Is blocked by, Depends on, and Duplicate. We map Viewpath finish-to-start to Jira 'Blocks' / 'is blocked by', and preserve the dependency type as a custom select field dependency_type__c so the customer's admin can configure link behavior accordingly. Circular dependency chains are detected and reported for manual resolution before import.

Viewpath Resources (people allocated to tasks) map to Jira Assignee on each Issue. We extract resource name, email, role, and allocation percentage. Jira uses a User-assignee model rather than a separate Resource object. We match resources by email against the Jira destination instance's user directory. Any Viewpath resource without a matching Jira user goes to a reconciliation queue; the customer's Jira admin provisions the missing users before record import continues.

Viewpath baseline schedules (saved project baselines for schedule comparison) migrate as a data artifact. Baseline start and end dates per task are stored in a custom Jira field baseline_dates__c as a structured text or JSON value that the customer can reference. Not all Jira configurations support baselines natively; if the destination is Jira Premium or Enterprise with Advanced Roadmaps, baselines can be restored within that module. We document the baseline data format during extraction so the customer admin can map it appropriately.

Viewpath custom filtered reports are exported as raw data with filter logic documented. The filter definition (field conditions, sort order, grouping) is captured in a written report artifact that the customer's Jira admin can use to rebuild equivalent Jira filters and dashboard gadgets. Jira's native filter system (JQL-based) and dashboard gadgets (created via the Jira REST API) replace Viewpath's proprietary report formats.

Viewpath's Gantt view is the primary UI; Gantt configuration (column layout, grouping, collapsed rows) was stored as a view preference. Jira does not have a native Gantt chart in Jira Software Cloud standard view, but Jira's Backlog view, Scrum board, and (with Advanced Roadmaps) Timeline view provide equivalent scheduling visibility. We extract the underlying schedule data from the Gantt and map it to Jira Issues with due dates and start dates; the customer admin configures the Jira view layout to match their scheduling preference.

Viewpath attachments were Google Drive links via Viewpath's embedded viewer. Since Viewpath's OAuth integration is no longer valid, we attempt to resolve each linked document by extracting the original Google Drive URL. Where the link resolves, we flag it as a recoverable document. Where the link is broken or the file is inaccessible, we report the broken link in the extraction inventory and recommend the customer re-upload or re-link those files in Jira directly.

Viewpath Users (task owners and resources) migrate as Jira Users. We extract full user list including name, email, and role. Email is the primary matching key for Jira User lookup. User-to-resource mapping is preserved so task assignments can be restored in Jira. Jira Cloud's user management (native Atlassian accounts or external directory via Atlassian Access) is configured during scoping.

Viewpath was designed for individual project scheduling and did not have a structured Portfolio or Program object. We do not migrate non-existent data. Any portfolio-level aggregation or reporting that the customer requires is rebuilt in Jira using Advanced Roadmaps (Premium/Enterprise tier) or a Jira Marketplace app post-migration.