Migrate from Mosaic to Jira

Mosaic Projects map to Jira Projects as the top-level container. Mosaic project metadata including status, start and end dates, associated client, and budget amounts transfer as Jira custom fields (e.g., mosaic_budget__c, mosaic_client__c, mosaic_status__c). The Jira Project key is derived from the Mosaic project name using an abbreviated prefix. We create the Jira Project via the Jira REST API before importing any child records. If the customer uses Mosaic phases as sub-planning units, those map to Jira Labels, Components, or a custom Phase field depending on the Jira project scheme.

Mosaic Client records represent organizations or companies associated with projects. In Jira, which has no native Account or Company object, we handle this as a configuration decision during scoping: Clients can map to a custom mosaic_client__c text or select field on Jira Issues, or to Jira Labels if the customer wants client-level filtering via JQL. We preserve client-to-project associations by setting the custom client field on every Jira Issue linked to the source Mosaic project. Client billing contact and address details migrate as additional custom fields if required.

Mosaic Employee records (sourced from integrated HRIS systems like Gusto) include names, departments, roles, start dates, and compensation. These map to Jira User accounts resolved by email address. Jira User records are created manually or provisioned via directory sync (Google Workspace, Okta, Azure AD) before migration. Compensation and department data from Mosaic does not map to a standard Jira field and migrates as custom fields (mosaic_department__c, mosaic_employment_start__c) if the customer needs the data visible in Jira. Mosaic integration credentials (OAuth tokens) do not transfer; we document which HRIS was connected so the customer can re-establish the integration in Jira or their identity provider.

Mosaic Time Entries log hours against Projects and Employees with date, hours worked, and billing rate. These translate to Jira Worklog records. Each Worklog is linked to the Jira Issue representing the corresponding Mosaic project task or Epic (determined during scoping), with the Jira User resolved from the Mosaic Employee mapping. ActivityDate preserves the original Mosaic timestamp. When migrating time entries from a Mosaic Hosted integration (e.g., Deltek Vision) to a Jira destination, a stored procedure must be added to the Deltek product for future time entry sync to function post-migration. We coordinate this as a post-migration configuration step with the customer's Deltek administrator.

Mosaic Phases subdivide Projects into logical planning stages with names, date ranges, and phase-to-project relationships. Jira has no native Phase object. We offer two configuration strategies during scoping: mapping phases to Jira Labels (enabling JQL filtering and board grouping) or mapping to Jira Components (better for component-level assignment and reporting). The phase date range migrates as custom fields (mosaic_phase_start__c, mosaic_phase_end__c) if the customer needs timeline visibility at the phase level in Jira.

Mosaic Custom Metrics store user-defined formulas for variance analysis and KPI tracking. These formulas (e.g., budget vs. actual variance ratios, utilization percentages) do not map 1:1 to Jira calculated fields because Jira does not have a native formula engine equivalent to Mosaic's formula builder. We evaluate each custom metric during scoping, flag unsupported functions, and recreate them as Jira custom fields populated at migration time or extended by Jira apps (e.g., ScriptRunner for calculated fields). Customers should expect a validation pass post-import to confirm calculated values match expectations. Complex multi-step formulas require the customer to document the logic for manual rebuild or a post-migration configuration engagement.

Mosaic Reports (variance analysis reports, FP&A dashboards, chart configurations) are stored in the application layer and cannot be programmatically extracted via API. Jira does not have an equivalent FP&A reporting model. We do not migrate Reports. Instead, we deliver a written inventory of every Mosaic report with its name, data sources, chart types, filters, and scheduling configuration so the customer's admin can evaluate Jira alternatives (native Jira dashboards, eazyBI, or Tableau for financial reporting) and rebuild the most critical ones post-migration.

Mosaic maintains native integrations with Gusto (HRIS), Deltek products (Vision, Vantagepoint), and other ERP systems. OAuth credentials and refresh tokens stored in Mosaic's platform layer are not portable across platforms. We do not migrate integrations. We export integration configuration as reference metadata: which systems were connected, the sync frequency, and which Mosaic fields mapped to which source system fields. The customer uses this inventory to re-establish connections in Jira (via Jira apps or native integrations) or their destination HRIS/ERP with equivalent field mapping.

If the customer's Mosaic instance includes custom objects beyond the standard FP&A schema, we migrate them to Jira custom object types (Jira Projects with custom issue types, or Jira-generated custom objects depending on the Jira edition). Custom object naming convention uses the source API name with Jira naming standards applied. We pre-create the destination schema including custom fields and any lookup relationships before data import. Custom objects that reference Employees, Projects, or Clients require those parent records to exist first in the migration sequence.

Mosaic stores notes and commentary against planning records. If the customer has note-type engagement data linked to Projects or Employees, we migrate these as Jira Issue Comments attached to the corresponding Jira Project's issues. Rich text formatting is preserved where possible. Jira's comment model is flat (no threading), so any hierarchical note structures in Mosaic flatten to sequential comments ordered by timestamp. Attachments migrate as Jira attachments via the Jira REST API, with null-filename attachments flagged and excluded per Jira's import requirements.