Forum Discussion
MS Project Master file won’t allow Duration/Deadline edits
Hi Tom, what was the process you used to migrate your schedules from the POL cloud environment to the Project Server On Prem environment? We've completed a bunch of these migrations and in our experience there's an important 'order of operations' for how schedules need to move from POL to PS SE, so that things like enterprise fields, resource assignments, etc. map and function properly. Based upon your input we'll provide some guidance. For instance, when you moved the individual sub-projects, did you create a new project in PS SE and copy the schedule into that new project, like you noted you did with the Master?
Also for any calculated fields you are using, are they Enterprise Custom Fields or the out of the box roll up fields (like work, duration, etc.), and how did you migrate those between environments?
Master projects can be tricky to work with, esp during a migration effort. Breaking your individual schedules down and migrating and validating those individually, after you've updated your PS SE configuration to match what's in POL, is a good starting point. From there, you may need to re-build the master, as in Project a master is really a separate project schedule that includes a set of sub-schedules (which you clearly already know from your note above). Esp. if your links go across projects, those 'pointers' are stored in the POL database attached to specific task UID. If those UIDs change or are published as new UIDs in the PS SE system, it's highly possible you'd break those links when you do the migration of each schedule, and esp within the master, which is just rolling those projects up.
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.