Why is 12 weeks the right migration window?

Calibrated for a 50–500-project PMO. Smaller orgs can compress to 6 weeks by collapsing Phases 1–2 (Inventory, Evaluate); larger PMOs (1,000+ projects, multiple OData feeds, custom Project Web App workflows) typically extend Phase 3 (Pilot) by 2 weeks for additional UAT cycles. Below 50 projects, a single PM can run the whole thing in two weeks; above 1,000, expect 16.

What's the most common Project Online migration failure?

Skipping Phase 3 (Pilot). Teams jump from Evaluate straight to Cutover, find data-fidelity gaps on go-live weekend (custom field types, dependency lag, baseline shadows), and have no rollback path. The pilot phase exists to surface those gaps in a 2-week window where you can still fix them or change tools.

What are the six go/no-go criteria for a Project Online cutover?

Export verified, schedule math matches, permissions mapped, reporting rebuilt, support staffed, and rollback still possible. Each is scored pass, amber, or fail against a threshold written before the meeting; two ambers can still be a go, but one fail on export or rollback never is.

How long should parallel running last?

As long as your validation checklist takes, not a standard calendar window: 1 to 2 weeks for 5 to 20 projects, 3 to 4 weeks for 50 to 100, and staggered waves of 2 to 3 weeks each above 200 projects. It ends when every active project is signed off by its PM, the critical reports are live, integrations are verified, no data-fidelity blocker is open, and at least 80 percent of regular users have completed a real workflow in the new tool.

When should training start for a Project Online migration?

Four weeks before the main portfolio cutover at minimum, with a power-user cohort of five to ten PMs using the new tool as their daily driver from the pilot phase, roughly eight weeks out. A one-hour overview on the Monday of go-live week is a handover note, not training.

How long does procurement take if we need a formal RFP?

Plan for 14 to 20 weeks from requirements to signed contract for a mid-market PMO, and run it in front of the 12-week plan rather than inside Phase 2. Legal review of a SaaS enterprise agreement typically takes four to eight weeks and IT security usually has a two-to-four-week intake queue, and neither is under the PMO's control.

What should I do first if I am starting after the retirement date?

Inventory the export set you hold: the .mpp files and the OData pull taken before September 30, 2026 are now the estate. Pick a destination in parallel, import the active portfolio first, and rebuild reporting last, because a dashboard can be rebuilt next month and unexported data cannot.

Project Online Retirement: A 90-Day Migration Plan

Q: When exactly did Microsoft Project Online retire?

September 30, 2026. Anything that read it live, including PWA, the OData feed, and timesheet workflows, stopped with it; anything already exported or imported did not. Microsoft had not committed to a read-only window, a grace period, or any post-retirement retention, so treat it as the last day the data was reachable. A team that has not finished migrating works from its export set: migrate the active portfolio first.

Microsoft Project Online retired on September 30, 2026, the third event in Microsoft's 2026 retirement timeline. That sentence was repeated so often that it lost its bite, but the calendar didn't care. By the time you read this, every PMO that was still on Project Online has run out of runway: the move is either in progress, or it starts now, from exported files.

The internet has plenty of "what to know" pieces (including our own retirement timeline and the complete Project Online migration guide). The plan below is the operational counterpart: 12 weeks, six phases, an explicit exit criterion for each gate, and the one failure mode that catches most teams, with procurement, the RFP template, communications, training, the go/no-go scorecard and parallel running each placed in the phase where it is used.

If your migration hasn't started yet, today is week one. If week one begins after the retirement date, with an export set rather than a live tenant, read the compressed plan at the end first: the phases below still apply, but the scope does not.

The 30-Second Summary

12 weeks, six phases: Inventory → Evaluate → Pilot → Prep → Cutover → Stabilise.
Don't skip Phase 3. A 2-week pilot on 3–5 representative projects is the difference between a clean go-live and a hypercare nightmare.
Sep 30, 2026 was the final cutover. There was no committed read-only window after it, so anything not exported by then should be treated as gone.
Cost ramps non-linearly the later you start. A planned migration ran ~3× cheaper than a panic-cutover in the final weeks, and a rebuild from exports after the date costs more again.
Exit criteria, not dates. Every phase has a gate. If the gate doesn't clear, don't move on.
Start with the estate, not the tool. Count your projects, custom fields, and resources before Week 1 starts. Project Online Data: Import What You Exported covers how to size the estate from the files you exported.
One document, end to end. Communications in Phase 1, procurement and the RFP template in Phase 2, training in Phase 4, go/no-go and parallel running in Phase 5, a compressed path for late starts at the end.

