Project Management migration

Migrate from ProjectFlow to Microsoft Project

Field-level mapping, validation, and rollback between ProjectFlow and Microsoft Project. We move data and schema; workflows are rebuilt natively in Microsoft Project.

ProjectFlow logo

ProjectFlow

Source

Microsoft Project

Destination

Microsoft Project logo

Compatibility

67%

8 of 12

objects map 1:1 between ProjectFlow and Microsoft Project.

Complexity

BStandard

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from ProjectFlow to Microsoft Project is a structural migration that must account for two compounding constraints: ProjectFlow has no documented public REST API, so CSV export is the primary extraction mechanism, and DailyReports — a construction-industry object in ProjectFlow — have no direct Microsoft Project equivalent. We request CSV exports of all Projects, Tasks, Documents, and DailyReports directly from the customer, parse the structured rows, and map them to Microsoft Project's task structure with start and finish dates, durations, and predecessor dependencies intact. Subtask hierarchies that exceed Microsoft Project's WBS nesting depth are flattened or re-parented during the transform phase. Alerts, ProjectShares, and multicompany user structures require manual reconfiguration in Microsoft Project's resource and sharing views. Workflow definitions in ProjectFlow export as zip files rather than structured data; we do not migrate them as automation code but instead deliver a written inventory of every alert and notification rule for the customer's admin to rebuild in Microsoft Project.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

ProjectFlow logo

ProjectFlow

What's pushing teams away

  • CSV export is currently the only documented export mechanism, making migrations of large portfolios time-consuming and error-prone without dedicated tooling.
  • Workflow export produces a zip file rather than a machine-readable format, requiring manual re-creation of complex workflow definitions in the destination system.
  • No public API documentation was found during research, limiting integration options and preventing automated migration pipelines for customers with real-time data requirements.
  • Enterprise tier required for multicompany structures and advanced resource planning, pushing smaller teams toward platforms with these features included at lower tiers.

Choosing

Microsoft Project logo

Microsoft Project

What's pulling them in

  • Organizations already running Microsoft 365 and Azure AD adopt Microsoft PPM because it slots into existing identity, Teams, and SharePoint infrastructure without requiring a separate identity provider or SSO vendor.
  • Enterprise PMOs choose it for critical-path scheduling, baseline comparison, cross-project dependencies, and resource utilization reporting that standalone PM tools cannot replicate at this depth.
  • Project Online's integration with Power BI gives portfolio-level dashboards and cost-rollup reporting that satisfies executive governance requirements without third-party BI tooling.
  • Government, financial services, and healthcare organizations select it because FedRAMP, ISO 27001, and SOC 2 compliance certifications meet enterprise procurement requirements out of the box.
  • Large IT departments default to it as the market-leader in project portfolio management software, often driven by corporate licensing agreements that bundle it with other Microsoft 365 seats.

Object mapping

How ProjectFlow objects map to Microsoft Project

Each row shows how a ProjectFlow object lands in Microsoft Project, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

ProjectFlow

Project

maps to

Microsoft Project

Project (MPP or Project Online project)

1:1
Fully supported

ProjectFlow Projects map 1:1 to Microsoft Project files or Project Online project plans. The project name, description, start date, target finish date, status, and priority migrate directly. We preserve the project-level metadata (customer, project manager, contract type) as task notes or custom fields in Microsoft Project because Project Online has no native project-level custom field object at the file level. Project-level Documents and DocumentFolders are linked via URL fields or recreated in SharePoint Online per the customer's document management preference.

ProjectFlow

Task

maps to

Microsoft Project

Task

1:1
Fully supported

ProjectFlow Tasks map 1:1 to Microsoft Project Tasks with Name, Start, Finish, Duration, Priority, and Status preserved. The Task's start_date and due_date map to Microsoft Project Start and Finish fields; estimated hours map to the Duration field (converted to duration units). Custom task fields from ProjectFlow are enumerated during discovery and mapped to Microsoft Project custom fields (Text1-30, Number1-10, Cost1-10, Flag1-20) via the Field List customisation dialog.

ProjectFlow

Subtask

maps to

Microsoft Project

Subtasks (summary task hierarchy)

1:1
Fully supported

ProjectFlow subtasks map to Microsoft Project's summary-task and sub-task hierarchy. Microsoft Project supports hierarchical task structures with summary tasks (parent rows) and sub-tasks (child rows) up to a practical WBS depth of 8-10 levels. We flag during scoping if the subtask hierarchy exceeds this depth and either flatten the excess levels or re-parent the deepest records under a newly created summary task. The indentation structure is preserved as Outline Level in Microsoft Project.

