What is parallel running in a Project Online migration?

Parallel running is the period after migration begins when both Project Online and the new PM tool contain live project data and PMs work in both systems simultaneously. It ends when the new tool is validated as the single system of record.

How long should parallel running last for a typical PMO?

For a PMO with 5 to 20 active projects, 1 to 2 weeks is usually sufficient. For 50 to 100 projects, 3 to 4 weeks. For PMOs with 200 or more projects, a wave-based approach is recommended where each wave has its own parallel-running window rather than running the entire portfolio simultaneously.

What are the exit criteria for ending parallel running?

Parallel running can end when all migrated projects have been validated by their PMs, all critical reports are live on the new data source, no open data-fidelity blockers exist, and at least 80 percent of regular users have logged into and used the new tool.

What is the biggest risk of parallel running too long?

Data divergence: PMs update schedules in both systems differently, creating two conflicting versions of reality. The longer parallel running continues, the harder it is to determine which system is authoritative, and the more painful the eventual clean-up.

Can we compress parallel running to reduce cost?

Yes, but only if your validation checklist is complete before compression. The minimum viable parallel-running window is the time needed to validate all active projects and confirm all critical reports are live. Compressing below that minimum produces a higher-risk cut-over.

What does parallel running cost in absolute terms?

Roughly two to four weeks of dual license fees plus the PM productivity cost of double-entry. For a 100-person PMO organization at typical license rates, two weeks of parallel running costs $15,000 to $40,000 in direct license costs alone, not counting the productivity drag.

When should parallel running start relative to the September 30, 2026 deadline?

Parallel running should ideally start no later than August 1, 2026, giving you until September 1 to complete validation with a 30-day buffer before the retirement date. Starting parallel running after September 1 leaves no room to resolve unexpected blockers.

Project Online Parallel Running: How Long Is Long Enough?

Two to four weeks. That's the answer every migration consultant gives when a PMO asks how long Project Online parallel running should last alongside the new tool. It's also wrong for most PMOs.

For a team managing 15 active projects, two to four weeks is too long: you're paying for two tools, managing dual reporting workflows, and breeding PM frustration that erodes adoption before the new system has a chance to establish itself. For a PMO running 200 projects with a complex enterprise resource pool, 30 Power BI reports, and six integrations with downstream systems, four weeks is not nearly long enough to validate everything before declaring cut-over complete.

The parallel-running window is not a comfort period. It is a validation window. The window exists to prove that the new tool is production-ready before you decommission the old one. Getting the length right matters: too short and you cut over before catching data-fidelity problems; too long and you're paying double costs while PM confidence in the migration erodes.

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

The framework: Parallel running duration is driven by how long your validation checklist actually takes to complete, not by a standard calendar window. For 5 to 20 projects with simple resource loading and no critical integrations, 1 to 2 weeks is usually enough. For 50 to 100 projects, 3 to 4 weeks. For 200 or more projects, use waves: each wave has its own parallel-running window, and the full-portfolio validation is staggered across several cut-over events rather than compressing everything into one window. The window ends when specific exit criteria are met, not when the calendar says so.

What parallel running actually is (and what it is not)

Parallel running is the period when both Project Online and the new PM tool contain live project data and PMs are actively working in both systems. The purpose is validation, not comfort: you keep Project Online alive not because you aren't ready to commit, but because you need a fallback if the new system surfaces an unexpected problem before PMs have fully transitioned.

What parallel running is not: a grace period where PMs can choose which system to use. That framing produces the worst outcome. Some PMs update in the new tool, some in the old one, and within a week the two systems have diverged enough that neither is a reliable source of truth. Parallel running requires discipline: the new tool is the system of record for all new updates from the moment it goes live, and Project Online is read-only for fallback and validation reference.

It is also not a training period. Training happens before parallel running starts. PMs who haven't been trained on the new tool should not be updating projects in either system during the parallel-running window; that is a change-management failure that extends the window and introduces data errors.

Why the standard 2-4 week answer misleads

The 2 to 4 week answer comes from migration consultants who work primarily with mid-market PMOs running 30 to 80 projects with clean data and no complex integrations. That is a real use case and the answer is reasonable for it.

The answer breaks for PMOs at either end of the scale. A small PMO with 10 projects and no downstream integrations can validate in three to five business days. Requiring them to run in parallel for two weeks is a cost and morale burden with no corresponding benefit. A large enterprise PMO running 300 projects with custom ECF reporting, OData-fed Power BI dashboards, SAP integration for resource cost actuals, and a timesheet approval workflow embedded in Power Automate cannot meaningfully validate all of that in four weeks, especially if the cut-over date is a Friday before a bank holiday weekend.

The correct question is not "how long is the standard parallel-running window?" but "how long does my specific validation checklist take to work through?"

The four factors that determine how long your parallel running needs to be

Project count and complexity. Validation means a PM opens each migrated project in the new tool, confirms the schedule data is correct, and signs off. At 30 minutes per project (a reasonable estimate for a well-prepared migration), 100 projects requires 50 person-hours of validation work. At 200 projects, that's 100 hours. Validation can run in parallel across multiple PMs, but it is bounded by the number of PMs available and their day-job obligations during the migration period.

