Project Online Migration by Industry: 7 Sector Guides

What changes about a Microsoft Project Online migration by industry comes down to three things: the compliance regime that decides what you must archive and how you validate the destination, the scheduling pattern that has to survive import without distortion, and the resource or cost model the schedule is joined to. The rest is the same in every sector. Microsoft Project Online retires on September 30, 2026, a date Microsoft announced in July 2024 and confirms on its product lifecycle page, and Microsoft has not committed to a read-only window, a grace period, or any post-retirement retention.

TL;DR: A Project Online migration differs by industry in three places: the compliance regime that governs the archive and the validation of the replacement, the scheduling pattern that must import intact (hard constraints and shift calendars, four dependency types with lag, multi-baseline history), and the cost or resource model the schedule is tied to. The sequence does not change: inventory the export set, archive what compliance needs, pilot on a real file, migrate in waves, reconnect integrations.

SharePoint 2013 workflows retired earlier, on April 2, 2026, and Project Server 2019 left mainstream support on July 14, 2026. The service, its Project Web App (PWA) site and the OData reporting feed stopped together, so every sector now works from the export set it took: .mpp files, MSPDI XML, OData extracts, SharePoint document libraries and audit logs.

Project Online migration by industry: what changes and what does not

The compliance regime, the scheduling pattern and the cost model are the three variables; the retirement date, the migration sequence and the Project Online data model are the constants. The table compares the seven sectors on the five things that differ.

Energy and manufacturing share constraint-driven schedules and the ERP failure; engineering and construction share the P6 split and the baseline problem.

Construction PMOs: move the portfolio layer, keep Primavera P6

Most construction PMOs never ran their delivery schedules in Project Online. Primavera P6 held the capital programs, the Project desktop client held the smaller site projects, and PWA sat on top as the coordination layer: program status, resource commitments across projects, executive dashboards and the phase gate workflow. That split decides the migration: P6 has no retirement date and stays; only the PWA layer needs a new home.

What lived in PWA, and therefore what the export set contains:

• Project records and metadata: names, owners, dates, phase, status and the Enterprise Custom Fields (ECFs) that classify each project. Construction PMOs commonly carry 30 to 50 ECFs (contract type, program, region, capital versus operating spend, safety tier), each needing a mapped equivalent.
• Summary milestone schedules: phase gates, budget approvals and milestone payment dates with their baseline history, not the full P6 delivery schedule.
• Resource commitments: the engagements showing which programs consume which senior people, a capacity picture that does not exist in P6.
• Governance history: which approvals were given, by whom and when, which contract audits can request years after handover.
• Dashboard and report configurations: never migrated automatically; rebuilt from the screenshots and documentation you took.

Multi-baseline history carries most of the risk. A three-year capital program accumulates an original, a revised and a current baseline, and milestone payments and contract disputes reference the schedule state at specific points in time. Most destination tools store one baseline per project. The full .mpp exports with every baseline set are your legal record: archive them with the contract documents, then import the current state. The guide to Project Online baselines missing after a migration shows how to tell from an export which baselines a project actually carried.

The P6-to-PWA feed is the other risk. Any integration that pushed P6 percent complete, actual dates or earned value into PWA stopped with the retirement. Replace it with the same batch cycle pointed at the new tool: P6 exports a summary .mpp, MSPDI XML or XER file and the new tool imports it, so confirm the candidate imports one of those formats and validate dependency fidelity on a real file. RFIs, submittals, drawings and contract documents in the SharePoint site behind each PWA project are still in SharePoint, which did not retire.

The construction sequence, working from the export set:

1. Inventory the exports. List every project record, ECF, calendar, resource engagement and workflow you exported, and confirm which capital programs have multi-baseline .mpp files.
2. Archive before you import. File the full .mpp exports and the governance history where the contract team can reach them without the PM tool.
3. Select on a real program file. Round-trip the most complex active program through each candidate and compare milestone dates, baseline counts and custom field values against the export; check named multiple baselines, calculated and lookup custom fields, long audit log retention and contractor guest access.
4. Load by phase. Planning-phase programs first, execution-phase programs last, one at a time, each validated against its archived export.
5. Reconnect P6 and rebuild the executive views before retiring the interim reporting.

