Deploying many Orchestrations - StaticStateInfo A Table To Know About

I'm doing some work with a customer this week who had an excessively large staticstateinfo table (more than 60,000 rows) in their BizTalk Message Box.  The table contains static Orchestration information, to be loaded at runtime, it has a row for
each deployed orchestration.  While the size of the table posed no immediate concerns the customer wanted to understand why the table grows bigger and how they could stop the growth.

The reason this customer had such a large number of rows is because they had several hundred Orchestrations deployed to their environment, but they ALSO had over 100 versions of each of these Orchestrations deployed to their environment.  These Orchestrations were no longer used. Because BizTalk only removes the information in the static state info table when the Orchestration version is actually removed from the group, their table was getting bigger and bigger and bigger....

Versioning of your Orchestrations is a very common and often required scenario, when implementing this you should ensure that once a version is no longer used or required it is removed from the system.  Doing this will decrease the size of the static state info table and also reduce the number of artifacts you have to manage within BizTalk.  Reducing the number of artifacts you have to manage makes administrating your system easier (especially in BizTalk 2004 where there is no 'application' grouping).   Therefore please make sure you consider how and when you are going to perform this undeployment right from the moment you decide to implement versioning of your Orchestrations.