Migrate from OpenProj to Microsoft Project

OpenProject Projects map directly to Microsoft Project plans. Each OpenProject project (with its modules, members, and work packages) becomes a single .mpp file or a Project Online PWA project. We preserve the project name, description, and start date. OpenProject's per-project module activation has no Microsoft Project equivalent; we document which modules were active and note the gap in the migration inventory.

OpenProject Work Packages map to Microsoft Project Tasks. The work package subject becomes the Task Name. Start and due dates map to Start and Finish. Estimated hours map to the Estimated Hours or Work field depending on the destination Project version. The work package description maps to the Notes field. OpenProject's type and status fields have no direct Microsoft Project equivalent; we map them to custom fields in Project that we configure during migration. Parent-child work package hierarchy maps to the WBS (Work Breakdown Structure) outline in Project.

OpenProject types (Task, Feature, Bug, Milestone, Phase, Epic) have no built-in equivalent in Microsoft Project. Project uses Task Type (Fixed Units, Fixed Duration, Fixed Work) for calculation behavior, not categorization. We create a custom picklist field in Project called Work_Package_Type__c and map each OpenProject type to a value in that list. This preserves the categorization for reporting without changing Project's scheduling behavior.

OpenProject statuses (New, In Progress, Closed, etc.) are globally configurable workflows per type. Microsoft Project uses Task Status (Complete, In Progress, On Hold, etc.) as a percentage-complete proxy rather than a workflow state. We create a custom text field Status__c in Project and map the OpenProject status name directly. If the customer requires a strict status workflow, we document the mapping table for rebuild in Power Automate or a Project Server workflow post-migration.

OpenProject time entries (hours, rate, cost, linked to a work package and user) map to Microsoft Project Assignment Actual Work on the corresponding task. We extract the hours and cost from each OpenProject time entry, find the matching task in Project, and set the Assignment Actual Work and Actual Cost fields. If OpenProject's cost module is unavailable on the source instance, we note the gap and skip the cost field population.

OpenProject users mapped to a project become Microsoft Project Resources. We create Resources in Project using the user's name and email. We configure the Resource Calendar to match the OpenProject working hours (default 40h/week if no custom calendar exists). Resource cost rates require manual entry in Project because OpenProject stores cost rates differently. Users without a corresponding Project license are created as Material Resources or noted in the reconciliation queue.

OpenProject versions (milestones with a name, description, status, and date) map to Microsoft Project milestone tasks. A milestone task in Project has zero duration; we set the milestone task's Finish date to the OpenProject version's date and preserve the name and description. Work packages assigned to the version retain their assignments and map as regular tasks under the milestone.

OpenProject custom fields (text, integer, float, Boolean, list, date, user, hierarchy) are Enterprise-only. Microsoft Project supports enterprise custom fields from the PWA interface (Project Online) or via field dialogs (desktop). We pre-create matching custom fields in the destination Project environment during the schema design phase. The customer's admin configures any lookup tables or list values in Project Online PWA. Community-sourced OpenProject instances have no custom fields; we skip this step and note it in the migration scope.

OpenProject attachments are linked to work packages with metadata (filename, mime type, author, created-at). The OpenProject API caps file link creation at 20 per request, so we batch large attachment sets. We extract the file content and embed it in the destination MPP or link it to a SharePoint document library if the customer uses Project Online with SharePoint sync. Microsoft Project has no API-based bulk attachment import; we handle this as a post-import file placement step with a manifest linking each file to its task.

OpenProject meetings (title, date, duration, location, attendees, minutes as Markdown) have no direct Microsoft Project equivalent. We create a task in Project with the meeting title and set it as a summary task with the meeting duration. Attendee list and minutes are stored in the task Notes field. If the customer uses Microsoft 365, we recommend recreating meetings in Outlook or Teams as the collaboration replacement and note this in the migration inventory.

OpenProject wiki pages (Markdown content with attachments scoped to a project) have no Microsoft Project equivalent. Wiki content migrates as a text document linked to the Project file or stored in the customer's SharePoint site. We preserve the wiki page hierarchy as folder structure and note the gap in the migration inventory. If the customer uses Project Online with SharePoint, we recommend recreating wiki content as SharePoint pages post-migration.

OpenProject cost tracking via the Costs module (labour costs, unit costs, budget values per work package) maps to Microsoft Project Fixed Cost, Fixed Cost Accrual, and Per Resource cost fields on tasks. The OpenProject cost module is not available on all hosting modes; we flag missing cost data during discovery. If cost entries are present, we map the budget value to the task's Fixed Cost and note that Project's cost calculation model differs from OpenProject's.