Energy and utilities: outage windows, NERC CIP evidence and the ERP handoff

Energy and utilities PMOs ran three things on Project Online that a generic plan misses: capital project tracking joined to the ERP, outage coordination inside fixed grid windows, and regulatory programs whose records auditors inspect years later. The pattern at a transmission utility: a pilot import of a capital project with three to five baselines looks reasonable until finance asks why the 2022 audit baseline is missing, because the destination kept only the current one. For a project subject to FERC rate filings, that is an audit finding, not a data quality issue.

Capital projects. Most destination tools store one baseline where Project Online stored eleven; the archive pattern from the construction section applies unchanged, with each historical baseline filed as a dated export auditors can reach without the PM tool.

Grid outage schedules. An outage project has a window the grid operator grants: the line is isolated on day 0 and must be energized by day 10, so the schedule carries Must Start On and Must Finish On constraints and runs on 12-hour or 24-hour shift calendars. The diagram below shows that structure and the two ways an import distorts it.

Constraint coercion is the first failure: Project Online supported eight constraint types, many destination tools support fewer, and a Must Start On that imports as Start No Earlier Than lets a task slip into the re-energization window. Shift calendar loss is the second: continuous 24-hour outage work that imports against a standard 8-hour week turns a three-day task into a nine-day task. Create the shift calendars in the destination first, import, then validate start dates and durations task by task against the exported source.

NERC CIP and FERC evidence. Utilities under NERC Critical Infrastructure Protection standards keep records demonstrating compliance with CIP-007 (patch management), CIP-010 (configuration change management) and related standards. FERC-regulated utilities filing rate cases include capital project evidence: original scope, approved cost estimate and final cost. The compliance archive therefore holds status history for every project touching CIP-covered assets, every baseline snapshot for capital projects subject to rate filings, gate review approval records, resource assignment logs, and retention schedules matched to the regulation. Treat any record not exported before retirement as unavailable.

ERP integration. SAP Plant Maintenance, Oracle EAM and IBM Maximo project codes lived in PWA as Enterprise Custom Fields, read by integration scripts from the OData feed for capital accounting. The field values move; the integration does not, and finance loses capital spend reconciliation until someone traces the cause, which in our migration work has typically taken two to three weeks.

The energy sequence, 14 to 20 weeks for a large portfolio:

1. Inventory (weeks 1 to 4). Classify every exported project as capital, outage or regulatory; document ERP code mappings, every shift calendar and every system that queried the OData feed.
2. Selection and pilot (weeks 5 to 8). Four tests on real files: multi-baseline retention on a capital project, constraint fidelity on an outage schedule, shift calendar accuracy after import, and a confirmed ERP integration path.
3. Compliance archive (weeks 5 to 8, in parallel). File the NERC CIP and FERC exports now.
4. Wave migration (weeks 9 to 16). Regulatory programs first, outage projects with upcoming windows next, capital projects last because their risk is managed through the archive.
5. ERP handoff (weeks 17 to 20). Finance validates the first reconciliation report from the new data source.

Engineering, EPC and capital projects: dependency fidelity across long cycles

Engineering and EPC firms used Project Online for portfolio governance, not as the scheduling engine. P6 or the Project desktop client held the activities, the resource loading and the field earned value; PWA held the summary schedules imported from P6, the Enterprise Resource Pool, the financial custom fields and the executive dashboards. That is four data layers (schedule, portfolio metadata, resource pool, financial fields), and the fourth is the one most inventories miss.

The defining risk is long-cycle projects that crossed the retirement date. If one still has no home in the new system, create one now from its last export: a full mid-delivery import if it is in early execution, or a static record carrying the last-known baseline and status with manual updates from here if it is in construction or commissioning. That decision belongs to the project owner and the PMO director, not the migration team.

