Just to note something with regard to long processing times in workflow, you can drastically increase processing times if you use invoked child workflows with iteration limits and make the updates in parallel batches.

Depending on how your workflow server is configured you can run multiple parallel processes without any performance degradation.

Basically,

1. Create a workflow that runs a Search Repository activity but set it to only return a limited number of results because too many loop iterations will cause the instance to slow down over time (I usually opt for a max of 250).
2. Set an input parameter that you can use to separate your batches
3. Set an output parameter to return the result count of the search
4. Configure a search for documents with the template you want to change and loop through to update the template.

To handle the batching, you could use advanced search syntax to search for not only the template, but an additional value so they can be grouped.

For example, maybe run them in 10 parallel batches based on the last digit of the entry Id with syntax like this

{[TemplateName]} & {LF:ID=*0}

Then you can use the input parameter instead of a static number so parallel instances can work on separate groups without overlap.

{[TemplateName]} & {LF:ID=*%(Input Parameter)}

Just make sure you don't send a blank/empty input parameter because that would cause undesirable results in the search.

Next, you create the "parent" workflow

1. Create a workflow with multiple branches for the parallel batches
2. Add a Repeat activity to each branch
3. Add an Invoke Workflow activity inside of the repeats
   1. Set the input parameter for each distinct branch (for example, if you use my earlier example you could do 10 branches passing in 0-9 as the input)
   2. Make sure "wait for workflow" is checked so it waits for the results and gets the output value
4. Set the Repeat activity to check after each iteration and set it to repeat as long as the output of the invoked workflow (i.e., how many results were found in the search) is greater than 0.

The reason most workflows like that take so long is that the more iterations you have, the more data is collected, and eventually it starts to impact the instance. For example, you might start with it taking milliseconds per document but after 1,000+ iterations it might take seconds or even minutes each.

By breaking it up into child workflows you can limit how much is handled by each instance to avoid the performance degradation, and by breaking it into parallel branches you can increase throughput significantly.

There's no "hard limit" on how many iterations will cause performance to slow down because it depends what activities are being run and how much data is accumulated, but as a general rule-of-thumb I try to limit things to no more than 250 iterations per instance.