Why?

Overall solutions

Reasoning

Harvest Control Manager Component

The API should make it possible to redo certain operations which occasionally fail and require manual intervention.

Only when the worst happens should i be required for a person to fiddle with the server.

The existing code in the harvest control manager that must be migrated into one or more plugins.

The plugins can form the base for other people adapting the code to suit their own needs.

The only state the manager should know about is it's harvest.

Everything else is up to the caller. This way you can use "channels" or not. And more importantly you can manage "channels" dynamically without having to reconfigure and redeploying harvest controll managers.

Job Scheduler Component

GUI

Indexing Server

Deploy package

Restructuring tasks

Component platform

Prototyping

Since it is a daunting project to just refactor everything it would be best to just start with the harvest control manager and see how easily it can be turned into an independent component.

Depending of how this works more of the restructuring tasks can be done in an other that makes sense. However reworking the Job Scheduler for work with the new control manager component is probably the most logical step.

The order should also consider refactoring parts of the code that would eliminate long known bugs or other areas that have not been focused on. Such as manual workflows.