Forum Discussion
MS Project Master file won’t allow Duration/Deadline edits
I apologize for the long wait for the reply. I spent the week trying to troubleshoot this to give a more robust reply.
Here’s the method we used when migrating files from the legacy server into the on‑prem PWA environment:
- Opened the project on the legacy server.
- Saved the MPP down to a local drive using a macro (a more sophisticated Save As that preserves custom field lookup tables).
- Ran the standard import wizard steps just like we would for a file that had never touched PWA.
What I’m seeing now is that this Save As approach must have carried enterprise metadata with the file because in the Organizer I’m seeing enterprise fields show up in the Master, despite the Master itself never being connected to PWA. Those enterprise fields appear to be the source of the corruption when I try to insert the on‑prem version of the subproject.
I narrowed it down to enterprise fields because I ran a series of tests where I selectively migrated views, tables, filters, and fields from the old Master File into a blank project via the Organizer. After each category, I attempted to insert the On Prem subproject into the blank master File. The environment only became corrupted once I migrated the full set of fields from the old Master into the new.
Could you help clarify:
- What the correct order of operations should be when migrating files from a legacy environment into on‑prem PWA?
- And is there a proper way to take a PWA‑connected file and turn it into a completely clean offline MPP (with no enterprise fields or server metadata) before inserting it into a Master?
Thank you for your help on this topic.
Hi, in our experience there's definitely an 'order of operation' that needs to be established and followed for this to be successful. Some guidance on this from our team:
Our suggestion to TEST/PROOF OUT would be to NOT elect to bring in the full list of enterprise custom fields when saving the schedule as mpp. when choosing the keep the enterprise fields, the save does not capture the values in these fields anyway, so I've always wondered what benefit this selected option provides.
Then, when you then import the mpp into the target system, it has ECFs there that will be provided to the imported project, presumably without any field name overlap, and the user could then manually enter values for these enterprise fields.
The process would follow something like:
- Inventory before you move anything - capture a cross-project link register, values for enterprise custom fields in use, tasks unique to the master (that are NOT part of the sub projects)
- Stage the target PWA environment - include ECFs with identical details, lookup tables that match, calendars, resource pool, EPTs, RBS, enterprise global, etc. The target environment needs to match the source.
- Extract the data - Open sub projects individually, save as local .mpp with the same exact filename as the enterprise project, save the master locally just for reference purposes (to rebuild later), make sure to save as .mpp not another format
- Build a link strategy - either break and rebuild based upon your register, or preserve and 'pray' the links re-establish. The first is the most reliable strategy.
- Import subprojects first from the Pro desktop client w the Import Wizard, map resources local to global, local fields to ECFs, calendars, publish the schedules.
- Rebuild the master - reapplying cross-project links
- Validate - run a Report - Compare Projects in the local source local .mpp vesus imported enterprise version. Check dates, critical path in the master, baselines, actual work and cost, constraints, etc.
We've seen this process can work, there are gotcha's throughout the process but this provides the framework for the move of schedules that are part of masters to the new system. DM me if you are looking for hands-on guidance as we've been doing these migrations for a while now, and have some tools we use to move the PWA Configuration and Resource pool in a 'semi-automated' way, as well as ways to support report and data moves.