Somewhere in your company there is a job that runs at two in the morning. It has been running for years. Nobody watches it, nobody thanks it, and the only day anyone thinks about it is the day it doesn’t run.
That is the shape enterprise IT trusts: a schedule, a folder, a file, a log. It is also the shape almost nothing in project management bothers to offer. Microsoft Project was built for a person sitting in front of it, so the data inside your plans stays there, waiting for somebody to open a window and press something.
The oldest integration is the one that still works
Your ERP, the industrial accounting system, the internal portal somebody wrote in 2009 — none of them has a connector for Microsoft Project, and none of them ever will. What they all have is an import routine that reads files from a folder.
CSV is the lingua franca of enterprise integration. It has outlived formats, vendors and entire technology stacks, and it will outlive whatever we are excited about this year. If your plans can land on a share as CSV, every system you already own can read them. What makes them readable next month as well is the contract behind the files: how to feed a system that predates APIs.
One command, one folder, one dataset
Next to the application, OneClickExporter installs OneClickExporter.Cli.exe: the same engine, without a window, and everything you need for an unattended Microsoft Project export.
Point it at a single .mpp, or at a folder. Every plan at the folder’s top level is read into one dataset, the way a master plan would be — which is exactly what you need when each project manager drops their own file on the same share and nobody consolidates anything by hand.
The options are the ones from the window: resource pool, milestones, time-phased data, earned value, preliminary works. Add --json or --xlsx and the same dataset also lands as JSON or as an Excel workbook — for the people downstream who live in a spreadsheet rather than in a BI tool. Delimiter and encoding are yours to choose, because the system at the other end has opinions about semicolons and byte order marks that were formed a long time ago and will not be revisited.
The exit code is the part that matters
An unattended job that cannot report its own failure is not automation. It is a rumour.
The command line ends with an exit code your scheduler can act on: 0 done, 1 done with warnings, 2 something wrong in the plan, 3 the licence, 4 the parameters. Windows Task Scheduler can raise an alert on a non-zero result, and any orchestrator you already run can branch on it.
The difference is not academic. A silent failure at two in the morning becomes a steering committee reading last week’s numbers on Thursday, convinced they are current.
What it does not need
Microsoft Project is not installed on that server, and does not need to be. The plan file is read directly — no Office automation, no hidden windows, and no interactive session that has to stay logged in for a COM object to survive. That last detail is why so many home-made “automated” exports quietly stopped working the day someone hardened the server.
Nothing leaves the machine either: the export reads local or shared files and writes the CSVs where you tell it to.
The dashboard is the easy half
Building the report is a good afternoon’s work. Keeping it true, every morning, without a person in the loop, is the part that decides whether anyone still trusts it in six months. The alternative is the pack everybody knows: finished on Thursday, describing last week.
That part is a scheduled task, a folder, and an exit code — the three things your IT department has trusted since long before any of this had a dashboard.
OneClickExporter reads Microsoft Project plans without Project installed and writes Power BI ready CSV files — or Excel workbooks, when the destination is a spreadsheet. The command line is part of the product, same licence and same key, and it is included in the 15-day trial.
#MicrosoftProject #ProjectData #Automation #LegacyIntegration