ProjectFlow

Milestone

maps to

Microsoft Project

Milestone (task with zero duration)

1:1
Fully supported

ProjectFlow Milestones map to Microsoft Project Milestone tasks — tasks with Duration = 0 and Milestone = Yes. The milestone name, target date, and any linked tasks migrate directly. We verify that milestone dates are correctly set as Finish dates on zero-duration tasks because Microsoft Project derives milestone status from the Finish date and duration value, not from a separate milestone flag field.

ProjectFlow

GanttCharts

maps to

Microsoft Project

Task dependencies (predecessors/successors)

1:1
Mapping required

ProjectFlow Gantt structure — task bars, start/end dates, and dependencies — is extracted and reconstructed in Microsoft Project using the FS (Finish-to-Start) dependency type as the default. Cross-dependency links from ProjectFlow that do not map to a standard Microsoft Project predecessor type (SS, FS, FF, SF) are stored as task Notes with the original dependency type noted, or linked via a custom Flag field. Lag time and lead time from ProjectFlow migrate as Successor fields with positive or negative day offsets.

ProjectFlow

Document

maps to

Microsoft Project

Document (SharePoint or file path reference)

1:1
Fully supported

ProjectFlow Documents are linked to projects and optionally nested inside DocumentFolders. We export document metadata (file name, URL path, linked project, linked task, author, created date) and recreate document references in Microsoft Project using a URL custom field on the relevant task or as a SharePoint document library linked to the Project Online site. Actual file transfer uses the customer's preferred storage path (SharePoint Online, OneDrive for Business, or local file share). Document versioning is not preserved; we transfer the current version only.

ProjectFlow

DocumentFolder

maps to

Microsoft Project

SharePoint folder structure or flat task notes

lossy
Fully supported

ProjectFlow DocumentFolders with their parent-child hierarchy are preserved as a flat list of folder paths and recreated as a SharePoint Online document library structure within the associated Project Online site. If the destination is Microsoft Project Desktop without SharePoint, the folder hierarchy is documented as a path list in the project Notes and provided as a CSV for manual folder creation.

ProjectFlow

DailyReports

maps to

Microsoft Project

Task Notes or Comments

lossy
Mapping required

ProjectFlow DailyReports (construction-industry-specific with site-level progress, weather conditions, and labour counts) have no direct Microsoft Project equivalent. We map DailyReports to a combination of task Notes on the relevant project or summary task and a CSV export of the original DailyReport data for the customer's records. We flag any loss of structured site-specific fields (weather, labour counts, equipment on site) during scoping and allow the customer to choose whether to include these as formatted note text or exclude them entirely.

ProjectFlow

Alert

maps to

Microsoft Project

Reminder or Flag icon

lossy
Fully supported

ProjectFlow alert thresholds and notification rules are platform-specific and do not have a native Microsoft Project equivalent. We extract alert configurations as a structured CSV during discovery and provide a written alert inventory that maps each ProjectFlow alert to a corresponding Microsoft Project Reminder (flag icon, reminder time) or to a SharePoint workflow for email notification. The customer configures these manually in the destination.

ProjectFlow

Assignee

maps to

Microsoft Project

Resource Assignment

1:1
Fully supported

ProjectFlow assignees on Tasks and Projects map to Microsoft Project resource assignments on tasks. We resolve ProjectFlow users by email match to Microsoft Project resources. Enterprise multicompany structures in ProjectFlow may result in the same person appearing as separate assignees under different company contexts; we deduplicate these to a single resource record in Microsoft Project during the mapping phase and flag any history attribution ambiguity. If a ProjectFlow assignee has no corresponding resource in Microsoft Project, they are held in a reconciliation queue for the customer's admin to provision before record import.

ProjectFlow

ProjectShares

maps to

Microsoft Project

Sharing and permissions

lossy
Mapping required

ProjectFlow ProjectShares control which users or external parties have access to a project. We map these to Microsoft Project Online's sharing model (Project Online site permissions via SharePoint Online groups) or to Microsoft Project Desktop file-level sharing if the destination is the desktop application. Role definitions differ between platforms; we document the original ProjectShares as a permissions matrix CSV and note where the destination's permission model diverges from the source.

ProjectFlow

Custom Fields

maps to

Microsoft Project

Custom Fields

1:1
Mapping required

ProjectFlow custom fields on Projects and Tasks vary by tier. We enumerate all active custom fields during discovery (field name, data type, values, linked object) and map them to equivalent Microsoft Project custom fields via the Task Information or Project Information Field List dialog. Field types map as follows: text to Text custom fields, numbers to Number fields, dates to Date fields, currency to Cost fields, and multi-select options to Outline Code or Flag fields. Fields that have no Microsoft Project equivalent are flagged and either dropped or converted to Notes text.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

