Classic BPM supports a distributed architecture where specific steps in a model execute on a particular Integration Server. This is done by assigning logical servers to steps in the model. The model is generated into a fragment for each logical server. Each fragment only references steps associated with a particular logical server. At run-time, only the steps known to a logical server will be executed for a process instance, effectively distributing the execution of the model across any number of Integration Servers.

The use of this feature is common, but requires a fairly complex messaging configuration to ensure that transition events are handled by the appropriate BPM node. This configuration is can cause issues and difficulties during installation and when configuring new BPM instances in an environment.

Dynamic Business Orchestrator treats the model definition as a single unit that cannot be fragmented. The concept of logical servers in a Dynamic Business Orchestrator model does not exist. Every Dynamic Business Orchestrator node has full visibility to the model and requires that the model can be executed on a single Dynamic Business Orchestrator node. In other words, all Integration Server namespace artifacts referenced by a Dynamic Business Orchestrator Process model have to exist on the Integration Server executing the model.

Prior to executing a classic model that uses the distributed architecture migration utility, the machine hosting Designer must be connected to every Integration Server referenced by the logical servers in the model. This is necessary so the migration utility can query those assets for the creation of maps that are stored in the model.

Upon migration, the Dynamic Business Orchestrator model will no longer have references to logical servers and will expect that every model dependency exists on every Integration Server node that is designated to execute the model.