Tables, stored procedures and DAV collections may be added to a transactional publication. When a table is added, triggers are created for capturing changes to the table. When a procedure is added, all calls to this procedure will be recorded in the publication's log and the same procedure will be called on the subscriber. When a procedure is published in this manner, actions performed inside the procedure are not themselves recorded even if they touch on items that are part of a publication. It is assumed that the procedure on the subscriber will produce the equivalent effect. When a DAV collection is published, operations on direct and indirect members of the collection are logged into the publication's log. When this is replayed on the subscriber, the operations are repeated on like-named DAV resources, creating collections and resources as needed.

When a table or procedure is added to a publication, the creating statement is added also, so that the subscribers come to create the table or procedure before receiving any replication operations on said table or procedure. Also when the table or procedure is altered, the altering statements are added to the publication so s to be reflected on all subscribers. This can be overridden for procedures, since in some cases it is desirable to have a different definition on the subscriber. Table constraints are also replicated, except for foreign key constraints with tables outside the publication, since these would not be meaningful on the subscriber, as there is no knowledge on what tables may exist there outside of the ones in the publication. Changes to schema on subscribers are never replicated to the publisher, even if we had bidirectional replication. Identity and timestamp columns are replicated so that the values on the subscriber are assigned by the publisher.

When a procedure is published, it is possible to specify whether the definitions, calls or both are replicated. Usually specifying both calls and definition is reasonable, sometimes only calls are to be replicated if the procedure intentionally has a different definition in the subscriber. This is useful for example when the subscriber gathers statistics or maintains a data warehouse where the storage schema is not identical with that of the publisher. Only procedures with input parameters can be replicated. The rationale is that replication is a one way stream and no return values, result sets or output parameters can be captured by either publisher or subscriber. Procedure calls cannot be replicated bidirectionally, these go from publisher to subscriber exclusively.

Even though replication can carry schema changes, it is in no way a means of keeping software installations in sync. Many schema elements such as triggers are not covered and a software upgrade is more complex than can be represented by replication alone.