What survives import:

• Dependency types and lag. EPC schedules use Finish-to-Start, Start-to-Start, Finish-to-Finish and Start-to-Finish, with lead and lag on procurement, long-lead equipment and commissioning sequences. A destination that only supports finish-to-start without lag silently rewrites that logic on import; the guide to broken dependencies after a Project Online migration covers the repair.
• Multiple baselines. Engineering PMOs use baselines 0 through 3 (contract, revised, approved change order, current working estimate). Most migration paths keep the active one; where baseline history is an audit requirement, the archived exports are the record.
• ECF formulas (rolled-up percent complete, earned value, cost-to-complete) migrate as their last calculated values, not as logic, and get rebuilt in the destination.
• Resource cost rate tables. Project Online stored up to five time-phased cost rate tables per resource. Most destinations flatten these to the current rate, which breaks earned value for past periods, so check the resource model of the destination against those tables before loading the pool.

Three patterns replace the weekly P6-to-PWA summary refresh: keep P6 as the scheduling system and point the same refresh at the new portfolio tool through .mpp or MSPDI XML import; consolidate the project types where P6 was habit rather than necessity (corporate IT, facility upgrades) into the new tool and keep P6 for true EPC construction; or retire the portfolio layer and rely on P6 reporting, which only works if the Enterprise Resource Pool can be reproduced elsewhere. The ERP cross-reference (an SAP WBS element or Oracle project number in an unremarkable custom field) deserves its own inventory line: the value moves, and a finance team never told keeps querying a feed that no longer exists.

The engineering sequence, three to five months for a 100-project PMO:

1. Inventory. Add four columns: the migrate-live or archive-static decision for every project active at retirement, the P6 refresh process per project, every ECF formula and rate table, and every ERP cross-reference.
2. Selection. A dependency round-trip on a real schedule with all four types and lag, a baseline test on a project with three or more baselines, a rate table test, and an ERP integration path validated with finance.
3. Pilot. One complete project of representative complexity, compared with the export on dependency counts, baseline counts, custom field values and assignments, every gap dispositioned before the next step.
4. Wave migration. Complete projects first, then active projects with near-term completion, then static records for long-running projects.
5. Reconnect P6. Point the refresh at the new tool and validate the first refresh.

Financial services: SOX change control, segregation of duties and the vendor assessment

A financial services PMO adds a vendor risk assessment, a data residency review, a SOX impact analysis, a change control record and a post-cutover segregation-of-duties validation to everything a commercial PMO does, which is why the plan runs 16 to 20 weeks where a commercial migration runs 12. The obligations are unchanged after the retirement date; only the source has changed, from a live tenant to an export set.

SOX Section 404. A PMO managing projects that touch financial systems, regulatory filings or internal audit holds SOX-relevant records. Changing the PM tool is a change-control event with a scope statement, a risk assessment including rollback triggers, test results confirming the data transferred intact, and sign-off from whoever owns internal controls. That record is separate from the migration plan: it proves the right people reviewed the plan and verified the results. Microsoft's SOX compliance documentation describes the SOC 1 Type 2 attestations behind the tenant-side controls.

Structured audit data came out through the OData feed; project documents in the SharePoint libraries attached to PWA needed a separate SharePoint export. Auditors ask for three to seven years of records; the exported records you hold remain valid evidence, and anything never exported cannot be produced.

Segregation of duties (SOD). PWA separated permissions by security category (which projects a user sees) and group (what the user does); modern tools use role-based access. The typical failure: the project manager who creates a project lands in a default role that also approves its status updates and edits its baselines, and the next access review reports a finding. Before go-live, record for each PWA role what it could create, edit and approve, map each to the closest destination role, and take every rule that cannot be maintained to the internal controls team.

