Importing a Project Schedule from Excel or CSV

A spreadsheet import has a reputation problem. Teams treat it as the fallback path, the thing you do when the real file isn't available, and brace to rebuild half the schedule by hand afterward. That reputation is outdated for one specific reason: .xlsx and .csv run through the exact same import pipeline as .mpp and MSPDI XML files. Field mapping, dependencies, costs, and the audit trail land identically, whichever format the schedule started in.

What a spreadsheet genuinely lacks, and what a .mpp file carries natively, is hierarchy. To import Excel project schedule data with the structure intact, the importer has to reconstruct that hierarchy from the sheet itself, using four signals read in a fixed priority order: an explicit outline-level column, a dotted WBS code, a parent column, and finally title indentation, falling back to a flat task list only when none of those are present.

The direct answer: Importing a project schedule from Excel or CSV runs through the same pipeline as .mpp and MSPDI XML, so tasks, dependencies, costs, and the audit trail behave the same regardless of source format. The one thing that differs is hierarchy, which the importer rebuilds from four signals in priority order and reports every repair as a named warning against the source row, never a silent reinterpretation.

Why You Can Import Excel Project Schedule Data Without Losing Ground

Onplana's import wizard accepts .mpp, MSPDI XML, .mpx, Primavera .xer, and Excel or CSV files up to 50 MB, and routes all of them through the same parser. A worked breakdown structure keeps its shape whichever format it arrives in: Microsoft's own guidance on WBS codes describes the same outline-level and code concepts a spreadsheet import has to read back out of plain columns. The practical upshot: if your only copy of a schedule is a grid instead of a plan, that's not a downgrade path, it's the same import with one extra reconstruction step.

The Four Signals That Rebuild Your Hierarchy

The importer checks these in order, and stops at the first one it finds:

1. An explicit outline-level column. A column of plain integers (1, 2, 3) naming each row's depth is the least ambiguous signal and wins over everything else if present.
2. A dotted WBS code. Values like 1.2.3 encode both the depth and the position, so the importer can rebuild the full tree from the code alone.
3. A parent column. A column referencing another row's ID or task name directly states the hierarchy without needing depth math.
4. Title indentation. Leading whitespace or tab characters in the title cell, the same visual cue a person reading the sheet would use.

If none of the four are present, every task imports as a flat, single-level list. That's a valid outcome, not an error, but it means dependencies and durations will compute correctly while rollup and grouping do not.

The diagram below shows the check running through all four signals in order.

Two Things That Save You a Support Ticket

Two details cause most of the confusion in a first spreadsheet import, and both are easy to get right once you know they matter.

Leading whitespace in a title is meaningful, not messy. It's the indentation signal the importer reads when no outline-level, WBS code, or parent column exists. A well-meaning pass to "clean up" the sheet before export, trimming leading spaces and tabs, deletes the only hierarchy information a flat title column carries.

A circular parent reference is refused outright. If row 12 lists row 40 as its parent and row 40 lists row 12, the importer cannot resolve a real position for either task, so it stops and reports the conflict rather than guessing which direction is correct. Every repair the importer does make gets logged the same way, as a warning naming the specific Excel row, not a silent reinterpretation you'd only discover by checking the schedule against the source later.

The Plan-Shape Check

Before mapping any fields, the importer checks whether the sheet looks like a project plan at all. A contact list or an expense report gets rejected with the column mapper offered as the way through it, since a heuristic can't reliably guess which column is the task title in a sheet that was never meant to hold one. If you know your own sheet better than the heuristic does, naming the title column yourself overrides the check and the import proceeds against that mapping.

A Minimal Sheet That Imports Cleanly

Six columns are enough for a working import that keeps hierarchy and scheduling logic intact:

Column	Example value	What it drives
Title	" Design review" (indented)	Task name and hierarchy signal
Outline Level	2	Explicit hierarchy, takes priority over indentation
Start	2026-09-01	Scheduled start date
Finish	2026-09-05	Scheduled finish date
Duration	4d	Task duration
Predecessor	3	Finish-to-start dependency by row number

That's the whole shape. Everything past those six columns, custom fields, cost rates, resource assignments, adds detail without changing whether the import succeeds.

This is the practical destination for anyone who already exported a Project Online schedule to a spreadsheet and is now looking at a grid instead of a plan. The data extraction window usually produces exactly this shape, task rows with an outline level or WBS code intact, so the hierarchy signals above are what carry the schedule the rest of the way. If the source file is still a native .mpp rather than a spreadsheet, the field mapping mechanics work the same way, just with more field categories to track, and the step-by-step .mpp export guide covers getting that file out cleanly in the first place.

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