The Project Online Cutover Day Runbook

Pull your Project Online cutover runbook. If it doesn't say what to do at 02:00 Saturday when the bulk import is still running and the validation team hasn't started, you don't have a cutover runbook. You have a plan that assumes everything goes right.

Assumptions-go-right planning is how migrations fail publicly. The export hangs on a corrupt .mpp file. The import queue backs up on a project with 4,000 tasks. The integration token expires at 23:00 Friday and nobody owns the service account. Each of those is a recoverable problem if you planned for it, and a rollback-triggering crisis if you didn't. This runbook is for the team that wants to recover, not roll back.

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

TL;DR for the steering committee:

• The cutover window is 61 hours: Friday 17:00 through Monday 06:00.
• Four phases in sequence: freeze + export (Friday evening), bulk import (Friday night through Saturday morning), validation pass (Saturday), integration reconnect + go/no-go (Sunday).
• Three rollback triggers: validation failure rate above 20%, a tier-1 project with a blocking fidelity issue, or a critical integration not reconnected by Sunday 18:00.
• Project Online read-only access persists until September 30, 2026 per Microsoft's retirement announcement, so a rollback means reschedule, not disaster.
• This runbook assumes you have completed the 90-day migration plan and the Project Online migration checklist is fully signed off before the window opens.

The 61-Hour Project Online Cutover Window

The cutover window has a specific shape. It is not "the weekend." It is 61 hours of sequenced work, each phase dependent on the previous one completing cleanly. If you think of it as "the weekend," you'll treat Saturday morning as slack. It isn't.

The diagram below shows the phases of the cutover window and where each phase's hard boundaries sit.

The table below gives you the operational detail for each block.

Time block	Phase	Owner	Exit criterion
Fri 17:00–18:00	Freeze	PMO Lead	Zero open checkouts in Project Online confirmed
Fri 18:00–22:00	Bulk export	Migration Engineer	All .mpp files downloaded, manifest hash-checked
Fri 22:00–Sat 08:00	Bulk import	Migration Engineer (on-call)	Import queue 100% processed or rollback invoked
Sat 08:00–20:00	Validation pass	Validation Team	All tier-1 projects signed off, tier-2 spot-check complete
Sun 06:00–18:00	Integration reconnect	Integration Lead	All integrations green in monitoring dashboard
Sun 18:00	Go/no-go gate	PMO Lead + Sponsor	Go decision documented and communicated
Sun 18:00–Mon 06:00	Final readiness	All	User comms sent, helpdesk briefed, rollback stand-down
Mon 06:00	Go-live	PMO Lead	Users directed to new system

Pre-Cutover Prerequisites

The cutover weekend is not the time to discover you have 14 corrupted .mpp files or that your Power BI service account expired. That work belongs in the weeks before, covered in the Project Online migration checklist. The prerequisites below are the minimum gate to opening the freeze window. If any item is unresolved on Friday at 16:00, postpone the cutover.

1. Inventory complete. Every project in Project Online is categorized: tier-1 (active, business-critical), tier-2 (active, not critical), tier-3 (historical, archive-only). Use the Project Online Inventory Checklist if you haven't already.
2. Dry run passed. At least one full dry-run export and import completed the previous weekend. Every tier-1 project validated successfully in the dry run.
3. Service accounts confirmed. The migration service account, the import API credentials, and the Power BI gateway service account are all active. Tokens are not expiring this weekend.
4. Rollback document signed. The rollback decision authority, the rollback steps, and the reschedule date are documented and signed by the PMO sponsor. The team needs to know who calls the rollback, not just what triggers it.
5. Stakeholder comms sent. Three-stage comms: two weeks before to project owners, one week before to all PMO users, Friday morning of the cutover with a final "we're doing this tonight" note. Silence before a go-live creates anxiety.
6. Helpdesk briefed. The support team has a one-page FAQ for Monday morning, covering how to log in, where the projects are, and how to raise a data issue if they spot one.
7. War room established. A shared channel (Teams, Slack, whatever you use) is open with all migration team members, the PMO lead, and the sponsor. Every status update, every issue, and every decision goes there, not to individual DMs.

Phase 1: The Freeze

The freeze window is Friday 17:00 to 18:00. One hour to confirm that nothing is in motion before you start moving it. This phase has a single job: guarantee that the data you export is the data you intend to migrate.

