Some hints I have learned about ActiveVOS (BPMS solution) so far

If you expect many long running processes (or what is worse human tasks) set the system logging level to none and define the logging for each of your process separately

Process logs can take a lot of your database storage. Especialy the logs for human tasks.
Not that they wouldn't be big if we would take a look at them separately. One log will take only few bytes. The problem is that there are many of them.
From our measurement we had approximately around 5500 log records for one human task which could consume almost 1MB of logical datastorage. As the system process are using the default logging level then by setting it to none you'll be rid of this problem (as you'll almost never need the logs from system processes - event the support never wants them).

Try to avoid architectural design based on manual process fixing in case of failure

One of the biggest advantages of ActiveVOS is that you can set the logging to full
level for any of your processes and once there is a failure you can return to any
point of it, fix some data and continue from there as if nothing happened.
The disadvantage is that once you overuse this "pattern", the maintenance cost of your solution will heavily increase as you'll always need some additional guys that will fix your failed processes from the point they arived into the office
(but that of course depends on the number of processes you're dealing with).
I am not saying that you should absolutely omit this pattern but I suggest that
you should always look if there is no additional automatic solution.

Be prepared that some things won't work

Nothing is perfect and ActiveVOS (even when it provides a cool solution) has some of it flaws. So be prepared that in some cases you'll end up with a workaround. To just name some that we needed here is a short list:

• XQuery methods "instance of" and "typeswitch" are not working properly in once you want to check an element type that might come from a hierarchy of types. The problem is that the saxon library which is underneath is not providing this functionality. The same goes for method like "rename".
• If you're using asynch calls with WS-Addressing than the timeout policy is not working if you'll define it on reply activity.
• If multiple wsdl files in one process are using the same namespace then they must be merged. I don't know how it is in newer versions (we lastly used this feature in version 6.2), but the eventing can show some unexpected behavior once used in clustered environment (but as said this might be already fixed).

But don't be afraid as these are some minor issues for which you can surely find a workaround and might be fixed over the time.

Don't use human tasks as mere notifications for FINAL task that needs to be done

From collegues project I have the experience that the people forget to close these FINAL TASK "notifications" once the work is finished as for them its not as important (because they have already a new notification/task that needs to be done).

Even the management doesn't care as everything has been done/finished, so (from the bussiness point of view) who cares that the process was not closed.

This creates not only confusion about which tasks are finished and which not (sure the user knows), but also makes a heavy usage of the database as unfinished system processes that run the human task can consume much of the database storage and can't be deleted if we wan't to decrease the database size.

Try to get all your important business data out of your processes and store them into
separate database before the process ends

Currently there is no archivation mechanism (of what I would know) that would allow you to archive only a part of your processes (for example completed ones) and leave other in tact.

The only thing you can do is archive your ActiveVOS database as a whole.
And than recover it as a whole.

This can be very tricky as it prohibits any incremental recoveries or storages (you can write it on your own, but than you'll loose the support - and which customer would be willing to loose that) and would work create a backup when you have a great mix of completed and running processes. You'll probably get to this problem once you'll have many finished processes as they can cost a lot of database memory (in one big project we're already over 600GB !!! of Oracle database). The best thing how you can prepare yourself for this is to a create some persisting activities in your processes, that will gather all meaningfull informations and store them into separate database. This way once you'll encounter some problems with database space, you can easily delete some of your old completed processes.

Oh and don't forget to put them in the first version of your processes as your deletes can be only used for processes "older than" (so forget defining time range from - to) and you wouldn't be happy if the oldest processes without persistence mechanism would be deleted/sacrificed for the sake of the database (as you must delete the newer versions).