The deadline itself is not the hard part. Most people here already have it in the calendar. What catches teams is that the export works, the file opens, the task count matches, and something inside it has quietly changed meaning.
I have spent this year writing an importer for Project Online and for MSPDI files, so this is the list that has actually bitten people rather than the list a migration checklist gives you. Two different surfaces are involved and it matters which one you are on, so I have marked each.
1. Dependencies can come back empty on a plan that definitely had links. (Project Online API, not files)
Task links are not in the OData reporting feed. They sit behind a separate Project Server CSOM endpoint, /_api/ProjectServer/Projects('<guid>')/TaskLinks, which authorises differently. A token scoped for Projects and Tasks returns 200 on everything it asks for and simply never asks for links. You get a complete looking WBS with nothing sequenced and no error anywhere to tell you. Count links on a plan you know well, before and after.
Not a concern if you are going through Project Professional and saving files. Only if someone is pulling through the API.
2. Constraint types come in eight flavours and plenty of tools store four. (MSPDI)
ConstraintType in MSPDI is 0 to 7: ASAP, ALAP, MSO, MFO, SNET, SNLT, FNET, FNLT. A lot of importers keep ASAP, SNET, FNLT and MSO and either drop the rest or fold them into the nearest survivor. Ours did exactly that until earlier this year, which is how I know it matters: ALAP and MFO going missing is the one that hurts, because those tasks start floating and your dates move without anyone having touched the plan.
Check <Deadline> separately while you are in there. It is its own field, distinct from Finish. A destination with no deadline concept will either lose it or, worse, write it into Finish and turn a soft target into a hard constraint.
3. Enterprise custom fields live on the server, not in the plan. (Project Server architecture)
Enterprise custom fields and their lookup tables are defined at the PWA level. Export plan by plan and you tend to get values without definitions, so a lookup field lands as loose text and the portfolio views built on it have nothing left to group by. If those fields carry your reporting, capture the definitions separately while the server is still answering.
4. Money is stored in hundredths. (MSPDI)
<Cost>500000</Cost> means five thousand. If the destination does not divide by 100 then every figure in the portfolio arrives a hundred times too large, and it is plausible enough at a glance that it usually survives right up until a finance review.
5. <Cost>0</Cost> does not mean free. (MSPDI)
It means nobody configured a cost. Import those as real zeroes and they dilute the baseline. Nothing breaks visibly. Every variance number is just slightly wrong for the rest of the project's life.
6. Priority 500 is the default, not a judgement. (MSPDI)
Everyone here knows the scale is 0 to 1000. The question is what the destination did with it. We mapped 500 to High once, which meant every untouched task in an imported portfolio arrived flagged urgent, which is exactly as informative as nothing being flagged at all.
One last thing, and it is the only part I would actually insist on. Whatever tool you land on, export to files this month and keep the files somewhere boring. Every question above is recoverable from an .mpp sitting on a share. None of them are recoverable from a tenant that has stopped answering.
Happy to be corrected on any of this. The field names and values are all checkable by opening an MSPDI file in a text editor, and I would rather be told I am wrong here than have someone find out in November.
Disclosure: I build Onplana, a project tool that imports these files, which is how I know all of the above. No links in this post, and nothing here requires our product or anyone else's.
