Playbook | Move Tasks to Another Project

Now, tasks can be moved from one project to another, while maintaining the lifecycle of all tasks.

1. When both projects are loaded in the Game Plan, you can move one or more tasks from one project to another (Target Project) by selecting and dragging them in the Task Grid.
   
2. When dragging a summary task, it and all its subtasks are moved to the Target Project.
3. The lifecycles of all tasks are maintained (Sandbox, Planned, Active, Completed, Archived).
4. If there is a link between tasks and one of the tasks isn't moved to the Target Project, a Cross-Project Link is created automatically.
5.  If you attempt to move tasks assigned to resources that are not assigned to the Target Project, and you are not the Target Project Owner or a Playbook Administrator, you will receive an error message and will not be permitted to continue.
   
6.  If you are the Target Project Owner or an Admin, you will receive a warning with the option to assign those missing resources.
   
7. When dragging a project, a new Top-Level summary task is created in the Target Project and the tasks are moved to it, while the original Project remains.
8. The main use cases for moving tasks to another project are (so far)...
   1. Splitting up large projects into smaller projects, for example...
      1. A project with ~2000 tasks can get a little laggy. Splitting them into multiple projects improves performance. Those could be ‘real’ tasks in a big project, or….
         1. Perhaps we have many what-if scenarios that we want to keep, but don’t want all of those extra tasks slowing down our project. Moving the what-if scenarios to another project is faster than copy/pasting them, and maintains the timing better because the links remain intact.
         2. Perhaps we have a ‘Misc’ or ‘Sustaining’ project that lasts for years and has many thousands of archived tasks. When we load all archived tasks, it can get a little laggy. We could move the ones from 1 or 2+ years ago to another project (instead of deleting them).
   2. Combining related small projects into a single larger project...
      1. Sometimes after planning things as separate projects, we realize they are related and decide we want to put them into the same project.
      2. Sometimes some of those tasks are done already and we want to maintain the lifecycle history (which we would lose if we copy/paste them).
   3. We accidentally created or pasted tasks in Project A when they should be in Project B.
      1. Moving them is faster than copy/paste.
   4. Moving tasks to another project can be a shortcut to assigning resources to a project (see #6 above).
9. The main differences between Moving vs. Copy/Paste...
   1. Active, Completed, and Archived tasks stay at their current lifecycle whereas Copy/Paste sets them all to Planned by default.
   2. Any Active/Completed/Archived task segments with customized "hours per day" are maintained on a Move. With Copy/Paste, they are reset to the "average hours per day".
   3. The Change Log is maintained on each task on a Move, whereas Copy/Paste creates a whole new task and Change Log.
   4. When tasks are moved, the start/end dates are maintained exactly. When Copy/Paste, by default, all ‘Start on’ tasks get switched to ‘Earliest’, which removes any spacing you added between tasks. You can set it to maintain the spacing, but you have to remember to.
   5. If you are moving tasks to a project that the resources aren’t assigned to yet...
      1. If you are an Administrator or the Project Owner of the project you are moving the tasks to, you can assign those resources during the Move.
      2. If you Copy/Paste to a project the resources aren’t in yet, you have to Cancel, go to Admin, assign the resource(s), browser-refresh the main site, and then start the copy over again. If you aren’t an Admin, you have to get in touch with an Admin to do it. Or leave the tasks unassigned and come back and reassign them later.
10. Need a hand? Contact a Customer Success Engineer today!