Services must be able to adapt to the changing needs of the consumers. Managing the inevitable changes is the focus of Service Evolution.  As a service becomes more popular, it typically becomes more difficult to change because it may have an unwanted effect on the consuming applications.  

It is recommended that a change plan be developed for a service. The plan identifies the process for rolling out changes. It identifies things like: How will a critical bug be resolved? How much notice will consumers get on new versions? Will older versions be sunset? The change plan acts as procedural contract between the service owners and the owners of the consuming applications.

Each service will have a roadmap that identifies bug fixes, new features, etc. This roadmap is shared with the consumers of the service of the service so that they know when new versions are coming.

Consuming applications will have new requirements on the services and those requirements must be sent to the service teams in the form of 'change requests'. Service teams are responsible for evaluating the level of effort to make the change and the time/costs associated with the change. If the change is deemed acceptable by the service team and the requesting party, then the service team must determine if the change will have a negative impact on the other consumers of the service. This process will typically involve the SOA governance team to review cost/benefit and risk/reward of making a change. 

In some cases, there will be business justification for making a change to a service for one consumer while not forcing other consumers to move to the new version. Although this is undesirable, the business reasons will often override the technical implications. In these cases, the older version of the services are often given a time-to-live (or expiration) before they are turned off and consumers will be forced to migrate to the most recent version. In other cases, the service may be forked creating two distinct services that must be maintained individually. Again, the goal is to avoid forking but the business need may deem it necessary. 

This process must be managed carefully with the appropriate communications, reporting and sign-off's. Change activity reports are generated to give all parties visibility into the historical view of changes.