The challenge
The manufacturer’s project management office ran on Project Server 2013: on-premises, out of support, and holding the schedules for engineering programmes measured in years.
The engagement was scoped against one project. That was not carelessness, it was what the discovery found, because the PMO’s own view of what was live had drifted from what the server actually held. As the migration approached, the number moved to 35, then to roughly 250, and by the time content was moving it stood at 300 live projects with a further 1,500 or so identified for archive.
A scope change of that size sends a migration wrong in one of two ways: the supplier absorbs it quietly and delivers late, or the work stops while commercial conversations happen and the date is lost. The client had already replanned once, moving cutover and go-live from February to March.
The solution
The scope change was documented and priced, not absorbed. A change request set out the movement from 1 to roughly 250 projects with the additional effort costed at 120 hours, and went to the client for approval, so the PMO could decide knowingly about a migration whose size had changed underneath everyone.
The migration tool’s failure mode was engineered around rather than escalated. The first three attempts failed: FluentBooks leaked resources across long runs, degrading until it stalled. The run was restructured into batches of five, with a forced restart of Project between batches and the ten largest projects handled individually, where one failure would otherwise cost a whole batch. The fourth attempt produced 142 projects in about 24 hours.
Reconciliation ran against the source system, not the migration list. Schedules saved but never published do not appear in the reporting database that migration lists are built from, and in a PMO an unpublished schedule is often the one someone is actively working on. An extract by modification date across the preceding four months was pulled to catch them, and the go-live list checked against it.
What would not be there on day one was said out loud. Ahead of the related intranet cutover the client was told plainly that Power Automate was out of scope and would not exist at go-live, and that the legacy 2010 workflows would keep running but without Microsoft support.
The results
The PMO stopped running its programme schedules on an out-of-support platform and, more useful day to day, acquired an accurate picture of what it actually had: a live-project list reconciled against the server rather than the last time anyone counted.
The one project that did not migrate cleanly was reported as exactly that, with a commitment to resolve it the following week. On a 222-project migration that sentence is worth more than the 221.