Picking the Right Project Online Migration Pilot Project

Here is the pattern. The Project Online migration pilot begins: the team asks for volunteers. A PM raises their hand immediately, happy to help. Their project has 150 tasks, all Finish-to-Start dependencies, no baselines set, no Enterprise Custom Fields, two resources listed without leveling. The import completes in four minutes. Every task appears, every date matches, the critical path renders correctly. The team calls it a success and books the all-hands go-live for six weeks out.

Six weeks later, cutover weekend. The 900-task capital infrastructure programme with SS and FF dependencies, eleven Enterprise Custom Fields, three baselines, and forty resource assignments with leveling constraints hits the import process. Forty percent of the dependency lag values drop to zero. Two baselines collapse into one. Seven of the eleven custom fields arrive as plain text strings. The PM who ran the programme for three years stares at a schedule that no longer resembles the one she spent two days preparing for export. It is Sunday evening. Go-live is Monday morning. There is no rollback path because Project Online is now in read-only mode.

Context: this post is one piece of the Microsoft retirement timeline 2026, the consolidated reference covering all three Microsoft Project ecosystem retirements happening in 2026.

TL;DR: A pilot that only tests simple projects produces false confidence, not validated readiness. Select pilot projects by five criteria: above-median complexity, all four dependency types with lag, live baselines, real resource assignments with leveling, and a willing project owner. Run a systematic side-by-side comparison, not a spot-check. Exit the pilot phase only when the project owner validates their migrated project line by line and agrees to use it as their production system.

Why the Wrong Pilot Is Worse Than No Pilot

Skipping the pilot phase is a documented failure pattern in Project Online migrations. But picking the wrong pilot project produces a failure mode that is harder to recover from: false confidence.

When a team runs no pilot, they know they have not validated. They carry that uncertainty into cutover planning and build larger time buffers, more validation checkpoints, a clearer rollback plan. When a team runs a pilot that succeeds because it was too simple to fail, they carry the opposite into cutover: the certainty that the import process works. That certainty causes them to compress validation time on go-live weekend, assign fewer reviewers, and skip line-by-line verification on complex projects because "we already proved this works."

This is the mechanism behind many cutover failures described in why Project Online migrations fail. The team did not skip validation. They validated the wrong thing and mistook that for validation of everything.

The Microsoft Project Online retirement announcement sets September 30, 2026 as the hard deadline. After that date, the PWA site stops serving pages, the OData endpoint stops responding, and the desktop client's sync connection breaks. That makes the cost of false confidence especially high: there is no recovering from a failed go-live by reverting to Project Online if Project Online is no longer writable.

A correctly selected pilot costs two weeks. A failed cutover caused by inadequate pilot selection costs weeks of remediation, data re-entry, and leadership confidence that is nearly impossible to rebuild. The math is straightforward.

Five Criteria for a Good Project Online Migration Pilot

Pilot project selection is not about finding a project that will succeed. It is about finding a project that will expose failures while fixing them is still cheap. Each criterion below targets a specific class of import risk.

Criterion 1: Above-median schedule complexity. Count the tasks across your active portfolio and sort it. Select a pilot project in the top quartile by task count, not the median and certainly not the bottom. A 150-task project with straightforward structure does not stress the importer. A 600-task project with summary tasks, sub-projects, recurring tasks, and milestone chains does. If import fidelity breaks anywhere, it will break on a complex schedule first.

Criterion 2: All four dependency types with lag values. Project Online supports Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish dependencies, each with optional lag or lead. Most destination tools support FS cleanly. SS, FF, and SF with lag are the primary risk surface. Your pilot must include a project that exercises all four types with non-zero lag values. If no single active project covers all four, select the project with the most non-FS dependencies and supplement with a second project that covers the remainder. Run Migration Preview on the candidate file first to see exactly which dependency types and lag values survive the round-trip before committing to the pilot phase.

Criterion 3: Live, named baselines. Project Online allows up to eleven baselines per project. Baselines that track against approved scope changes or variance-reporting cycles carry date, work, and cost snapshots that many importers collapse, merge, or silently drop. Select a pilot project with at least two named baselines set against different points in the project lifecycle, ideally one from original approval and one from a scope change. If all your active projects have zero baselines set, that is itself a finding: your portfolio has no variance tracking, and the migration will not expose baseline fidelity as a risk.