1. Send the freeze notification to all PMO users at 16:45 Friday. The message is short: Project Online is entering maintenance mode at 17:00; no edits, saves, or publishes until Monday.
2. At 17:00, pull the open-checkout report from Project Online. Go to PWA, navigate to Server Settings, then Queue Jobs or Check In Projects. Every project that is checked out to a user needs to be force-checked-in by the migration engineer.
3. Force-check-in any open checkouts. Notify the owning PM by name in the war room channel. They will occasionally push back; the PMO lead needs to hold the line. An open checkout at export time means a stale file in the migration package.
4. At 17:45, run the open-checkout report again. The result must be zero. If it isn't, do not advance to export until it is.
5. Confirm in the war room channel: "Freeze confirmed, 17:52 Friday, zero open checkouts, proceeding to export."

Phase 2: Bulk Export

Export begins at 18:00 Friday and must complete by 22:00. Four hours for a mid-size PMO of 100 projects is comfortable. A 300-project PMO needs to start at 17:00 or break the export into a pre-export run of tier-3 archives the previous night.

1. Run the export script against your Project Online PWA URL. The script should download each project as a native .mpp file, plus a JSON metadata sidecar (custom fields, resource assignments, enterprise lookup table values). Do not export to XML only: XML loses some field types silently.
2. Download the enterprise resource pool separately. It is not embedded in individual .mpp files. One export, one JSON file, treat it as a tier-1 artifact.
3. Hash-check the manifest. After all downloads complete, run an MD5 or SHA-256 hash on every file and write the manifest to a text file. This is your proof-of-export: if an import fails later because a file is corrupted, the hash tells you whether the corruption happened during export or during the import process.
4. Spot-check five tier-1 .mpp files in Microsoft Project desktop before closing the export phase. Open each one, verify the task count matches what you recorded in the inventory, and confirm the baseline dates are present.
5. Copy the export package to two locations: the migration server and a cloud backup (SharePoint document library or Azure Blob Storage with a short SAS token). If the migration server dies at 01:00 Saturday, you have 15 minutes of recovery, not a crisis.
6. Log "Export complete" in the war room channel with the file count, total package size, and the time. This is the baseline for Saturday morning's import count.

Phase 3: Bulk Import

Import starts at 22:00 Friday and the window closes at 08:00 Saturday: 10 hours. Most PMOs with 100 active projects complete import in four to six hours. The overnight window is buffer, not schedule.

1. Start the import queue with tier-1 projects first. If the queue stalls at 02:00 on a complex schedule, you want it to be a tier-2 project, not your CFO's capital program.
2. Assign one engineer to on-call monitoring overnight. This is not optional. The monitoring job is: check the import queue log every 30 minutes, flag any failed import to the war room channel immediately, and invoke the rollback protocol if the failure rate exceeds thresholds (see the rollback section).
3. For each failed import: log the project name and error, attempt a retry once, and if the second attempt fails, quarantine the project file to a separate folder. Do not block the queue on a single bad file. Continue importing and address quarantined files as a batch after the main queue finishes.
4. At 06:00 Saturday, pull the import progress report. You need the count of successful imports, failed imports, and quarantined files. Share in the war room channel.
5. At 08:00, the import window closes. Any project not yet imported is either in-flight (acceptable if it will complete by 09:00) or quarantined (needs a decision before validation begins). See rollback triggers below for the quantitative thresholds.

Phase 4: Validation Pass

Validation starts Saturday 08:00. The validation team is checking one thing: does the data in the new system match the data in Project Online? Not "does it look nice" and not "do they prefer the new interface." Data fidelity, period.

Organize the validation team into two-person pairs. Each pair works through a project list: one person reads data from Project Online (still accessible, read-only), the other reads from the new system. They compare and flag discrepancies. Two-person teams validate roughly 30 projects per day at a thorough pace. Scale your team accordingly.

1. Validate every tier-1 project with a complete check: task count, task names, baseline start and finish, actual start and finish, resource assignments by name, and custom field values for the five most-used fields in your PMO.
2. Validate tier-2 projects with a spot check: task count, baseline dates, and two custom fields. A 10% sample of tier-2 projects that passed the dry run is sufficient.
3. Tier-3 archive projects do not require validation during the cutover weekend. Confirm the file is present and opens without error. Full validation can happen in the two weeks after go-live.
4. Log every discrepancy in a shared spreadsheet with the project name, field, expected value, and actual value. Categorize each as: blocking (wrong value on a tier-1 project, no same-weekend fix), fixable (wrong value with a known correction that takes under 30 minutes), or cosmetic (presentation difference, not a data error).
5. At 16:00 Saturday, tally: blocking issues count, fixable issues count, validation failure rate (projects with at least one blocking issue divided by total tier-1 projects validated). Share in the war room.
6. Fix every fixable issue before 20:00 Saturday. Escalate blocking issues to the PMO lead for rollback assessment.

