Migrate from Fluid to Microsoft Project

Fluid Projects map directly to Microsoft Project Online Projects (PWA project records). We extract the project name, description, status, start and finish dates, and owner assignment as standard fields. Project Site provisioning in SharePoint Online is either pre-existing or created during PWA configuration; we note whether a SharePoint site exists for the project and flag its URL for the customer to confirm access before migration. Projects are the first records imported because all task, assignment, and effort data depends on the project-level key.

Fluid Programs are top-level groupings of related projects with program-to-project parent relationships. Microsoft Project Online PWA has no native Program object; Programs must be represented as a project-level grouping structure. We map Programs to a designated summary-level project that acts as a program container, or to a SharePoint hub site naming convention, depending on which approach the customer selects during scoping. We document the program-to-project membership in a separate CSV reference table alongside the migration so the PMO can rebuild the program view in Project Online using SharePoint hub sites or a third-party portfolio tool if desired.

Fluid Tasks map to Project Online Tasks with the full standard field set: Task Name, Start and Finish dates, Duration, Priority, Status, WBS code, and Outline Level. We preserve the parent-child task hierarchy from Fluid by setting the Outline Level and WBS fields in Project Online so that summary tasks and sub-tasks render correctly in the Gantt chart. Task-level dependencies (finish-to-start, start-to-start) are extracted from Fluid's linked-task records and mapped to Project Online predecessor-successor relationships using the PredecessorLink table.

Fluid Subtasks inherit fields from their parent task. We flatten Subtask records into the parent Task row with a deeper Outline Level value (2, 3, etc.) so that Project Online renders them correctly as indented rows in the task list and Gantt view. We tag each indented row with a custom WBS prefix matching the parent's WBS code for traceability. Where the destination Project Online environment uses Enterprise Project Types with different required fields, we apply the relevant enterprise custom fields during task import.

Fluid assignees are named users linked to task records. We extract every distinct assignee and map them to Microsoft Project Online Resources. If the destination PWA has an Enterprise Resource Pool configured, we resolve each Fluid assignee by matching the display name or email to an existing resource record and create resource assignments linked to the matching Resource GUID. If no Enterprise Resource Pool exists, we create generic resources and document the Fluid-assignee-to-Project-Online-resource lookup table for the customer's admin to resolve post-migration before running the resource loading view.

Fluid Custom Fields are supported but require pre-migration schema review. We read the field name and data type (text, number, date, picklist, boolean) from Fluid's field definition and create a corresponding Enterprise Custom Field in Project Online PWA before any data loads. Text fields map to Text custom fields, numeric fields to Number, dates to Date, picklist values to Outline Codes with the picklist values configured as options. We flag any Fluid custom fields that store non-standard data (arrays, nested JSON, formula outputs) and document them as requiring manual post-migration entry or a Power Apps form as a separate remediation item.

Fluid stores task start and end dates that drive the Gantt visualisation. We extract these as standard date fields (Scheduled Start, Scheduled Finish) and Duration in Project Online's task fields. The Gantt layout itself is a UI construct in both platforms and is not migrated; the underlying schedule data is. If Fluid task records contain constraint dates (must start on, finish no later than) or deadline fields, we map these to the Project Online constraint type fields and flag the constraint type for the customer's PM to review—constraints can affect schedule calculation behaviour in Project Online.

Live effort metrics (hours consumed versus hours planned) are stored per task in Fluid as numeric effort fields. We export these as Assignment Actual Work (hours already consumed) and Remaining Work (hours still planned) on the resource-task assignment in Project Online. If the customer's Fluid data includes both planned and actual effort figures, we map the actual to Assignment Actual Work and the difference to Remaining Work. We flag this mapping during scoping because Project Online calculates percent complete from work values rather than task-level progress percentages, and the customer's PMO may need to adjust Earned Value reporting settings accordingly.

Workload distribution visualisations in Fluid are computed at runtime by aggregating task assignments and effort metrics. These visualisations are not stored as discrete exportable records. We flag this during scoping and advise customers that the visual output cannot be migrated; only the underlying task assignments and effort data (which drive the Project Online Resource Usage view) are transferable. After migration, the Resource Usage view in Project Online PWA can be configured to replicate the workload distribution view if the Enterprise Resource Pool is populated with assignments.

Flex Statistics mode in Fluid stores scenario-modelling and what-if planning data in a proprietary analytical format with no documented export endpoint. Migration of Flex Statistics data is not possible. We document this gap explicitly in the migration scope before work begins and recommend that customers who rely on Flex Statistics for portfolio-level scenario planning export any required data as a manual screenshot or PDF before the migration cutover date. Project Online does not have a native equivalent scenario-modelling feature; customers requiring this capability post-migration should evaluate Microsoft Project Online Premium (Project Plan 5) with Power BI or a third-party scenario planning add-in.

Project Online uses a three-part resource model distinct from Fluid's direct task-to-assignee approach. Resources exist in the Enterprise Resource Pool, Assignments link a Resource to a Task, and Project Online calculates work from Duration, Units, and Assignment Work values. We create or resolve Resources in the Enterprise Resource Pool before importing task-assignment relationships, and we ensure that each Resource has a calendar (Standard or custom) so that task scheduling respects working time. Any Fluid assignees that cannot be resolved to an Enterprise Resource are placed in a reconciliation queue; migration cannot complete with unresolved resource references because Project Online requires a valid Resource GUID on every assignment record.