The Phase Gate Discipline

Every phase in this plan has a written exit criterion at its top. A gate that does not clear does not advance, regardless of which calendar week the team is in. That is the discipline that separates a 12-week migration from a 12-week plan that takes 20.

The shorthand is the Phase Gate Discipline: six gates, six exits, no exceptions. If the inventory is not complete, evaluation does not start. If the pilot has open data-fidelity gaps, cutover prep does not start. If the validation team has not signed off, go-live is rolled. The temptation to "start prep in parallel while we close out pilot" is exactly the pattern that produces the Pilot-skip failure mode on go-live weekend. It looks like progress and it is technical debt.

Steering committees that adopt this discipline have a simpler reporting model: every week, the status is the current phase, the exit criteria, and the gate's binary state (cleared / not cleared). That single sentence beats a Gantt-chart status update because it surfaces blockers in a form that demands a decision.

Why the Timing Matters More Than the Tool

Most posts focus on which tool to migrate to. That's the wrong starting question. The harder question, the one that determines whether the project succeeds, is when you migrate, not what you migrate to.

Two things rose non-linearly as the deadline approached, and both keep rising after it:

Risk, vendor support windows tighten, consultants get booked, and your own team's stress levels reduce decision quality. A migration scheduled for July was fundamentally different from the same migration scheduled for September.
Cost, by Q3 2026 every PMO consultant in the region was double-booked, day rates rose, and integration vendors pushed back on bookings. Hypercare overtime stacks on top.

Past Sep 30, you are in the danger zone. Microsoft had not committed to a read-only window, a grace period, or any post-retirement retention, so whatever was not exported is not something to plan on recovering. Teams that arrive past the deadline are not paying twice; they are rebuilding from whatever they exported.

The sweet spot was migrating to a usable state with two months of buffer for hypercare, training, and the inevitable surprises, which meant starting the 12-week clock in the spring. If that window has closed for you, the phases below still apply; the scope does not. Migrate the active portfolio on the plan, keep the exported archived portfolio in read-only storage, and treat the compressed plan near the end as the main path rather than the fallback.

Phase 1, Inventory (Weeks 1–2)

Exit criteria: documented project list, integration map, user roster, and a quantified data-volume estimate.

You can't plan what you don't measure. Most PMOs underestimate their Project Online footprint by 30–50%, usually because nobody has counted the orphan projects, the OData feeds wired to Power BI, or the SharePoint document libraries linked to Project Web App. The free Project Online Inventory Checklist walks the 35 items most tenants miss in this phase, with notes/owners per item and a PDF export for the steering committee.

Week 1 checklist

Pull the full project list from Project Online (active + archived). Tag each project with status, owner, last-modified date, and approximate task count. For projects you have already exported, the free Migration Preview reads each .mpp or Project XML file and reports its tasks, dependencies and custom fields.
Identify all OData consumers, Power BI dashboards, custom .NET reports, Excel data connections. Match each one to the OData snapshot in your export set: the OData export walkthrough covers the endpoints and the paging.
Map every integration: timesheet system, financials, identity provider, document libraries, Power Automate flows.
Roster every Project Online user, by role, by license tier, by time-zone.

Week 2 checklist

