Import an MS Project Schedule Without Losing Dependencies

The import finishes, the Gantt renders, the bars look right, and the schedule gets used. Three weeks later someone notices the critical path doesn't match what the original file showed, and by then nobody remembers which tasks came from the import and which got edited since.

The direct answer: an MS Project schedule import that supports all four dependency types (finish-to-start, start-to-start, finish-to-finish, start-to-finish) with lag, and rebuilds the parent-child hierarchy as subtasks, generally keeps dependencies intact. What actually goes wrong is narrower than "links get dropped": negative-lag values that look like errors, zero-cost tasks that import as blank, and dangling tasks that reveal a dependency the original file never had in the first place. None of these show up by glancing at the rendered Gantt.

In short. A well-built MS Project import preserves all four dependency types with lag and rebuilds the task hierarchy, so links rarely vanish outright. The real risks are subtler: MS Project stores lead time as negative lag, so a 2-day lead shows as -2 rather than being relabeled; a genuinely free task can import with no cost shown at all, since MS Project treats zero cost as "not configured"; and dangling tasks after import usually mean the dependency was never formally linked in the source file. Check for all three before treating the import as done.

What actually breaks in an MS Project import

Most imports do not silently drop a dependency. They import it correctly and then present it in a way that reads as broken if you don't know the underlying quirk:

• Negative lag where you expected a lead. MS Project sometimes stores lead time as a negative lag value rather than a distinct field. A 2-day lead comes across as -2, which is technically correct and visually alarming the first time you see it in a new tool.
• Zero-cost tasks that import blank. MS Project distinguishes "$0, confirmed" from "no cost configured," and most source files never bothered to set the first one explicitly. The importer has no way to tell the difference, so a task that was genuinely free comes through with nothing in the cost field.
• Dangling tasks with no predecessors or successors. These usually mean the task was ordered correctly on screen in the original file but never formally linked, an implicit dependency that the schedule's author relied on visually and never encoded. Import surfaces the gap rather than creating it.
• Resource mismatches. If the resource's email address differs between the source file and the destination, the importer can't match them automatically and the assignment needs a manual resolve.

What should survive an import, format by format

Source format	What it is	Dependencies with lag	Hierarchy	Costs
.mpp (2007 or later)	Native Microsoft Project binary	Yes, all four types	Yes, rebuilt as subtasks	Yes, where set
MSPDI .xml	Microsoft Project's XML interchange format	Yes	Yes	Yes
.mpx	Older Microsoft Project exchange format	Yes	Yes	Yes
.xer (Primavera P6)	Primavera's native export	Yes	Yes	Yes
Excel / CSV	Manually built work breakdown structure	Only if columns encode it	From outline levels or WBS codes	If a cost column exists
.mpp (2003 or earlier)	Legacy binary format	Not supported	Not supported	Not supported

The practical limit worth knowing before you start: files over roughly 50 MB usually aren't a single project's schedule anymore, they're a portfolio export or a file carrying embedded images and notes that have nothing to do with the schedule itself. Split it first rather than fighting the importer.

Three checks that confirm the dependencies actually survived

Do these before anyone starts editing the imported schedule, not after:

1. Compare predecessor counts. Export or note the predecessor count per task in the original file, then compare it against the imported version. A task that had three predecessors and now has one lost something specific you can go find.
2. Recompute the critical path and compare it to the original. If the critical path in the imported schedule doesn't match the one Microsoft Project reported, a dependency, a duration, or a constraint changed somewhere between the two files, even if every task visually looks the same.
3. Look for negative lag and blank costs on purpose. Don't wait to stumble on them. Filter the imported schedule for negative-lag dependencies and zero-value cost fields, and confirm each one is a real lead or a real free task rather than an import artifact you haven't diagnosed yet.

The diagram below shows where each of the three failure modes actually originates in the pipeline: they don't show up at the same stage, which is why a single glance at the finished Gantt misses all three.

Bringing the file in

1. Save the source schedule in a modern format if it's still Project 2003 or earlier; nothing downstream reads that binary.
2. Upload the .mpp, MSPDI XML, .mpx, .xer, or Excel/CSV file. Onplana's own import walkthrough covers the upload, XML, and OData paths in more detail than fits here.
3. Review the resource-matching step if any assignee's email address differs between systems; resolve mismatches manually rather than letting the importer guess.
4. Once the import completes, run the three checks above before treating the schedule as ready: predecessor counts, critical path, and a deliberate filter for negative lag and blank costs.
5. If you're bringing the file in to keep working on it locally rather than as a shared plan, Onplana Schedule opens the same formats directly on the desktop and shows the same critical path and float without an upload step at all.

Run the free Schedule Health Check on the file before you commit to using the imported version anywhere. It runs the same dependency-graph analysis this post describes, in under a minute, and catches dangling tasks, negative-lag confusion, and constraint conflicts without you having to filter for each one by hand. Related reading: how .mpp field mapping decides what survives goes one level deeper on individual fields, and FS, SS, FF, SF explained covers what each dependency type actually does once it's imported correctly. If you just need to open the file without importing it into a shared project at all, opening an .mpp file without Microsoft Project covers the read-only and desktop-editing paths.

Run the free Schedule Health Check Upload your .mpp, MSPDI XML, or other schedule file and get a per-finding breakdown of dependency issues, constraint conflicts, dangling tasks, and the real critical path, computed from the dependency graph. No signup, no credit card. → Run the Schedule Health Check

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