Data residency. GDPR, FCA operational resilience guidance and US state privacy laws limit where project data may sit, and resource names and client-facing case references can bring project records into scope. The review answers which regulated data categories appear in the exports, where the destination stores them, and whether the residency control exists in the tier you will license, not only in the enterprise plan the vendor is pitching. A deployment inside your own cloud tenant removes the variable.

The vendor security assessment is the longest single step: structured questionnaires take vendors one to four weeks to answer and infosec two to four more to resolve findings. Send SOC 2 Type II and ISO 27001 evidence first, pre-scope the questionnaire to the data categories that will flow to the PM tool, and hold a gap analysis meeting before the formal exchange.

The financial services sequence, with the change control record built in parallel:

1. Inventory (weeks 1 to 2). Audit trail scope and a data map from the export set, including the SharePoint libraries.
2. Vendor assessment (weeks 3 to 8). Questionnaire, certifications and the pre-assessment gap analysis.
3. Change control (weeks 7 to 10). Change control board (CCB) approval and the SOX record, overlapping the assessment where the CCB cadence allows.
4. Migrate (weeks 11 to 16). Import, reconcile record counts, baseline values and key fields against the export, and document every discrepancy and its resolution.
5. SOD validation (weeks 17 to 18) and go-live (weeks 19 to 20).

If the whole estate cannot go through one change window, split it: active projects first, closed and archived projects as an exported archive reconciled later under a normal window. Auditors accept a documented phased plan; they do not accept missing records.

Healthcare and pharma: HIPAA, 21 CFR Part 11 and the validation track

For a healthcare or pharma PMO, leaving Project Online is a regulated system decommission rather than a tool swap, and the compliance track runs six to eight weeks past the data migration. Three obligations apply: HIPAA where project data touches protected health information, FDA 21 CFR Part 11 where the environment was validated for regulated electronic records, and an audit trail archive that regulators and accreditors can ask for years later.

HIPAA. PHI reaches project data through project notes that describe patient populations, resource assignments that map staff to clinical departments and milestone dates tied to patient-facing events. Access control continuity: document who had access to which projects, verify that access in the replacement matches what was authorized, and have the privacy officer sign the mapping before data moves. A Business Associate Agreement: Microsoft covered Project Online under its HIPAA BAA for qualifying Microsoft 365 customers, per Microsoft's HIPAA compliance documentation, and the replacement vendor has to provide equivalent coverage for the tier you license before any PHI-adjacent data is imported. Audit log retention: the access logs Project Online wrote to SharePoint belong in a HIPAA-compliant archive; seven years is a common retention period for clinical project records.

21 CFR Part 11 and computer system validation. Part 11 applies when the PM tool stores records used as evidence for FDA submissions or inspections: clinical trial timelines, regulatory submission tracking, product development gate records. Decommissioning the validated Project Online environment needs a change control record, a system retirement summary and evidence that data was transferred and archived. The replacement then passes installation qualification (IQ: configuration, access controls and infrastructure to specification), operational qualification (OQ: scripted tests of approval routing, record locking, audit trail capture and electronic signatures where used) and performance qualification (PQ: real workflows run by real team members) before it carries regulated activity. The diagram below shows the two tracks side by side.

The data migration finishes around week 12 and the regulated go-live lands around week 20, so non-regulated project management moves to the new tool at cutover while regulated programs run on interim processes until the Validation Summary Report is signed. Vendor-supplied validation packages (pre-built IQ/OQ protocols and pre-executed test cases) compress the cycle to four to six weeks if your quality unit accepts them under its SOPs.

The audit trail archive. Four categories of Project Online data are the evidence auditors request: status history, approval workflow records (including SharePoint 2013 workflow history), baseline comparison data (baseline start, finish and work against actuals) and resource assignment logs mapping personnel to study phases. Store them in a compliant archive separate from the replacement PM tool, with the migration dossier (inventory scope, export records, BAA, validation summary) alongside your other validation records. Deployment inside your own Azure or AWS tenant removes third-party BAA negotiation and simplifies the IQ.

The healthcare sequence, run as two tracks:

1. Inventory (weeks 1 to 3). Projects, ECFs and resources from the export set, flagging Part 11 scope and PHI-adjacent content.
2. BAA and access map (weeks 1 to 4, compliance track). Signed before any PHI-adjacent import.
3. Archive (weeks 4 to 6). The four evidence categories filed in the compliant archive.
4. IQ (weeks 5 to 8), then OQ and PQ (weeks 9 to 14) against the configured destination.
5. Import and cutover (weeks 7 to 12) for non-regulated go-live, then the Validation Summary Report and regulated go-live (weeks 15 to 20).

Manufacturing: capex baselines, plant turnarounds and NPI phase gates

Manufacturing PMOs ran three distinct project types on Project Online, and a plan that treats them the same fails three ways at once: phase-gate workflows that have stopped running, capex baselines reduced to the current snapshot, and SAP project codes that arrive in the destination while the finance team's ERP query still points at the PWA OData feed.

Capital expenditure projects. Capital project controls query the initial appropriation, the approved budget, the revised estimate at the end of engineering and the current forecast, each a distinct baseline; a mature capex project uses three to five of Project Online's eleven. For public manufacturers under SEC reporting, losing that history is a compliance problem. The archive pattern applies: each historical baseline exported as its own .mpp or MSPDI XML file, filed where auditors can reach it.

Plant turnarounds. A turnaround's start and end dates are fixed by production planning before the schedule exists: the line goes down on day 0 and must be back up by day 21, and every task carries a hard start or finish constraint to hold the window. Turnaround schedules fail at import in the same two places as grid outage schedules: constraint coercion (a Must Start On imported as Start No Earlier Than drifts outside the shutdown window) and shift calendar loss (12-hour, 24-hour or 6-day patterns imported against a 5-day, 8-hour week double task durations). Build the shift calendars in the destination first, import a real turnaround schedule, and verify constraint type and calendar on every task against the export. Schedule the migration work between a completed turnaround and the planning phase of the next one, never inside a shutdown.

New product introduction. NPI follows a phase-gate model (Development, Feasibility, Definition, Implementation, Launch) with an approval at each boundary, and many firms built those gates as SharePoint 2013 workflows inside Project Online. Those workflows stopped on April 2, 2026, and every NPI project that reached a gate since then sat in governance limbo, advancing anyway or stalling. The rebuild is a native governance workflow in the destination tool or a Power Automate flow against its API, either of which takes two to four weeks to design, build and test, and it belongs in the pilot phase.

ERP integration. SAP WBS elements and Oracle project numbers stored as Enterprise Custom Fields move with the field values. ERP integration scripts, Power Automate flows and Power BI reports that read them from the OData feed do not. Document every system that read PWA data and confirm each has a tested path to the new source.

The manufacturing sequence:

1. Inventory. Classify every exported project as capex, turnaround or NPI; document ERP code mappings, every shift calendar, every NPI gate left unresolved since April 2 and every integration that read the OData feed.
2. Selection. Four tests on real data: multi-baseline retention on a capex file, constraint fidelity on a turnaround schedule, native phase-gate governance for NPI, and an ERP integration path the ERP team signs off.
3. Three parallel pilots. One complete capex project, one complete turnaround and one full NPI cycle, with every gap fixed or explicitly accepted.
4. Wave migration. NPI projects first because their governance is already broken, turnarounds with a shutdown window in the next quarter next, capex projects last.
5. ERP handoff. Finance validates the first reconciliation report from the new source before any capital appropriation report is produced.

Nonprofits and NGOs: TechSoup pricing, grant periods and a free tier that holds a schedule

For a nonprofit, the retirement was a procurement conversation before it was a migration. Project Online came inside a Microsoft bundle at zero or near-zero cost through TechSoup and Microsoft's nonprofit donation program; the replacements are standalone products priced per user per month. Three things make the nonprofit case different: subsidized licensing removed any realistic cost baseline, the IT director, PMO lead and COO are often the same person so the migration competes directly with program delivery, and grant funding may not allow the staff time the migration needs.