ProjectFlow logo

ProjectFlow gotchas

High

No documented public REST API for automated exports

Medium

DailyReports object is construction-industry specific

Medium

Enterprise multicompany structure complicates user deduplication

Microsoft Project logo

Microsoft Project gotchas

High

Project for the web is being retired and merged into Microsoft Planner

Medium

Planner-tier portfolio features are incomplete despite Plan 5 labeling

Medium

Web app constraint controls are weaker than the Windows desktop client

High

Project requires a separate license not bundled with standard Microsoft 365

Medium

Project Online API is edition-gated and inconsistently documented

Pair-specific challenges

  • No public REST API forces CSV-only extraction

    ProjectFlow does not publish a REST API endpoint reference. CSV export is the only documented data extraction mechanism. We request CSV exports of Projects, Tasks, Documents, and DailyReports directly from the customer and parse the structured rows. If CSV exports are unavailable in the customer's tier or the export produces inconsistent row structures due to custom field variance, we fall back to assisted screen-scraping using FlitStack AI's capture tooling. This adds discovery time and may require manual field verification for each migrated project. We recommend requesting a full CSV export during the scoping phase before migration begins.

  • DailyReports have no Microsoft Project equivalent

    ProjectFlow's DailyReports are a construction-industry-specific object recording daily site-level progress including narrative notes, weather conditions, labour counts, and equipment status. Microsoft Project has no native DailyReport object; progress is tracked via % Complete on tasks and task Notes. We map DailyReports to a combination of task Notes and a standalone CSV of the original DailyReport data for archival purposes. Any structured fields — particularly weather conditions, labour counts, and equipment status — are flattened into note text and flagged as a potential data loss item during the scoping sign-off.

  • Subtask nesting depth may exceed WBS limits

    ProjectFlow supports subtask hierarchies whose depth depends on the customer's tier configuration. Microsoft Project's practical WBS nesting depth is approximately 8-10 levels before the outline becomes difficult to read and manage. We flag when subtask hierarchies exceed this depth during the discovery phase and either flatten excess levels (re-parenting deeply nested tasks under a new summary task named '[Imported Subtasks]') or preserve the full hierarchy as a ProjectFlow-native CSV alongside the migrated file. The customer chooses the strategy before migration begins.

  • Multicompany Enterprise structures complicate resource deduplication

    ProjectFlow Enterprise tier supports a multicompany structure where the same person may exist as a user under multiple company contexts within a single ProjectFlow instance. When migrating to Microsoft Project's single-company resource pool, we must identify and deduplicate these cross-company user records during the assignee mapping phase, preserving task history attribution correctly. We produce a deduplication report listing each resolved resource with the original ProjectFlow company context preserved as a custom resource field.

Migration approach

Six steps for a successful ProjectFlow to Microsoft Project data migration

  1. Discovery and CSV export request

    We audit the ProjectFlow instance across tier (Grow/Professional/Enterprise), active Projects, Task count, subtask nesting depth, Documents and DocumentFolders, DailyReports, Alerts, and user count. We specifically request CSV exports of all Projects, Tasks, Documents, and DailyReports from the customer and validate the row structure and field headers. If CSV exports are incomplete or unavailable in the customer's tier, we document the gap and propose assisted screen-scraping as a fallback. We also enumerate any multicompany user structures requiring deduplication. The discovery output is a written migration scope, a field-level mapping spreadsheet, and a DailyReport handling decision signed off by the customer.

  2. Microsoft Project destination planning

    We identify the target deployment: Microsoft Project Desktop (MPP file format) or Project Online (cloud). For Project Online, we identify the target tenant, Project Online site collection, and SharePoint Online document library for document storage. For Desktop, we identify the target file storage location. We plan the custom field schema in Microsoft Project (which custom fields are needed, which data types to use, and where Outline Codes apply). We also configure the project calendar and working time settings if the ProjectFlow instance uses non-standard working days.

  3. CSV parsing and transform

    We parse the ProjectFlow CSV exports into a normalised intermediate format. Tasks are sorted by project and then by parent-child hierarchy to reconstruct the WBS structure. Subtask nesting is validated against Microsoft Project's depth limits and flattened if necessary. DailyReports are parsed separately and transformed into a structured note format for insertion into the relevant project or summary task Notes fields. Alerts are extracted as a structured CSV and mapped to the Microsoft Project Reminder inventory. Assignees are resolved by email match and deduplicated for multicompany structures.

  4. Sandbox migration and reconciliation

    We run a full migration into a sandbox environment: a test MPP file for desktop targets, or a Project Online test site for cloud targets. The customer reconciles record counts (Projects, Tasks, Milestones, Documents, DailyReports), spot-checks 25-50 random tasks against the ProjectFlow source, and verifies that subtask hierarchies, milestone dates, and predecessor dependencies are intact. Any mapping corrections — particularly around custom field types, DailyReport note formatting, and resource deduplication — happen in this phase before production migration begins.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Projects (as the parent container), Tasks (with WBS hierarchy reconstructed), Milestones (zero-duration tasks), Gantt dependencies (predecessor links), Resources and Assignee assignments (with deduplication applied), Documents (as SharePoint links or file path references), and DailyReports (as task Notes). Each phase emits a row-count reconciliation report before the next phase begins. We run a final delta migration for any records modified during the migration window.

  6. Cutover, validation, and alert rebuild handoff

    We freeze ProjectFlow writes during cutover and perform a final delta migration. We enable the Microsoft Project file or Project Online site as the system of record. We deliver the Alert and Notification Inventory document mapping each ProjectFlow alert to a Microsoft Project Reminder configuration step. We provide the DailyReport archive CSV as a standalone export. We support a one-week hypercare window to resolve any reconciliation issues. We do not rebuild ProjectFlow alert configurations as Microsoft Project workflows inside the migration scope; that work is documented for the customer's admin to configure manually.