Criterion 4: Real resource assignments with leveling. Placeholder resource assignments (a single generic resource assigned to all tasks) do not test the resource import. Select a project with named, individual resources from the Enterprise Resource Pool, actual assignment units, and at minimum one instance where resource leveling has been applied to resolve an overallocation. The resource heatmap can help you identify which pilot candidates carry the most meaningful assignment data before you select. After import, verify that leveling constraints survived and that over-allocations the original PM resolved have not reappeared.

Criterion 5: A willing project owner who will do real validation. The PM on the pilot project must agree to two things before the pilot starts. First, they will spend real time validating the migrated project against the Project Online source, not a five-minute spot-check but a systematic line-by-line review. Second, if the pilot passes, they will use the new tool as their production system for the remainder of their project, not continue updating the original in Project Online as a safety net. A pilot where the PM validates loosely and then keeps using Project Online is not a pilot. It is a demo.

Anti-Criteria: What Makes a Bad Pilot

It is worth naming the patterns that produce bad pilot selections, because each one looks reasonable at the surface.

Too simple. The most common mistake. If the project imports without errors and validates in twenty minutes, it did not test the import process. It tested that the importer works on trivially simple data. Every significant tool on the market can import a 150-task all-FS schedule with no baselines and no custom fields. That test eliminates nothing.

Politically sensitive. Some PMs will volunteer because they want visibility, or because their project is the flagship initiative the executive team watches. Avoid these. When the pilot finds problems, and a well-selected pilot will find problems, the team needs space to investigate and fix without an audience. A high-visibility project creates pressure to declare success regardless of what the data shows.

No Enterprise Custom Fields. If your portfolio uses ECFs for project categorisation, budget codes, reporting flags, or approval workflows, the pilot must include a project that uses them. ECFs that silently coerce from lookup tables to plain text strings, or from numeric types to strings, will corrupt portfolio-level reporting when the full portfolio is migrated. A pilot with no ECFs teaches you nothing about this risk.

No resource leveling history. A project where the PM clicked "Level Resources" once and it resolved nothing meaningful does not test resource fidelity. Look for a project where leveling made substantive changes: tasks that shifted dates, splits that were introduced, over-allocations that were resolved. Those are the assignments that expose import gaps.

A conscripted PM. The pilot PM who agreed to participate because their manager volunteered them will do the minimum validation required to exit the phase. They will spot-check ten tasks, say it looks right, and move on. The pilot then exits on insufficient evidence, carrying the same false-confidence risk as an easy project. Participation must be genuinely voluntary, and the PM must understand what they are signing up to do.

Structuring the Two-Week Pilot Phase

Two weeks is the right length for a pilot phase that produces usable evidence. Less than two weeks compresses the validation work into a single push and produces incomplete results. More than two weeks usually means the team is doing something other than systematic validation.

Week 1: Import and initial inspection.

Start with a pre-export remediation pass on each pilot project. The Project Online migration checklist covers the items to address before export: orphaned tasks, missing resource assignments, dependency cycles, and ECF values that need cleanup before they travel. Export each project to .mpp format from Project Online and run it through Migration Preview to get a pre-import fidelity report. The report flags dependency type support, baseline preservation, and custom field fidelity before you start the live import.

Import each pilot project into the destination tool. Do not adjust or fix data in the destination after import. If the import requires manual correction to make the schedule look right, that correction is itself a finding: every project in the portfolio will need the same correction, and some portion of the portfolio will not be corrected before cutover.

Document the import results for each project: task count (source vs. destination), dependency count by type, baseline count, custom field values spot-checked across ten representative tasks. This is not the full validation; it is the triage pass to identify where the detailed validation in week two should focus.

Week 2: Systematic validation and exit decision.

The PM for each pilot project conducts a structured comparison of the migrated project against the Project Online source. "Structured" means a checklist, not a visual scan. The checklist covers: every summary task, a 20% random sample of leaf tasks (dates, work, units), every dependency type with lag, every named baseline (task-level date, work, and cost for a 10% sample), every ECF value for a 20% sample of tasks, and the resource assignment list with leveling applied.

