You Saved Your Project Online Backup. Now What?

September 30 came and went, and Project Online went with it. If your organization saved its projects as MPP files and pulled an OData export before access ended, you did the most important thing you could have done.

The question now is what you are actually holding, and how to turn it back into a working project environment without losing anything along the way. I recently helped a client rebuild about 150 live projects from exactly these two ingredients, so I want to share what we learned, including the parts that are easy to get wrong.

If you are still deciding which platform to move to, my earlier post, Project Online Retirement: How to Choose What Comes Next, covers the options. This one is about the backup itself.

What is in an MPP file, and what isn’t

An MPP file is a single project schedule saved from Microsoft Project. If you saved your plans from Project Online through Project Professional, each file holds the heart of that project:

• Tasks, durations, dependencies, and constraints
• Resource assignments and the work assigned to each person
• Baselines, so you can still compare plan against actual
• Progress and actuals, as they stood when the file was saved
• Local custom fields that belonged to that plan
• Your enterprise resource pool and each person’s rate history
• Enterprise custom field values, which may not come through when the file is opened against a new server
• Timesheets and status updates
• Project sites, including documents, risks, and issues
• Permissions, enterprise views, and settings
• Your reports and the connections behind them
• The MPP files rebuild the schedules. They load into Project Server Subscription Edition as enterprise projects, and platforms like OnePlan can work with Microsoft Project files as well. Enterprise scheduling tools like Deltek Open Plan and Oracle Primavera P6 can import them too, though they calculate schedules differently, so the results need careful checking.
• The OData export restores what the files left behind, especially enterprise custom field values and project-level data.
• The OData export is also your answer key. Once projects are rebuilt, you compare each one back to the export to prove nothing was lost.
• Backup review: a quick look at what you saved, what it contains, and what can realistically be restored
• Recovery plan: the order to rebuild in, which source wins for which data, and how you’ll know it’s done
• Rebuild: projects restored into Project Server Subscription Edition, OnePlan, Deltek Open Plan, Oracle Primavera P6, or another platform
• Verification: every project compared back to your OData export, with differences explained
• Reporting: Power BI reports reconnected, with your history rebuilt from the export

What it does not reliably hold is everything that lived at the enterprise level, around the plans:

In other words, the MPP file gives you the schedule. It doesn’t give you the system the schedule lived in.

What is in an OData export, and its catch

Project Online’s OData feed is what most Power BI reports were built on. If you exported it, you have a record of your data across all your projects in one place: projects, tasks, assignments, resources, baselines, and the enterprise custom field values your MPP files may be missing. Depending on what was exported, you may also have time-phased data and timesheet detail.

The catch is that an OData export holds the published version of each project, not necessarily the latest one. On the migration I worked on, a number of plans had been updated after they were last published. The MPP file and the OData export disagreed for those projects, and both were “right.” One showed the current plan, the other showed what had last been shared.

Rate history is the other gap. A standard OData export usually holds a resource’s current rate, not the full history of dated rates behind it. If your costs depend on rates that changed over time, it is worth checking whether that history was captured anywhere else.

Why you need both

The two backups do different jobs, and together they are much stronger than either one alone.

That last point matters more than it sounds. On our migration, every project was compared against the original data before go-live. Most matched exactly. Where they didn’t, we could explain why, and the client could sign off with confidence instead of crossed fingers.

Six mistakes that lose data on the way back in

Every one of these came up on a real project. None of them are hard to avoid once you know to look.

1. Loading projects before the resource pool exists

If the people in your plans don’t exist in the new system yet, their assignments may come in disconnected from your resource pool. Build the resource pool first, then load the projects.

2. Assuming custom field values came along

A plan can open perfectly and still be missing the job codes, cost codes, or status values your finance and reporting teams depend on. Check them, and restore them from the OData export where needed.

3. Trusting views and calculated fields because they look right

After a migration, a view or calculated field can point at the wrong data and still look completely normal. We saw columns quietly showing stale values that had stopped updating. Test what people actually see, not just the data underneath. That one deserves a post of its own.

4. Treating the published numbers as the truth

As above, the export and the file can disagree for good reasons, such as work done after the last publish or rates that changed since. Decide up front which source wins for which kind of data, and write it down.

5. Letting old macros run

Many older plans carry macros saved inside the file. Ours had macros in about two out of every three files, including some that published the plan automatically when it was closed. Opening those files in a new environment can trigger behavior nobody expects. Check for embedded code before you start opening files in bulk.

6. Losing the original project names

Saving to a file can quietly change a project’s name. On our migration, parentheses in project names were saved as underscores, so a plan named “Pump Trial (Phase 2)” came back as “Pump Trial _Phase 2_.” Small, but it breaks anything that looks projects up by name.

Take stock of your backup

Before planning anything, it helps to know exactly what you have. These are the questions I’d ask first:

1. Do you have an MPP file for every active project, or only some?
2. Were the files saved from Project Online while connected, or exported some other way?
3. Which OData tables were exported? Projects, tasks, assignments, and resources at a minimum. Time-phased data and timesheets if you can.
4. Do you have a list of your enterprise custom fields and lookup values, including any formulas?
5. Did anyone capture resource rates and their history?
6. Do you have copies of your Power BI reports and the queries behind them?
7. Is there a list of the automation and integrations that connected to Project Online? (My last post, The Hidden Automation Behind Your Project Online Environment, covers why that list matters.)

What may not be recoverable

I’d rather be straight about this: if something wasn’t exported, it may simply be gone. Timesheet detail, rate history, and data that was never published are the most common gaps.

Project sites are worth a separate check. Documents, risks, and issues lived in SharePoint, which is separate from the project data itself. Ask your Microsoft 365 administrator what is still available there before assuming either way.

Even with gaps, most organizations holding MPP files and an OData export can get back to a working project environment with their active work intact. Knowing the gaps early just means nobody is surprised later.

How Pinnacle helps

At Pinnacle Management Systems, we help organizations turn a Project Online backup back into a working system:

Frequently asked questions

Can I restore Project Online projects from MPP files?

Yes. MPP files saved from Project Online can be loaded into Project Server Subscription Edition, and imported into other platforms such as OnePlan, Deltek Open Plan, or Oracle Primavera P6. Enterprise custom field values and resource connections usually need extra work to restore correctly.

What is the difference between an MPP backup and an OData export?

An MPP file holds one project’s schedule. An OData export holds published data across all your projects, including custom field values your MPP files may be missing. A complete recovery works best with both.

Our MPP files and OData export show different numbers. Which is right?

Often both. The OData export reflects the last published version of each project, while the MPP file may include later changes. Decide which source is authoritative for each kind of data before you rebuild.

Can we recover our timesheets?

Only if timesheet data was included in your export. Check which OData tables you saved.

How long does recovery take?

It depends on how many projects you have and how complete your backup is. A short review of what you saved is the fastest way to get a realistic answer.

If you are holding a Project Online backup and aren’t sure what to do with it, I’m happy to take a look. A short conversation usually tells us what can be restored, and what it will take.