Report dependency. Every report that an executive or decision-maker depends on needs to be live on the new data source before parallel running can end. If you have 12 Power BI reports that need new connectors and validated semantic models, and you've been running two report rebuilds per week, you need six weeks of report-rebuild work behind you before parallel running starts. Parallel running does not create time to rebuild reports; that work must be done in advance.

Integration complexity. Integrations with downstream systems (SAP, Workday, custom .NET applications, Power Automate flows) need testing under live conditions. Each integration has a verification step: does data flow correctly through the new connector? Does the downstream system receive the right shape of data? These tests run during parallel running and each failed test extends the window.

User adoption baseline. Parallel running should end when at least 80 percent of active users have logged in and completed at least one meaningful workflow in the new tool. If adoption is below that threshold, cut-over will surface resistance that could have been addressed during parallel running. Measuring adoption weekly gives you early warning if training wasn't effective.

Sizing guidance by PMO scale

The diagram below shows how parallel-running windows scale with project count, assuming a prepared migration with validation checklists built before the window opens.

Small PMO (5 to 20 projects): One to two weeks of parallel running, often ending earlier. At this scale, one person can personally validate every project in two to three business days. The main reason to hold the window open past validation-complete is to let users log in and confirm they know how to use the new tool for their day-to-day work.

Mid PMO (50 to 100 projects): Three to four weeks. This scale has enough projects that a single validator can't cover everything; assign one validator per five to ten projects, run validations in parallel, and track completion in a shared spreadsheet. The window extends to four weeks when reports aren't fully rebuilt before the window opens, which is the avoidable error to prevent.

Large PMO (200+ projects): Wave-based approach. Trying to run the entire portfolio in parallel simultaneously produces a sprawling, unmanageable validation effort. Instead: cut over in waves of 30 to 60 projects. Each wave has its own mini parallel-running window of two to three weeks. Active projects with upcoming milestone deliveries go in the first wave; lower-priority projects and archived work go in later waves. The Project Online retirement deadline on September 30, 2026 is the forcing function: your wave schedule must complete all cuts before that date.

What has to be true before parallel running can end

Parallel running ends when you have affirmative confirmation of these five conditions, not just the assumption they're met:

PM validation complete: Every active migrated project has been opened and signed off by its PM in the new tool. Signoff means the PM confirms schedules, resources, dependencies, and baselines look correct, not just that the project loaded.
Critical reports live: Every report in your Tier 1 rebuild bucket is live on the new data source and has been validated against the old source for the same period. No critical report should be on a "rebuild later" timeline that extends past parallel-running end.
Integrations verified: Every downstream integration has been tested end-to-end with live data from the new tool. Automated verification is better than manual; build a test that runs the integration and confirms the output shape.
No open data-fidelity blockers: Any data-fidelity gap discovered during validation, a missing baseline, a dependency that didn't survive import, a custom field that came in as an empty string, must be resolved or explicitly accepted. "We'll fix it later" on a data-fidelity item is how stale data accumulates in the new system indefinitely.
Adoption threshold met: At least 80 percent of regular users have logged in and completed a meaningful workflow. Measure this with the new tool's user activity report; don't rely on training-completion records as a proxy.

Managing double-entry fatigue during the window

The biggest morale risk during parallel running is PM fatigue from updating two systems. Every update a PM makes in Project Online must be replicated in the new tool, or vice versa, depending on which is the system of record. Even a two-week window feels long when PMs are tired from training, adjusting to a new interface, and managing their actual projects.

Reduce double-entry by making the new tool the system of record from day one of parallel running, and using Project Online only as a read-only reference. PMs make all new entries in the new tool. Validators read from Project Online to compare; they don't write to it. This approach means only one active entry stream, not two, and it builds PM confidence in the new system faster.

Identify and support a cohort of five to ten power users in the first week of parallel running. These are the PMs who got early access during the pilot phase and are comfortable with the new tool. Route validation questions to them, not to the migration team. This takes load off the team and creates peer-support channels that persist after the migration is over.

The cost of running in parallel too long

Every week of parallel running has a direct cost: dual license fees plus PM productivity drag from operating two systems. For a 100-person PMO organization using typical license tiers, two weeks of parallel running costs between $15,000 and $40,000 in license fees alone. That is the best case. If parallel running extends to six weeks because validation wasn't ready when it started, the cost is $45,000 to $120,000, plus the organizational cost of migration fatigue: PMs check out of the process, informal workarounds calcify into permanent habits, and the final cut-over becomes a confrontation rather than a planned event.

The cure is preparation: the Project Online Inventory Checklist helps ensure you know exactly what needs to be validated before parallel running starts, and the 90-day migration plan shows where parallel running fits in the overall timeline relative to data migration, report rebuilding, and training. The migration preview tool lets you upload a sample .mpp file and see which data elements survive the tool boundary before you're in the parallel-running window and discovering problems under live conditions.

Per Microsoft's retirement announcement, Project Online service availability ends September 30, 2026. Starting parallel running on August 1 gives you a maximum of 60 days before the deadline, with a natural exit point around September 1 that preserves 30 days of buffer for unexpected validation issues. Starting later narrows that buffer to zero.

Run the free Migration Preview Upload a sample .mpp file and see which data elements survive the tool boundary before you enter parallel running. No signup required. → Open Migration Preview

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