Service Versioning vs. Service Migration

My article on SOA Governance, "Introduction to SOA Governance," has lead to the following question:

They're related, but not the same. They can be used together, or separately.

Versioning is something the provider does. Migration is something the consumer performs.

Versioning enables a provider to change the service and make that available while keeping the unchanged service also available. Migration changes the consumer to stop using a version of a service and start using either a different version or perhaps a completely different service.

There are two motivations for why to do migration:

• New functionality – A new service or service version has new functionality the consumer wants.
• Staying current – The consumer doesn't want any new functionality, but wants to use the latest and (presumably) greatest.

There are two impetuses for when to do migration:

• Voluntary – The consumer doesn't have to change, but decides to, perhaps to make changes when it's convenient to and to try to stay current to avoid being forced to make changes at inconvenient times.
• Compelled – The consumer must migrate, even when it's not convenient, because the providers are deprecating and sunsetting the service. Some consumers might never migrate otherwise.

So you could use versioning exclusively, just creating new versions with new behavior but continuing to support old versions forever and never needing to migrate. You could use no versioning, creating a new service every time you want to change an existing one's behavior. Even with no versioning, you could still use migration by changing the consumers to use the new service.

Think of an IBM product like WAS. It has versions, which IBM produces. And WAS customers have to migrate every couple of versions to stay on supported product. IBM produces the versions; customers migrate.