When you deploy a new version of a Web service, you must plan for transitioning existing consumers to the new version. The approach you use depends on how you intend to add the new service to your existing operational environment. You might, for example, choose to host both the old and new versions of the service for a period of time. Or you might require existing consumers to upgrade to the latest version of the service, and then, at an agreed upon hand-over date, replace the existing service with the new one. In either case, you should take steps to proactively notify existing consumers when a new version begins its development lifecycle so that they can take steps to adapt to the changes as necessary. You can use CentraSite to identify the existing consumers of the service and notify the consumers manually or you can create policies to do this automatically when a new version reaches a particular state in its lifecycle.

After a new version of an asset is placed into production, new consumers should be discouraged from using the older versions of the asset. Applying a lifecycle model that includes the Deprecated state is a good way to indicate to users that an asset has been replaced by a newer version. As a best practice, you should always switch an older version of an asset to the deprecated state as soon as a new version of the asset is placed into production.