Migrate from Merlin Project to Jira

Merlin Project files map to Jira Projects. Each Merlin Project file (or group of related files) becomes one Jira Project with a defined Project Key. We use the Merlin Project name as the Jira Project name and derive a two-to-ten character Project Key from the name's initials. If the customer maintains multiple Merlin Project files for a single program, we consolidate them into a single Jira Project with Epics representing sub-initiatives.

Merlin Project Activities map to Jira Issues with the activity type determining the Issue Type. High-level planning Activities (parent tasks with no parent) map to Epic. Deliverable-level activities map to Story. Administrative or tracked-but-not-delivered tasks map to Task. Bug-type work (if defect logging exists) maps to Bug. Sub-activities with a parent Activity map to Subtask. We preserve the activity name as Issue Summary, the start and end dates as Due Date and Custom Start Date fields, and duration as a calculated estimate field. Notes migrate as Issue Description (rich text). Custom properties defined in Merlin Project export become Jira custom fields.

Merlin Project Milestones (zero-duration timeline markers) map to Jira Issues. We create them as Epic with a zero estimate or as a dedicated Issue Type if the customer's Jira instance has a Milestone type configured. The milestone date migrates to Due Date and a custom milestone_target__c field. Milestone status (completed, not completed) migrates to Issue Status. Parent-project milestone grouping is preserved via Epic Link or a custom parent_milestone__c field.

Merlin Project's four dependency types (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) map to Jira Issue Links. FS dependencies where activity B cannot start until activity A finishes map to Jira Blocks relationship. We interpret SS, FF, and SF dependencies and represent them as Blocks or Depends on links with a note in the link comment field indicating the original dependency type, since Jira's standard link types do not natively support all four dependency semantics. We create Jira issue links only after both issues are created in Jira to avoid dangling reference errors.

Merlin Project Resources of type Person map to Jira User accounts. We extract resource names and email addresses from the Merlin Project Resource export. The customer's Jira admin provisions User accounts (or we use the Jira API to provision users if they have admin credentials). We match by email during migration so that each resource assignment in Merlin Project resolves to the correct Jira Assignee on the corresponding Issue. Any unmatched resources go to a reconciliation queue for manual provisioning before the activity migration phase.

Merlin Project Equipment and Material resources have no direct Jira equivalent because Jira does not have a native resource pool with cost rates. We map Equipment resources to Jira Components with the component name matching the resource name, and Material resources to a custom multi-select picklist field resource_materials__c. If the customer requires time-phased resource allocation with capacity planning, we document Advanced Roadmaps configuration as a post-migration step.

Merlin Project Assignments (the linking table between Activities and Resources with allocation percentage and work units) map to Jira Issue Assignee plus a custom work_allocation__c field carrying the allocation percentage. Jira does not natively support split assignments across multiple assignees per issue without third-party apps, so if a Merlin Project Activity has multiple assigned Resources, we create a primary Assignee from the first Resource and document additional assignees in a custom multi-user field secondary_assignees__c. Work hours migrate to an estimate or time tracking field if Jira time tracking is enabled.

Merlin Project file attachments migrate to Jira Issue attachments via Jira's REST API. We extract the file list from the Merlin Project Attachments view CSV (file names and paths) and retrieve the actual file binaries from the Merlin Project file package. Files are uploaded to the corresponding Jira Issue using the issue key as the target. We chunk large attachment batches to respect Jira's file size limits (10 MB per file in Jira Cloud). If the Merlin Project file package is encrypted or password-protected, we flag it for manual handling.

Merlin Project custom properties defined at the Activity or Resource level migrate to Jira custom fields. We map the Merlin Project custom field name and data type to the nearest Jira custom field type (text, number, date, select, multi-select, user picker). Custom fields must be pre-created in Jira with the correct field type before migration; we provide the schema specification during the configuration phase. If a Merlin Project custom field uses a data type that Jira does not support natively (e.g., duration with mixed units), we map it to a text custom field with the original value preserved.

Merlin Project notes attached to Activities, Resources, or the project level migrate to Jira Issue Comments on the corresponding Issue. If a note is project-level rather than activity-level, we attach it to the project's first Epic or to a designated Project Notes issue created for this purpose. Rich text formatting in Merlin Project notes is preserved as Jira's comment wiki markup. Comments are ordered by the original Merlin Project timestamp.

Merlin Project scheduling constraints (As Late As Possible, As Soon As Possible, Fixed Dates) have no native Jira equivalent. We capture the constraint type and date values in a custom field scheduling_constraint__c (text) and a custom field constraint_date__c (date) on the migrated Issue. The dependency chain already preserved via Jira issue links allows Jira's scheduling engine to independently evaluate feasibility. Customers using Advanced Roadmaps configure the constraint behavior post-migration in the Advanced Roadmaps planning view.