Categorise projects: active (will migrate), archived (will export to read-only storage), retire (won't migrate at all).
Document custom fields. Project Online's "Enterprise Custom Fields" with calculated formulas and lookup tables are the most common migration trip-wire, and the field-by-field migration guide sets out which types survive a move and which have to be rebuilt.
Measure data volume, total tasks, total assignments, total custom-field values. This drives the import-tool selection in Phase 2.
Confirm sponsor + executive owner. The migration is going to surface organizational debt; have someone authorised to make decisions when it does.

Don't skip: the integration map. Migrations fail more often because of an unknown OData consumer than because of the project data itself.

Sidebar: the communication plan, written in week 1

A migration communication plan is a written document with six named audiences, a cadence tied to cutover, and message templates ready to send, drafted in inventory week and owned by one named person who is not also running the technical migration. Without one, a heads-down team goes quiet, silence reads as trouble, and sponsors start asking through informal channels.

Audience	What they need to hear	Cadence
Sponsors	Schedule status, top risks, decisions needed; one page	Biweekly from week 2; daily in week one after go-live
Project managers	Kickoff expectations, pilot membership, their own cutover date and validation checklist four weeks out	Project-specific notes every three to four weeks
Resource managers	How resources and calendars will be represented; the post-go-live approval workflow	A conversation in week 1, then pilot exit and cutover
Finance	Last day of Project Online billing, first day of new-tool billing, the overlap during parallel running	Week 1, cutover, licence stop
IT	The integration inventory (Power BI, OData, Power Automate, SharePoint) with runway to rebuild it	Kickoff, midpoint, cutover-prep two weeks out
End users	What changes for them, how to get in, who to ask; from the PMO director, not IT	Three weeks out at the latest (six with training), plus a one-week reminder

Write the five messages in week 1 with bracketed fields.

Message	Sent	Primary audience
Kickoff announcement	Week 1 (T-minus roughly 10-12 weeks)	Sponsors, PMs, resource managers, finance, IT
Two-week reminder	T-minus 2 weeks	All six audiences
Freeze notice	T-minus 1 week (start of change freeze)	PMs, end users
Go-live note	T-0, cutover day	All six audiences
Post-cutover survey	T-plus 1 to 2 weeks	PMs, end users

For a team working from exported files the freeze notice has already been sent, by Microsoft: the export set is the frozen state, and the message becomes "any change made since the export must be re-entered in the new tool". Bad news delivered early with a mitigation plan preserves trust; the same news reaching a sponsor from someone else destroys it. When something breaks, the message has four parts, in order: the impact first, not the cause ("the capacity view for the Northeast portfolio shows wrong allocations for 12 projects"); what is being done, concretely; a specific time for the next update, even if it is "no fix yet"; and a named person for anything urgent.

Phase 2, Evaluate (Weeks 3–4)

Exit criteria: shortlisted tool, data-fidelity spike completed against your real export, security/compliance sign-off.

Two weeks. No more. Many PMOs get stuck here for months running parallel evaluations on tools that fundamentally don't fit. Get to a shortlist of three by end of week 3.

Week 3, Shortlist

Use the alternatives roundup as a starting filter, or, if there is no budget yet, the free Project Online replacement options. Apply your hard requirements:

Does it support all four dependency types (FS/SS/FF/SF) with lag? Most "modern" tools don't, they only do FS without lag.
Does it ingest .mpp files natively or via XML? Direct .mpp parse is rare; XML is universal.
Does it support baselines and critical-path analysis?
Does it offer SSO + SCIM at the tier you need?
Does it match your data-residency requirements?

If a tool fails any hard requirement, it's out. Keep three.

Week 4, Data-fidelity spike

Pick three real, complex projects from your inventory. Export them. Import them into each shortlisted tool. Compare against the original side-by-side.

What you're testing: not whether the tool can import .mpp, but whether your projects round-trip with their critical path intact, dependency lag preserved, baselines surviving, and custom field types mapping correctly. This is the moment that disqualifies tools, and it's much cheaper to find out in week 4 than in week 11.

Don't skip: the security review. Your security team will ask for SOC 2 docs: SSO configuration, audit-log capability, and data-retention policies. Get those answers documented before you commit. (Onplana publishes a full security & compliance overview for exactly this reason.)

Don't skip the budget either. End of week 4 is when finance starts asking for a 3-year number. Run the inventory you built in Phase 1 through the free Migration Cost Calculator: it produces low/mid/high scenarios across the six cost categories (license delta, data-migration labor, training, parallel operation, integration rework, cleanup) and exports a CFO-ready PDF. Defensible numbers beat round numbers when the steering committee asks. Pair the calculator output with the playbook for defending the migration budget to a CFO: the numbers tell the story, the framing keeps the meeting from getting derailed by "did we look at cheaper options" questions in the first ten minutes.

If your company requires a formal procurement: the five-phase timeline

Two weeks is the evaluate phase for a PMO that can trial a tool without a purchasing cycle. A mid-market company (50-500 users) that needs an RFP, an IT security review and a negotiated contract is running a 14-to-20-week procurement program that sits in front of the 12-week plan, not inside Phase 2, with two of its five phases outside the PMO's control.

Requirements (weeks 1-2). Functional requirements from the Phase 1 inventory; every integration that consumes Project Online data (the most common late disqualifier); a 3-year TCO rather than a per-seat price (Microsoft Project Online Plan 3 lists at $30 per user per month; the migration budget template has the line items); the compliance baseline (data residency, SOC 2 Type II, ISO 27001, FedRAMP); and measurable success criteria.
Longlist and shortlist (weeks 3-4). Eight to twelve names scored meets / partially / does not meet, disqualified on integration or security first, cut to three to five: fewer leaves legal nothing to negotiate against, more stretches demos across weeks you do not have. Submit your top two to IT security intake now.
RFP and demos (weeks 5-8). The template below is the document. Run every demo in the same two-week window on the same .mpp file you provide, score independently, and hand the leading vendor's standard agreement to legal in week 8.
IT security review (weeks 9-12). A two-to-four-week intake queue precedes the review, which needs a completed CAIQ or equivalent, a current SOC 2 Type II or ISO 27001 report, a penetration test summary, the DPA and the subprocessor list; a missing item restarts the clock.
Contract close (weeks 13-16+). Legal review of a SaaS enterprise agreement typically takes four to eight weeks; plan for four rounds of redlines.

Compress by overlapping, not shortening: security intake during the shortlist, a legal pre-brief during demos, completed security documentation as a condition of the demo. Name an owner per phase (the PMO for 1 to 3, IT security for 4, legal for 5), and after the retirement date run the trial import from your export set while legal works.

The Project Online RFP template: weights, then the copy-ready text

Every vendor answers yes to a yes/no checklist: "dependencies" can mean FS only without lag, "baselines" can mean flat date copies rather than phantom bars, and ".mpp import" can turn typed custom fields into text. Ask for evidence instead: upload this file and show us the lag values. Score each vendor 0–5 per section, multiply by the weight and sum; the highest score advances to a live demo on your most complex schedule, and a vendor who declines the demo on your file is disqualified. (The general PM tool RFP template serves a buyer who is not leaving Project Online.)

Category	Weight	Scoring method
Functional requirements	40%	0–5 scale per criterion, averaged
Data migration fidelity	20%	Pass/fail on live demo items, then 0–5
Security and deployment	20%	Certification evidence required
AI features	10%	0–5 per criterion, demo required
Commercial and pricing	10%	TCO model, scenarios required
Total	100%	Weighted score 0–5

Commercial terms stay at 10% because a price win with a fidelity loss costs more in schedule re-entry than the licence saving. SOC 2 Type II (within 12 months; Type I is not equivalent), specifiable data residency and SSO/SCIM are pass/fail minimums; AI is a tiebreaker, demonstrated on your schedule with its reasoning shown. Copy the following into your RFP and adapt the specifics.

SECTION A: FUNCTIONAL REQUIREMENTS

Respond to each item with: (a) current availability (GA/Beta/Roadmap/Not planned), (b) brief description of implementation, and (c) link to documentation or demo.

Dependency type support
- 1a. List all supported dependency types (FS, SS, FF, SF)
- 1b. Confirm whether lag and lead values are preserved on .mpp import. Provide a demonstration on the buyer-provided sample file.
- 1c. Describe how the tool recalculates the critical path after a dependency change.
Baseline management
- 2a. Describe how baselines are stored. Are they accessible as historical Gantt overlays or only as date metadata?
- 2b. How many baselines per project are supported?
- 2c. On .mpp import, are existing baselines preserved as historical records or collapsed?
Enterprise custom field fidelity
- 3a. List all supported ECF types (cost, duration, flag, number, text, date, etc.)
- 3b. On import from Project Online, are typed ECFs preserved with their original type, or coerced to text?
- 3c. Describe how lookup tables attached to ECFs are handled on import.
File format support
- 4a. Confirm .mpp import support. Specify the most recent .mpp format version tested.
- 4b. Confirm MSPDI XML import support.
- 4c. Provide a round-trip fidelity report on the buyer-provided sample file.

SECTION B: DATA MIGRATION

Live demo requirement
- 1a. Acknowledge that the evaluation demo will be conducted on a sample .mpp file provided by the buyer, not vendor sample data.
- 1b. Describe your migration process from first export to validated production load.
- 1c. What is your SLA for resolving fidelity defects discovered post-migration?
Archive migration
- 2a. How are closed/archived projects handled? Are they migrated differently from active projects?
- 2b. What is your estimated per-project migration time for a schedule of 200 tasks with 5 baselines?
Historical reporting data
- 3a. How is Project Online OData reporting history migrated? What happens to Power BI reports that depend on it?

SECTION C: DEPLOYMENT AND SECURITY

Compliance
- 1a. Provide current SOC 2 Type II report (issued within past 12 months).
- 1b. Confirm GDPR compliance. Specify data residency regions available.
- 1c. Provide most recent penetration test summary.
Identity and access
- 2a. List supported SSO protocols (SAML 2.0, OIDC, etc.)
- 2b. Confirm SCIM provisioning support and which identity providers are tested.
- 2c. Describe role-based access control granularity (project-level, field-level, resource-level).
Data encryption and portability
- 3a. Confirm AES-256 encryption at rest and TLS 1.2+ in transit.
- 3b. Confirm that buyer data is exportable in MSPDI XML or .mpp format on demand at no fee.

SECTION D: AI FEATURES

Describe all AI capabilities currently in GA (not roadmap). For each: feature name, data inputs, output format, and how the AI explains its recommendation to the user.
Schedule risk: Does the AI identify critical-path risk proactively? Demonstrate on buyer-provided schedule.
Resource leveling: Does the AI suggest leveling options that respect dependency constraints?

SECTION E: COMMERCIAL TERMS

Provide a full 3-year TCO model at [your user count] named users: license, implementation, training, support, integration.
Confirm whether migration services are included or quoted separately.
Confirm price lock through end of initial contract term.
Confirm data portability: MSPDI XML or .mpp export on demand, at no fee, at any time.

Phase 3, Pilot (Weeks 5–6)

Exit criteria: 3–5 projects migrated, validated, and running in production on the new tool. UAT sign-off from project owners. Documented gap list with mitigations.

This is the phase teams skip. Don't.

The pilot is where you discover that one custom field type doesn't translate cleanly, that the OData feed your CFO uses for monthly reporting needs a workaround, that your power users have hotkey muscle memory you didn't plan training for. Each of these is cheap to fix in week 5; expensive in week 11.

The import itself is the mechanic this phase rehearses. The video below shows the import wizard end to end, from uploading a Microsoft Project file to matching resources and importing.

Pilot project selection

Pick projects that collectively cover your portfolio's complexity:

One large schedule-driven project (1,000+ tasks, multiple baselines)
One agile/hybrid project (sprints + milestones)
One small simple project (the "easy win" sanity check)
One project with all four dependency types
One project with significant resource leveling

If a project owner won't cooperate, swap it. Volunteers > conscripts.

The pilot project owners are also your power-user cohort: five to ten PMs who use the new tool as their daily driver from this phase onward and become the internal trainers in Phase 4.

What "validated" actually means

Walk each pilot project against its Project Online twin, line by line, with the project owner. Confirm:

All tasks present, with correct dates
All dependencies (especially SS/FF/SF and lag) intact
Baselines preserve historical variance
Custom fields populated and computed correctly
Resources assigned with the same allocation percentages
Critical path matches (or, common, the new tool surfaces a better critical path because Project Online had a bug)

Document any gap. Decide: fix in tool, fix in import script, fix in process, or accept. The five test cases in the migration test plan template are the minimum the pilot walks through.

Phase 4, Cutover Prep (Weeks 7–9)

Exit criteria: bulk export verified, mapping rules documented, training delivered, rollback plan signed off, integration cutover plan agreed with vendors.

By now you've migrated five projects manually. Phase 4 is industrialising that for the rest.

Week 7, Mapping and scripts

Your pilot taught you the mapping rules: which custom fields go where, how lag values translate, how to handle resource pool migration. Codify these into the import script your migration partner (or your team) will run for the bulk cutover.

Week 8, Training: the role-based curriculum

PMs need 90 minutes hands-on. Stakeholders need 30. Executives need a 15-minute walkthrough of the dashboard. Schedule them now while everyone has bandwidth, three weeks before cutover, not three days. Those budgets are the floor for occasional users; the PMs who own schedules need four weeks of structured practice at four to six hours a week in a sandbox, starting in week 8 at the latest and ideally in the pilot phase. A one-hour overview on the Monday of go-live week is a handover note, not training: by Tuesday half the PMs are back in Project Online or Excel. The two motions that change most are the desktop file-save habit meeting a web tool that saves as you go (the number-one first-day ticket) and dependency editing for PMs who scheduled by dragging Gantt bars.

Role	Time budget	Curriculum	Exit check
Project managers	4 weeks, 4-6 hours per week	Week 1, orientation: the interface and data model, one familiar project in both tools. Week 2, scheduling: a 20-task schedule with all four dependency types and lag, a baseline and its variance, one live dependency-editing session. Week 3, reporting: a status report, two saved views, progress on ten tasks	The 20-task schedule built, baseline set, three tasks advanced and the critical path read correctly in 45 minutes; a simulated Monday-morning update in under 20 minutes
Power-user cohort (5-10 PMs whose projects are in the pilot)	Daily use from Phase 3, plus week 4	Bulk editing and templates; integration workflows (Power BI refresh, Excel export, the OData equivalent); week-one troubleshooting patterns; explaining the confusing concepts to a peer	Apply a template, import resource assignments, produce a portfolio view sorted by due date
Stakeholders	30 minutes	Find their projects, read a status report, set up notifications	Recorded walkthrough completed
Executives	15 minutes	The portfolio dashboard and the top-risk view, with the PMO director	Walkthrough held

For a distributed team, record the week-2 session, route questions to an async channel staffed by the cohort, and track sandbox completion rather than attendance. The phase ends when each PM completes the four core tasks in a timed sandbox exercise: 45 minutes is ready, over 60 minutes needs more practice before that PM's projects cut over.

Week 9, Integration coordination

Every Power BI dashboard, OData consumer, and timesheet hook needs a cutover window. Get those windows agreed with the consuming teams. Don't assume Power BI will "just keep working", it won't, because the OData URL is different.

Don't skip: the rollback plan. It should be one page. Since Project Online retired on September 30, 2026, the rollback target is the export set, not the tenant: delete the imported projects, re-import from the verified export, reschedule to weekend N+1, communicate via the standing comm channel. Sponsors love a written rollback plan; they trust the team that has one.

Phase 5, Cutover (Weeks 10–11)

Exit criteria: all active projects migrated, all integrations wired up, validation team sign-off, hypercare team in place.

This is the visible phase. Done right, it's anticlimactic. Done wrong, it's a Monday morning all-hands.

The go/no-go meeting: six checks, one scorecard

The go/no-go meeting is the gate into cutover weekend, and it routinely gets held as a status update where nobody votes no, because nobody wrote down what a "no" requires. Write it down: six checks, each scored pass, amber or fail against a threshold decided before the meeting. Two ambers do not block a go if neither touches export integrity or the rollback path; one fail on either of those two does, regardless of how green everything else looks.

Check	What it verifies	Pass threshold
Export verified	Every active project, resource pool, and custom field is out of Project Online and validated	100% of active projects re-imported and diffed against the source export, zero unresolved discrepancies
Schedule math matches	The destination recalculates the same critical path and finish dates as the source	Finish dates match within 1 day on every project; critical path sequence unchanged on tier-1 projects
Permissions mapped	Every user and role has working access in the destination	100% of internal users verified by spot-check login; guest access confirmed for anyone who needs it day one
Reporting rebuilt	The dashboards leadership actually checks are live	The 2-3 reports reviewed weekly are functional and validated against last week's Project Online numbers
Support staffed	Someone is on call to fix problems during and after cutover	Help desk trained, runbook published, on-call coverage scheduled through week one
Rollback still possible	You can still undo the cutover if it goes wrong	Source tenant remains read-accessible, export data retained, rollback procedure tested at least once

Export verified means every project, resource pool and custom field has cleared the data extraction window, not that the export job finished. After the retirement date the rollback threshold becomes: the export set is retained in two places, and a re-import from it has been tested at least once.

A worked scorecard: four checks pass, permissions and support staffing are amber (guest access for three consultants pending IT approval; week-one on-call pending a hire's start date). Neither touches export integrity or rollback and both have an owner and a date, so it is a go. Schedule math failing on one tier-1 project, because the destination's critical path drops two weeks that Project Online's forward pass accounts for, is a no-go with everything else green: the silent data problem the post-cutover validation audit exists to catch.

The migration lead makes the call, but the PMO director or the sponsor signs off on the thresholds before the meeting, because a decision only one person can see is a decision only one person can be held to. A no-go triggers three steps: reschedule to a specific new date; give every amber and fail a named owner and a re-check date; re-run all six checks. The rollback decision framework covers the signals that say stop and the ones that say push through.

The 60-hour window

Friday 17:00   Freeze writes on Project Online (admin-only mode)
Friday 18:00   Bulk export from Project Online begins
Friday 22:00   Bulk import to new tool begins
Saturday all   Validation team walks each project, flags variance
Sunday all     Hypercare team monitors audit log + integration health
Monday 06:00   PMs log in to the new tool; migration war-room on standby

Keep the window under 60 hours. Past that, fatigue corrupts decisions and small mistakes compound. Working from exported files, the freeze and export are already done; the window starts at the Friday 22:00 import.

The validation pass

Two-person teams, each project: one person on the new tool, one on the (read-only) Project Online view. Spot-check task dates, dependency arrows, critical path, custom-field values. A two-person team can validate ~30 projects/day. Plan capacity accordingly.

Communications

Status updates every 4 hours during the window: Slack channel, email digest, or whatever your org uses. The opposite of a successful migration weekend isn't a failed one; it's a successful one where leadership doesn't know it succeeded until Monday afternoon. The go-live note from the Phase 1 sidebar goes to all six audiences on cutover day, with the URL, access instructions, the hypercare channel and known issues so far.

The parallel-running window: how long, which tool wins, and when it ends

Parallel running is the period when both Project Online and the new tool hold live project data and PMs work in both. It is a validation window, not a grace period in which PMs choose their system. Its length is set by how long your validation checklist takes, not by the two-to-four-week figure consultants quote: 1 to 2 weeks for 5 to 20 projects, 3 to 4 weeks for 50 to 100, and above 200 projects, waves of 30 to 60 at 2 to 3 weeks each, active projects with upcoming milestones first. Plan 30 minutes of PM validation per prepared project, rebuild executive-facing reports in Phase 4, and do not close the window before at least 80 percent of active users have completed a meaningful workflow in the tool's activity report.

Three rules apply from day one. First, name the system of record per metric before the window opens and publish the map to every PM: when the tools disagree, the system of record for that metric wins, and nobody negotiates it project by project.

Metric	Source of truth	Why
Schedule finish dates	New tool	Current schedule math
Percent complete	Investigate if the gap exceeds 5 points	Import-cycle timing and rounding
Resource utilisation	New tool	A unified pool shows the real number once allocations are pooled (the resource model explains why)
Cost actuals	Project Online, until every cost feed is reconnected	Invoice and time-entry feeds arrive last
Milestone status	Investigate	A predecessor updated in one system only
Locked baselines and historical actuals	Project Online export	Most imports carry only Baseline 0

Second, freeze edits in Project Online from day one: the new tool takes every new update and Project Online is a read-only reference, which leaves one entry stream and removes double-entry fatigue. Third, run the same five checks on the same projects every day, and escalate only what falls outside tolerance:

Check	Compare	Run it	Escalate if
Task count	Open and total tasks per project	Daily	Gap of more than 1-2 tasks
Percent complete	Rollup percent complete per project	Daily	Gap over 5 points
Finish dates	Project and critical-task finish dates	Daily	Gap over 1 day without a known constraint
Resource assignments	Named assignments per resource, per project	Every 2-3 days	Any assignment present in one tool and not the other
Actual hours	Logged actual hours per task	Weekly	Gap over 10% on a cost-tracked task

A daily check takes one person about fifteen minutes, and most of what it finds is structural: import timing, recalculation cycles, baseline sets (Project Online supports eleven baselines and most imports bring Baseline 0), working-hour rounding that sums to a 1-3 point percent-complete gap across a 1,200-task schedule, and progress entered in the old tool out of habit. Three patterns are stop signals: every project finishing systematically earlier or later (a calendar or global lag changed on import), a critical-path reversal on the same project, and a task-count gap such as 80 tasks against 73. Working from exported files after the retirement date, the comparison source is the frozen export set: the checks still run against it, the timing causes disappear, and the window is shorter.

The window ends on affirmative confirmation of five conditions: every active project signed off by its PM (schedules, resources, dependencies and baselines, not just "it loaded"); every tier-1 report live and validated against the old source; every downstream integration tested end to end; every missing baseline, dropped dependency or empty custom field resolved or explicitly accepted; and the 80 percent adoption threshold met with the import current within 24 hours. Waiting for zero divergence is waiting for a condition that never arrives; commit to the date.

Phase 6, Stabilise (Week 12)

Exit criteria: hypercare ticket queue cleared, retrospective held, Project Online tenant archived for compliance, lessons documented.

The first week post-cutover is hypercare. Expect 3–10× normal support load. Staff for it.

Hypercare priorities

Critical: anything blocking a project owner from updating their schedule. Resolve same-day.
High: dashboard / report regressions. Fix within 48 hours.
Medium: cosmetic differences vs Project Online. Document and triage.
Low: feature requests. Park for the post-migration backlog.

Send the post-cutover survey one to two weeks in (data accuracy, access, training gaps) and feed the answers into the hypercare backlog. The first 90 days after Project Online migration picks up where hypercare ends.

Archive Project Online

Once the new tool is the source of truth, lock Project Online for read-only. Schedule the tenant deactivation per your data-retention policy, typically 90 days post-cutover, but check the retention preset that matches your obligation. If the tenant was already unreachable, the export set is the archive: keep it in two places for the same retention period.

Retrospective

Hold it within 7 days while memory is fresh. Two questions:

What worked that we should keep?
What didn't, that the next migration (or the next vendor migration in 5 years) should avoid?

Publish both internally. Migration debt stays paid down only if it's documented.

Tier variations: pick your timeline by portfolio size

The 12-week plan is calibrated for a 50 to 500-project PMO. Smaller and larger orgs need a different cadence. The table below shows the recommended phase durations by tier; the Phase Gate Discipline is identical across tiers (every gate clears before the next phase starts), only the timeboxes change.

Tier	Portfolio size	Total weeks	Phase 1 (Inv)	Phase 2 (Eval)	Phase 3 (Pilot)	Phase 4 (Prep)	Phase 5 (Cutover)	Phase 6 (Stabilise)
Compact	< 50 projects	6 weeks	0.5 wk	0.5 wk	2 wks	1 wk	1 weekend	1 wk
Standard	50-500 projects	12 weeks	2 wks	2 wks	2 wks	3 wks	2 wks	1 wk
Enterprise	500-1,000 projects	14 weeks	2 wks	2 wks	3 wks	3 wks	3 wks	1 wk
Large enterprise	1,000+ projects	16 weeks	2 wks	2 wks	4 wks (2 pilot waves)	3 wks	4 wks (2 cutover wknds)	1 wk
Multi-region	Federated tenants	14-18 wks	Unified	Unified	Per-region or unified	Unified	Per-region	Unified retro

The pilot doubles on Enterprise+ tiers because a single pilot wave does not cover enough portfolio diversity at that scale to derisk the bulk cutover. The cutover doubles because two-weekend windows let you split the portfolio in half and learn from the first weekend before committing the second. Phase 3 is the load-bearing phase in every tier; the Phase Gate Discipline forbids compressing it below 2 weeks even on the Compact tier.

What to Do This Week

If you haven't started:

Today: Schedule the kickoff for Monday morning. 60 minutes. Sponsor + PMO lead + IT lead.
Tomorrow: Pull the project list (or, if the tenant is gone, the export set inventory). Send it to the kickoff invitees as the pre-read. Migrate the active portfolio first, starting from the .mpp files you exported. Onplana Schedule opens them free if you need to check what each one holds.
End of week: Inventory complete. Phase 2 begins Monday.

If you've started but lost momentum:

Today: Audit your phase. Are exit criteria met for the previous phase? If not, you're behind your own definition. Don't paper over it, go back.
This week: Re-baseline the timeline. If you can't finish with current scope, descope the projects that can wait or hire help. Both are cheaper than a stalled migration.

The compressed plan if you are starting late or after the retirement date

Some PMOs did not make Sep 30. The calendar is the calendar; ambition isn't velocity. The compressed plan has one ordering rule: export, then destination, then reporting, because the export is the only step that ever had a real deadline and the dashboards can wait a month.

Secure the export set first. The export set you hold is the estate: inventory it project by project (file, last-modified date, task count, baselines), store it in two places, and treat everything not in it as a rebuild. The export deadline post covers what is still recoverable. If your export set is a folder of .mpp files, open each one without a Project licence in Onplana Schedule, free for Windows and Mac, to see what it holds before you rebuild.
Pick the destination in parallel. The decision never touches Project Online, so it must never be the reason an import waits. Three questions: all four dependency types with lag, import of the formats you exported (.mpp and MSPDI XML), and a resource pool if projects share people. Answer, pick, move.
Import the active portfolio, then validate. Phases 3 to 5 collapse to the Compact row of the tier table: a pilot on your three most complex projects, the go/no-go scorecard with the export set as the rollback target, and a cutover from files; the archived portfolio follows later.
Rebuild reporting last, on purpose. Rebuild the two or three reports leadership checks weekly and treat the rest as post-cutover work. A missing dashboard is fixed next month; a project that was never exported is gone.

A compressed window does not buy a reconciliation of every custom field formula, historical timesheets project by project, or a month-long parallel period; those are triaged out, not skipped, and reconciled after cutover from the exported files.

The goal isn't moving every project. It's preserving the schedule integrity of the projects that matter, and giving your PMO a tool worth using for the next decade.

Two free tools to anchor Phase 1 and Phase 2 Inventory the scope, then build the budget. No signup, runs on your real data, both export PDFs you can hand to the steering committee. → Project Online Inventory Checklist · Migration Cost Calculator

Onplana imports Microsoft Project files natively: .mpp + Project XML import, all four dependency types with lag, and baseline shadows and the critical path on the Gantt on every plan including Free, so you can run the Phase 2 data-fidelity spike without a procurement cycle. Start a free evaluation or book a migration walkthrough.

Microsoft 365 integration paths (if some teams keep working in the new Microsoft surfaces): Migrate Microsoft Planner to Onplana with optional live sync · Import Project for the Web Premium from Dataverse · Microsoft To Do bi-directional sync

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