Phase 5: Integration Reconnect and the Go/No-Go Gate

Integration reconnect runs Sunday 06:00 through 18:00. The integrations list comes from your pre-migration inventory. Work through them in criticality order: the Power BI reports your steering committee sees every Monday morning are tier-1; the weekly CSV export to a shared drive is tier-3.

For each integration:

1. Update the connection endpoint or API base URL to point to the new system.
2. Refresh any OAuth tokens or API keys scoped to Project Online.
3. Run a test transaction: for Power BI, a dataset refresh; for a SharePoint list sync, a triggered push; for a REST API consumer, a GET against the projects endpoint.
4. Confirm the output matches the expected format. Log the result (pass/fail) in the integrations tracking sheet.
5. For any integration that fails: attempt a fix, document the root cause, and flag to the PMO lead if you cannot resolve within two hours. An unresolved critical integration at 17:00 Sunday triggers the go/no-go gate assessment.

The go/no-go gate is Sunday 18:00. The PMO lead and project sponsor review three inputs: the validation pass result, the integrations tracking sheet, and the list of any outstanding quarantined projects. The decision is binary: go, or hold. If you hold, the rollback protocol activates. If you go, the PMO lead sends the go-live notification to the war room and prepares the user communication for Monday morning.

Rollback Triggers

Three conditions trigger a rollback. Any one of them is sufficient. The PMO lead holds the authority; the trigger criteria are defined in advance so that the Friday-night judgment call is already made.

Trigger 1: Validation failure rate above 20%. If more than one in five tier-1 projects has a blocking data-fidelity issue with no same-weekend fix, the risk of going live with bad data outweighs the cost of rescheduling. Call the rollback.

Trigger 2: Blocking fidelity issue on a tier-1 project with no fix path. A single corrupted baseline on the CFO's capital program, a missing resource pool, or a lost custom-field definition can cascade into real business decisions made on wrong data. If you can't fix it by Sunday 16:00, call the rollback.

Trigger 3: Critical integration not reconnected by Sunday 18:00. "Critical" means the integration affects something a user will touch Monday morning. Power BI dashboards reviewed in the Monday steering meeting: critical. The weekly archive export: not critical.

When a rollback is called: notify the war room immediately, send a stakeholder communication within 30 minutes (short, factual, includes the reschedule date), and confirm with the Project Online administrator that the read-only tenant stays accessible. Project Online remains accessible in read-only mode through September 30, 2026 per Microsoft's retirement announcement, so a rollback is a reschedule, not a loss.

Document the root cause before you disband the team. The next cutover attempt benefits from knowing exactly what broke and when.

The First 24 Hours After Go-Live

Monday 06:00 is not the finish line. It's the start of the live support window. The migration team's job shifts from data movement to issue triage, but it doesn't end.

1. Send the go-live communication at 06:00 Monday. Two sentences for users, one paragraph for project owners, a short note for the PMO sponsor. The user message includes: where to log in, who to contact with issues, and when they'll get hands-on orientation.
2. Staff the war room channel through Monday 17:00. Triage every reported issue in under two hours. Categorize as: data error (investigate and fix), access issue (user provisioning), training gap (respond with guidance), or known issue (already logged, ETA on fix).
3. Run the Monday morning Power BI refresh manually and confirm the output before the steering meeting. Don't let executives encounter a blank dashboard as their first live-system experience.
4. At 12:00 Monday, the PMO lead does a 30-minute check-in with project owners in tier-1. Not a survey, a call. "Is your project there? Does the baseline look right? Any data you're unsure about?" Three questions. This catches misses that users won't file a ticket for, they'll just work around silently.
5. At 17:00 Monday, close the active war room support mode and transition to standard support process. Document any open issues with owners and ETAs. Send a brief close-out note to the sponsor: go-live complete, issue count, resolution status.

Your 90-day migration plan likely projected a two-week post-cutover stabilization period. Keep it. The first Monday is the high-water mark of user confusion. Week two is quieter. By week three, the migration is background noise and the PMO is running on the new system.

Run the free Project Online Inventory Checklist Walk through your tenant's 35 pre-cutover items, with owners and notes fields, and export a PDF for the steering committee. No signup required. Open the checklist

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