How Project Online Dependencies Break During Migration (and How to Stop It)

The post-migration schedule looked clean. Every task had a start date, a finish date, a resource. Status reports started flowing. Three weeks later, the schedule showed the integration phase finishing before the development phase. A predecessor that had been 8 days of lag now had 0, and the successor had already been marked complete before its predecessor finished in calendar time. Nobody caught it until the next steering committee review.

This pattern repeats in nearly every Project Online migration that skips a dependency audit. Project Online dependencies store more than predecessor-successor links: they carry type (FS, SS, FF, SF) and lag values that most .mpp imports handle incompletely. The import completes without errors. The schedule renders. Everything looks fine. The math problems only surface when the schedule plays out in calendar time.

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

TL;DR: Project Online supports FS, SS, FF, and SF dependency types plus lag. FS migrates cleanly in nearly every tool; SS, FF, and lag values are the primary risk surface. Before migrating, export a full dependency inventory by type and lag. After migrating, compare it against the destination. Don't rely on visual inspection: the schedule looks plausible even when dozens of links are wrong.

What Project Online Dependencies Actually Store

Project Online stores task dependencies in the Microsoft Project XML (MSPDI) format when you export .mpp or XML files. Each dependency record has four components: a predecessor task ID, a successor task ID, a dependency type, and an optional lag value.

The four dependency types follow PMBOK conventions, as documented in the Project Online service description:

Finish-to-Start (FS): The successor cannot begin until the predecessor finishes. This is the default in every PM tool. An FS with a 2-day lag means the successor starts 2 days after the predecessor finishes.

Start-to-Start (SS): Both tasks start at the same time, or the successor starts a specified number of days after the predecessor starts. Common in parallel workstreams where one task kicks off another but both run together.

Finish-to-Finish (FF): Both tasks finish at the same time, or the successor must finish within a lag of the predecessor finishing. Common in quality-review chains where review finishes when the deliverable finishes.

Start-to-Finish (SF): The successor cannot finish until the predecessor starts. The rarest type, used in just-in-time scheduling.

Each type can carry a lag (positive delay) or lead (negative lag) expressed in days, hours, or percentages of the predecessor's duration. A 50% lag on an FS dependency means the successor starts halfway through the predecessor, not after it.

The diagram below shows each dependency type and its migration risk:

What Actually Degrades During Export

When you export a Project Online project to .mpp or MSPDI XML, the dependency types and lag values are stored in the XML schema. What the destination tool does with those values depends entirely on that tool's own dependency model.

Three failure modes appear most often.

Type collapse. The destination tool supports only FS dependencies. Any SS, FF, or SF link in the MSPDI XML gets silently converted to FS or dropped entirely. The successor task's calculated start date changes, but no import error fires. The schedule is structurally different from the source but visually plausible.

Lag silently zeroed. The destination tool supports the dependency type but ignores lag values on import. A 3-day lag becomes 0, and the successor task moves 3 days earlier in the schedule. If that task is on or near the critical path, the project's calculated finish date shifts with no warning.

Cross-project dependency orphaning. Project Online allows cross-project dependencies: a task in Project A linked to a task in Project B through the enterprise resource pool. When projects are migrated individually, those cross-project links become orphan predecessors. The successor tasks lose their constraint entirely and schedule to "as soon as possible," which can shift tasks dramatically in the migrated schedule.

In our audit of Project Online schedules, roughly 40% of schedules with more than 200 tasks contained at least one non-FS dependency type. For schedules with more than 500 tasks, that figure exceeds 60%.

Lag Values: The Hidden Variable

Lag is the most underestimated migration risk in dependency chains. A lag value modifies the timing relationship between predecessor and successor. It is not a separate task, not a buffer task, not visible in the task list. It lives only in the dependency record.

When lag values are stripped or zeroed on import, the schedule compresses. Predecessor-to-successor gaps that were intentional (allowing for review, transport, legal review, or cure time) disappear. The schedule now shows tasks starting sooner than they physically can. Status reports look more optimistic. Milestone dates appear closer. Resource assignments overlap in ways the source schedule deliberately prevented.

The failure is not immediately visible. If the destination tool recalculates from the new (incorrect) lag values, everything looks fine inside that tool. You would have to compare the source and destination dependency lists side-by-side to see the discrepancy.

Leads (negative lag) carry the same risk. A 2-day lead on an FS dependency means the successor starts 2 days before the predecessor finishes. If the lead is dropped, the successor moves 2 days later. If the lead is kept but the dependency type changes, the relationship changes its meaning entirely.