At the end of week two, the migration team and the pilot PMs meet to review findings. Findings fall into three categories: resolved (configuration change fixed the issue), accepted risk (known gap with a workaround), and blocking (the problem cannot be resolved without changing the tool or the data). Only when there are no blocking findings, and every pilot PM signs off on their project and agrees to use the new tool as their production system, does the pilot phase exit.

What "Validated" Actually Means

Validation is not "it looks right." It is a systematic comparison that produces a documented record of what was checked, what matched, and what did not.

The benchmark is straightforward. For each pilot project, the PM exports a task-level report from Project Online (task name, start, finish, work, resources, predecessor ID, predecessor type, predecessor lag) and runs the same report in the destination tool. They compare the two outputs row by row. Discrepancies are logged: what the source showed, what the destination shows, and whether the gap is acceptable.

For baselines, the comparison runs the same way. Each named baseline in Project Online carries task-level baseline start, baseline finish, and baseline work. The PM exports those values from Project Online before migration and compares them against the destination after import. A baseline that collapsed from three named snapshots to one unnamed snapshot is not a match.

For ECFs, the comparison is a value check, not a field-name check. A field that migrated with the right name but the wrong type (lookup value became free text) has lost fidelity. The PM checks values against a sample drawn before migration.

Visual inspection will miss all of these. The schedule can render correctly, the Gantt can look identical, and the dates can match, while the dependency lag values are zero, the baselines are collapsed, and the ECF types are wrong. Systematic comparison is the only method that catches the gaps that matter.

When the Pilot Finds Problems

A well-selected pilot will find problems. That is the point. What matters is how the team responds.

Configuration issues are problems that exist in the destination tool's setup, not its capabilities. Field mappings that are wrong, import settings that were not configured correctly, custom field definitions that were not pre-created before import. These are fixable. The response is to correct the configuration, delete the imported project, re-import from the original .mpp, and re-validate. Do not patch the destination data and call it good. If the configuration was wrong on the first import, it will be wrong on every subsequent import until it is fixed.

Tool limitations are problems that reflect what the destination tool actually supports. If the tool only supports FS dependencies and silently coerces SS and FF to FS on import, that is a tool limitation, not a configuration issue. No configuration change will fix it. The response has three options: accept the workaround if the impact on the portfolio is small, switch tools if the impact is large, or pre-process the affected projects before export to convert non-FS dependencies to FS-with-appropriate-lag equivalents. None of these options are free. Quantify the portfolio impact before deciding.

The quantification step matters. If five of your four hundred active projects use SS dependencies, accepting the workaround may be reasonable. If eighty projects use SS and FF dependencies, which is typical for large capital programmes, a tool that drops them silently is not a viable destination. The pilot's job is to surface that finding while there is still time to change direction.

Whatever the finding, document it in writing before exiting the pilot phase. The written record justifies the exit decision to the project sponsor and guides remediation work on the remaining portfolio. An undocumented finding that was "handled" verbally will resurface on cutover weekend when the person who handled it is not in the room.

Exit Criteria and Moving to Phase 4

The pilot phase has two exit conditions, both required.

First: every pilot project owner completes the systematic validation checklist and signs off that the migrated project matches the Project Online source within agreed tolerances. Those tolerances must be documented before validation starts, not adjusted after, because post-hoc tolerance-setting creates incentive to match the bar to the results rather than the reverse.

Second: every pilot project owner confirms they will use the new tool as their production system from pilot exit forward. They close out their Project Online copy and do not maintain a parallel update as insurance. This confirmation is the real test of whether the new tool is actually usable day-to-day, not just importable.

When both conditions are met across all pilot projects, the team has real evidence: specific projects with specific complexity profiles were imported, validated systematically, and adopted in production. That evidence transfers to the full portfolio cutover in a way that "the demo looked good" does not.

If either condition is not met, the pilot phase does not exit. It extends until the blocking findings are resolved or the team makes a documented decision to accept them and proceed. Rushing through exit criteria to stay on schedule is how false confidence gets manufactured a second time.

---

Check import fidelity before your pilot phase The free Migration Preview round-trips your .mpp file through the import process and flags dependency-type support, baseline preservation, and custom field fidelity before you start Phase 3. Open Migration Preview

The comparison diagram below summarises the five criteria for good and bad pilot project selection. Use it as a quick-reference when evaluating candidates from your portfolio.

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