How to export Microsoft Project data to legacy systems

Microsoft Project data into the systems you already run: a CSV file with fixed columns, in the same order on every run

There is a system in your company nobody wants to touch. It runs the plant, or the maintenance orders. It was written before anyone said “API”, it works, and the person who wrote it retired in 2016. Once a week somebody opens a Microsoft Project plan next to it and retypes the dates by hand.

That system does not want a connector. It wants a file — and it has wanted the same file, in the same shape, since the day it was written.

The hard part is not getting the data out

Old import routines are not fragile because they are old. They are fragile because they were written once, against one layout, and never touched again. Move a column, rename a header, skip a file, and the job stops — usually at night, and nobody notices until a report looks strange on Thursday.

So the real question is not how to export Microsoft Project data to legacy systems. Any script can write a CSV once. The question is whether the thing writing it behaves identically next month, after an upgrade, on a different machine.

Ten files, always written

Every export produces the same ten CSV files: Projects, Tasks, Assignments, Milestones, Resources, TimePhasedAssignments, TimePhasedResources, EarnedValue, Governance, PreliminaryWorks.

Switch a stream off and its file is still written, with its header row and no data. That is the contract, not an accident: an import routine looking for a file that is not there aborts, while one reading zero rows simply carries on.

Names and column order are fixed. Tasks.csv carries 142 columns in the same positions on every run, and the eight files of the original contract are certified byte-for-byte against the output of the COM-based predecessor — an integration written years ago against those columns still reads today’s export unchanged.

Comparison: what breaks an old importer versus what the export contract pins down — ten files always written, fixed column order, ISO dates, invariant numbers, choosable delimiter and BOM, neutralised formula characters
Six ways an import job dies, and the six guarantees that keep it alive.

Your old system has opinions about semicolons

It formed them a long time ago and it will not be revisited. So the format bends to the reader, not the other way round: --delimiter takes comma, semicolon or tab, and --bom writes UTF-8 with a byte order mark for the readers that insist on one.

Everything else is already neutral. Dates are ISO yyyy-MM-dd, and a missing date is an empty field — never NA, never a placeholder year that ends up in someone’s average. Numbers use the decimal point with no thousands separator, whatever the regional settings of the machine happen to be — a detail that has broken more integrations than any protocol ever did.

Even the scars are part of the contract

In Assignments.csv one header reads Actual Finish, with a space, while every neighbour is written solid. In Tasks.csv there is an unnamed column sitting after EAC. Both are inherited, both look like defects, and neither will be quietly repaired: somewhere there is an importer mapping column 51 by position, and a Power BI model expecting that empty column.

A contract you improve without telling anyone is not a contract. It is a surprise with a version number.

The field that refuses to become a formula

=cmd|'/c calc'!A1 is a perfectly legal task name. Written into a CSV and opened in a spreadsheet, it stops being a name. Any value starting with =, +, -, @, a tab or a carriage return is prefixed with an apostrophe so it stays text — except genuine numbers: a negative cost turned into text breaks a dashboard just as effectively.

One line, then it is somebody else’s problem

Point it at a plan or a folder of plans, name a destination, choose the delimiter your reader wants, and let the scheduler run it. Run every night, that is the nightly job your PMO never had. Microsoft Project is not installed on that server and does not need to be; nothing leaves the machine.

OneClickExporter.Cli.exe export "\\share\Plans" --destination "\\share\Export" --delimiter semicolon --bom

Then the file lands in the folder, and the system nobody wants to touch reads it the way it has read every other file for twenty years.


OneClickExporter reads Microsoft Project plans without Project installed and writes a fixed, documented set of CSV files — plus JSON or Excel when the destination prefers them. The command line is part of the product, same licence and same key, and it is included in the 15-day trial.

#MicrosoftProject #LegacyIntegration #DataContract #ProjectData #CSV

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top