The Microsoft channel. The closest product in Microsoft's nonprofit channel is Planner Premium, included in Microsoft 365 Business Premium and qualifying nonprofit plans at no additional per-seat charge, and its limits are hard limits: a 3,000-task cap per plan, 10 custom fields per plan, no enterprise resource pool, no multi-baseline support and no .mpp import. Three or four simple task-list projects fit inside that; capital programs, multi-funder grant portfolios and matrix-resourced international programs do not.

What "free" has to mean. Freemium tiers with feature locks stay free, but the question is what is locked: a tier that locks dependencies or file import cannot hold a migrated Project Online schedule at all, while a tier that caps project count keeps the schedule model intact and limits how many run at once. Onplana's Free plan is the second kind: five members, two projects and 300 MB of storage, with the Gantt and critical path, baselines, all four dependency types with lag, milestones, Kanban and calendar views, and .mpp and MSPDI XML import. For three or more simultaneous projects, Starter at $7 per seat per month raises the cap to 25 projects, and resource capacity planning and dashboards start on Pro at $12; the migration cost calculator puts the seat cost at your team size next to the subsidized number you used to pay.

Grant projects. Grant periods fix the deadline, so the tool has to enforce project-level deadlines and track milestone completion against funder deliverables rather than calendar dates. Funders specify report formats, so status data has to export in a form program staff can drop into each funder's template without re-keying. Multi-funder portfolios need project-level tracking of which funder owns which deliverable and which reporting cadence applies. If the enterprise resource pool managed volunteers, consultants or multi-year capacity across projects, verify cross-project resource visibility and which tier carries it.

The nonprofit sequence, kept simple because staff time costs more in lost program capacity than the tool does:

1. Inventory. Half a day for most nonprofits: active projects, the custom fields used for grant tracking and the resource pool definitions, read from the export set.
2. File the grant exports. Any grant project with funder audit requirements keeps its exported schedule history where program staff and auditors can reach it.
3. Select on portfolio size and complexity. One or two active projects with real scheduling: a genuinely free tier. Three or more, or cross-project capacity planning: a paid tier, checked for nonprofit pricing.
4. Pilot two projects. One complex grant project and one simple one; confirm grant milestone dates import correctly and program staff recognize the status output.
5. Wave migration. Completed projects to archive first, then active grant projects, validating grant-period deadlines batch by batch. Most nonprofits finish in eight to ten weeks with existing staff.

What is the same in every industry

Every sector runs the same sequence, and the failures that cross industries are the ones a sector plan still misses:

• The source is the export set. The retirement date applied to every tenant, and Microsoft has not committed to a read-only window, a grace period, or any post-retirement retention. The data extraction window pillar lists what each export format carried.
• The inventory list. Project count, task volume, ECF count, baseline populations, resource pool size, calendars, workflows and every integration that read the OData feed. The 35-item Project Online migration checklist is the generic list; each section above names the columns your sector adds.
• The pilot on a real file. Constraint types, shift calendars, dependency types with lag, baseline counts, custom field values, rate tables: every sector's biggest risk is caught by the same round-trip of the most complex real project through the candidate tool, compared with the export.
• Baselines. Project Online stored up to eleven per project; most destinations keep one, so every capital-intensive or regulated sector needs the archive pattern.
• Integrations. The values in custom fields move; the systems that read them from the OData feed do not.
• Workflows. SharePoint 2013 workflows retired on April 2, 2026, so every gate built on them is a rebuild, not a migration item.
• Wave order. Time-sensitive compliance records first, schedules with fixed windows coming up next, long-running capital projects last.

The broader Project Online migration hub carries the governance framework for the per-project decisions every sector has to make.

Model the replacement cost for your team size The free Migration Cost Calculator estimates what a replacement costs at your seat count, next to what you paid for Project Online. No signup required. → Open the Migration Cost Calculator

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.