Without seeing the template you're referencing, I expect it's like the introduction section of a lab report: the introduction section introduces the report not the experiment that the report is about.
The Software Project Plan will have a different purpose from the product you're making. And the purpose of the product you're making should be defined in a ...
An elapsed month (emon) is always 30 elapsed days long (i.e. 30x24 = 720 ehours). Since 12 emons = 360 days, not 365, your schedule will fall 5 days behind each year. There is no unit of duration in MSP that aligns with calendar months.
I would say that if we keep in my that the WBS is (amongst others) a communication tool, I will at the planning deliverable leg, if this helps to manage stakeholders expectations or if it reassures them.
In any case, as PM, the planning leg is something you must do. Whether it is in your WBS or not.
However, I would use a more generic name, and I will ...
I have some experience with migrations. What I can suggest is the following.
FIRST and very first, create a product oriented work breakdown structure. Don't do this alone, do it with the support of the team.
About the WBS, I'd put in the first level of my WBS the following:
Website: So you can decompose further the features to deliver (frontend, ...
The production schedule shown at the top of the question is suitable for continuously selling products where the aim of the production is to keep the stock levels in the warehouses stable.
If you instead you have jobs that must be produced in their entirety before date X and then it is done, then I would use a different planning technique. For each job, a ...
To create a project schedule for my projects, regardless if they are agile or not, these are my first 6 steps:
Open the latest version of you work breakdown structure to outline the schedule
Ask to your team what needs to be done to deliver what is in the work breakdown structure
Identify with your team in which sequence they suggest to do the activities