How to Verify Project Online Dependencies Before You Migrate

The safest place to audit is the source schedule, before anything moves.

Step 1: Export the dependency inventory. Open your projects in the desktop client or use an MSPDI XML export. For each project, extract the full task dependency list: predecessor task name, successor task name, dependency type, lag value, and lag unit. A PowerShell query against the OData API can pull this for the whole tenant in bulk.

Step 2: Count by type. Sum the dependency counts by type (FS, SS, FF, SF) and by lag presence. Document these numbers. They become your acceptance test after migration.

Step 3: Run a schedule health audit. The free Schedule Health Check analyzes .mpp and MSPDI XML files and surfaces broken dependency chains, orphaned tasks, and circular logic before you expose the file to migration. Diagnose the source first; don't migrate a schedule with pre-existing dependency problems. For a deeper look at what else silently breaks in Project Online schedules, see the 7 hidden killers in your MS Project schedule.

Step 4: Flag the high-risk dependencies. Any SS, FF, or SF dependency with a lag value is high risk. Any cross-project dependency is high risk. Mark these explicitly so your migration team can verify them by hand after import.

Step 5: Verify your destination tool's dependency model. Confirm which dependency types the tool supports and whether it preserves lag on import. Most modern tools support SS and FF; SF support is less common. Run a test import with a small schedule containing all four types plus a mix of lag values, then compare input vs output before committing to the tool.

Post-Migration Verification Checklist

After importing each project into the destination tool, run this checklist before accepting the migration as complete:

1. Compare total dependency count in source vs destination. Any reduction is a red flag.
2. Verify that each SS, FF, and SF dependency in the source exists with the same type in the destination. Check a random 20% sample for large schedules.
3. For any dependency with a non-zero lag in the source, confirm the lag value and unit match in the destination.
4. Check the critical path in both tools. The critical path should involve the same tasks. If the destination shows a materially different critical set, a dependency or lag value has changed. The critical path method explained covers how to read and compare critical paths if you need to rebuild that foundation.
5. Look for orphaned tasks: tasks with no predecessors and no successors that had at least one of each in the source. These signal dropped dependencies.
6. For cross-project dependencies: verify the linked tasks still exist in the destination and the dependency has been rebuilt or replaced.

If you run the Schedule Health Check against both the source and the migrated file, you can compare findings between them. A longer finding list in the destination than the source signals something degraded during import.

What to Do When Dependencies Break

You find them: a set of SS dependencies converted to FS, or a dozen lag values zeroed out. Here is the path forward.

For type changes (SS/FF converted to FS): Rebuild the affected dependencies manually in the destination tool. Use your source spreadsheet as the specification. SS links where both tasks share the same start date can often be rebuilt as a task relationship plus a constraint; FF links may need the destination tool's co-termination setting enabled.

For zeroed lag values: Re-enter the lag values from your source spreadsheet. Prioritize dependencies on or near the critical path first. Non-critical-path lag values affect resource loading and reporting accuracy but don't move the project finish date directly.

For dropped cross-project dependencies: These need to be rebuilt as either internal links (if both projects are in the same program) or documented external constraints (if they're in separate programs). Document them because future schedule updates won't propagate across projects without explicit linking.

For structural damage: If more than 15% of dependencies changed type or were dropped, consider re-importing from a corrected MSPDI XML rather than repairing in the destination. Fixing the XML source and re-importing is faster than rebuilding 300 dependencies by hand.

Why This Gets Harder Near September 30, 2026

Microsoft Project Online retires on September 30, 2026. After that date, the tenant enters read-only mode and eventually goes dark. Every schedule you have not validated in the destination tool before cutover is a schedule you will be diagnosing against a system you can no longer query directly.

The dependency audit is one of the most tedious parts of migration preparation. It is also the one most likely to be cut when time is short. The teams that skip it discover the same thing: schedule math that looks right but is wrong in ways that only surface in status reports, two or three weeks after the tools are done.

Start the audit early. For large PMOs, a full dependency inventory for 100-plus projects can take several days to compile. The project-online-migration-checklist-2026 walks through the full pre-migration inventory process, including the dependency audit as a named line item.

Audit your schedules before migration The free Schedule Health Check analyzes your .mpp and MSPDI XML files and surfaces broken dependency chains, type inconsistencies, and orphaned tasks in about 30 seconds. Run it on your source schedules before they move. → Run the Schedule Health Check

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