Migrate from OmniPlan to Microsoft Project

Each .omniplan file is one Project. We extract project-level metadata (name, start date, calendar reference, baseline set name, and currency) and write these as Project summary fields in MS Project. The destination MS Project file is created as a new project plan with the correct project start date and default calendar applied before any task or resource data imports.

OmniPlan tasks map directly to MS Project tasks. Name, Start, Finish, Duration, and Outline Level are preserved. We explicitly write the Duration Type (work-time or elapsed) as an MS Project flag field or note since MS Project handles elapsed time via duration unit format or scheduling mode. Child tasks with Outline Level greater than 1 are imported as summary tasks in MS Project, preserving the WBS hierarchy.

Named resources (people, equipment, materials) migrate to MS Project Resources with Max Units, Standard Rate, and Cost Per Use preserved. Resource type (Work, Material, Cost) maps from OmniPlan's resource classification. If OmniPlan resource calendars differ from the project default, we attach the non-standard calendar to the resource record in MS Project.

OmniPlan resource-to-task assignments map to MS Project Assignments with Units (allocation percentage), Work, and Start/Finish derived from the task schedule and resource calendar. If the OmniPlan assignment has an overridden effort value, we write the effort directly to the Assignment Work field. MS Project recalculates Assignment Units based on the task duration and resource max units unless the assignment was configured as effort-driven in OmniPlan.

Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish dependencies migrate with lead and lag time expressed in the same duration format. OmniPlan lag time notation converts to MS Project format (e.g., '+5d' for 5 days lag). We validate that all predecessor tasks exist in the destination file before writing dependencies to avoid orphaned references.

OmniPlan milestones are tasks with zero duration. We write these as MS Project tasks with Duration = 0 and the Milestone flag set to Yes. The milestone name, start date, and any custom fields carry over. We flag milestones explicitly because MS Project derives milestone status from zero duration, not from a separate object type.

Hammock tasks derive their duration from child tasks in OmniPlan. Microsoft Project does not support dynamic hammock task formulas natively. We freeze the computed start and finish dates at migration time and write a fixed-duration task with the original hammock name. A note field in MS Project references the original hammock children for audit purposes. This is the standard approach recommended in the OmniGroup export documentation for MPP round-trip fidelity.

OmniPlan recurrence rules (daily, weekly, monthly, annual) are expanded into a series of individual task instances. Each occurrence inherits the original task's duration, resource assignments, and dependencies. MS Project supports recurring tasks natively, but expanding them during migration ensures each occurrence is an independent task row that can be edited individually in the destination without breaking a recurrence template.

OmniPlan Pro custom fields (text, number, date, dropdown, checkbox) map to MS Project custom fields (Text, Number, Date, Flag, Cost) using the closest MS Project type. We pre-create the custom field schema in the destination project before data import. Multi-select dropdown values in OmniPlan map to MS Project outline codes or text fields with delimited values.

OmniPlan supports multiple named baselines with snapshot dates. MS Project Standard supports a single baseline plus up to 10 interim plans. We write the most recent baseline as the MS Project baseline and store additional baseline sets as custom fields (Baseline1_Start, Baseline1_Finish, Baseline1_Duration) for comparison purposes. Monte Carlo confidence interval data from OmniPlan Pro migrates as custom numeric fields.

OmniPlan work calendar settings (standard hours per day/week, weekly schedule, holidays, and exceptions) map to MS Project base calendars at the project level and resource-specific calendars where exceptions exist. Non-standard working time exceptions require explicit re-entry in MS Project because exception dates are stored as individual entries rather than a rule-based calendar.

Split tasks in OmniPlan have discontinuous work segments. We represent each split segment as a separate task row with a shared split-group identifier in a custom field. MS Project renders these together in the task usage view; the grouping identifier allows admins to reconstruct the split visually in the destination. A note on the primary segment documents the split pattern for reference.