Platform deep dives

Context on both ends of the pair

ProjectFlow logo

ProjectFlow

Source

Strengths

  • Three-tier pricing model with a clear feature progression from Grow through Professional to Enterprise.
  • Microsoft 365 and Power BI integration for reporting and analytics out of the box.
  • Supports both agile and traditional project management methodologies within a single instance.
  • Construction-industry variant includes native DailyReports and DocumentFolders for site-level tracking.

Weaknesses

  • No publicly documented REST API limits the ability to build automated integrations or migration pipelines.
  • CSV export is the primary data portability mechanism; bulk structured migrations require manual preparation.
  • Workflow definitions export as zip files rather than structured data, complicating migration of automation rules.
  • Rate limits and API quotas are not publicly documented, creating uncertainty for customers with high-volume data needs.
Microsoft Project logo

Microsoft Project

Destination

Strengths

  • Deep critical-path scheduling with baseline comparison and cross-project dependency tracking unmatched by lighter PM tools.
  • Native Azure AD authentication, Teams integration, and Power BI reporting sit on infrastructure enterprises already license and manage.
  • Enterprise governance controls including demand intake workflows, resource request approval, and portfolio-level capacity analysis.
  • Supports both Waterfall and Agile methodologies within the same project, accommodating hybrid delivery teams.
  • Scalable from Project Plan 1 for small teams to Project Server on-premises for regulated industries with strict data-sovereignty requirements.

Weaknesses

  • Ease-of-use scores trail the category average by a wide margin; onboarding friction frustrates new users consistently across G2 and Capterra reviews.
  • Pricing ranks 42nd of 49 tools in its category — the total cost of ownership including IT administration and training is rarely recovered for small or mid-market teams.
  • No built-in client portal, external stakeholder sharing, or proofing workflow, limiting use cases to internal PMO environments only.
  • The web interface (Project for the web / Planner Premium) has materially weaker constraint controls and resource auto-leveling than the Windows desktop client.
  • Project for the web is being consolidated into Microsoft Planner, creating uncertainty about which product tier will host project portfolio data long-term.

Complexity grading

How hard is this migration?

Standard Project Management migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across ProjectFlow and Microsoft Project.

  • Object compatibility

    B

    2 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    ProjectFlow: Not publicly documented.

  • Data volume sensitivity

    B

    ProjectFlow doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your ProjectFlow to Microsoft Project migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about ProjectFlow to Microsoft Project data migrations

Answers to the questions buyers ask most during ProjectFlow to Microsoft Project migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your ProjectFlow to Microsoft Project migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between two and four weeks for portfolios of up to 50 Projects and 5,000 Tasks with no DailyReports and clean CSV exports. Migrations with large DailyReport volumes (requiring manual field-to-note transformation), deeply nested subtask hierarchies that need flattening, or Enterprise multicompany structures requiring resource deduplication extend to four to eight weeks. The CSV export availability and quality from the customer's ProjectFlow instance is the primary variable.

Adjacent paths

Related migrations to explore

Ready when you are

Move from ProjectFlow.
Land in Microsoft Project, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day