1. Crossing over to a SaaS option from your legacy
solution, look before you leap.
You’re the Application Portfolio Manager foryour Enterprise and all of your key software
suppliers are introducing you to their new “cloud variant” of the solution you’ve been running for
years in your data center. All of the CIO journals and other IT trade publications you reference are
encouraging everyone to run to the “cloud” as fast as you can, otherwise you’ll lose your
competitive edge.
There is nothing inherently wrong with getting a little excited about the potential advantages of
cloud-based computing, but you’re an IT Sourcing Pro and you know “the devil’s always in the
details”.
Converting from a traditional technology to a product as a service from the cloud requires a
dramatic departure from how most companies are run today.
Whether it’s Microsoft, Oracle, SAP or IBM reaching out to you with their hosted versions of
Productivity Suites, CRM, ERP or HCM, getting to the cloud painlessly is just not a reality you
should be diluting yourself with.
While the many technical and architectural aspects of a migration froma legacy on-premise
workload to its cloud-based variant must be considered, we’ll focus here on the User and
licensing implications of such a migration.
Let’s start with a few basic areas of interest…
The business model.
With virtually no exception, you are moving to user-based licensing, all of the other traditional on-
premise licensing modalities such as CPU, Core, MIPs, Device, Server, Site license or other no
longer apply.
Consuming your legacy on-premises workloads as SaaS will likely introduce other new pricing
items such as Storage, Network, and Redundancy support, as well as new costs forany special
developer needs your workload(s) may require.
All of these costs typically take the formof a monthly subscription fee and expose many service
options that end user organizations will have to properly align and assign to their teams.
The change management model.
Common to virtually all SaaS-based offerings is the absence of product versions or versioning.
User Experiences, as defined by the interface they work with, are completely under the control
and management of your SaaS provider. Updates are delivered by the SaaS provider when they
are ready and users will need to adapt to changes in UI or functionality on the fly. Since real-time
new feature access is considered one of the principle benefits of SaaS solutions, organizations will

2. need to understand well in advance when changes are scheduled to be released and whether or
not such changes can impact any downstream integration with other systems or customizations
they use in combination with the SaaS solution.
The Subscription offerings and alignment with Use Cases.
Your SaaS provider’s solution carries cost to them they never had when they were simply
providing you a license to use their IP. As such, these providers have typically built out features to
their offerings that are carefully selected and SKU’d to a number of user subscription options
(personas). As you would expect, the personas attempt to mimic broad use cases from entry-level
to high-end and many points in between.
Because the margins associatedwith services and subscriptions aren’t quite as hefty as the
margins associated with licensing only the Intellectual Product (IP), the arrangement of SaaS
features and the personas they are provisioned to are carefully tweaked to the SaaS provider’s
advantage.
Any organization which runs SAP solutions knows quite well the challenges they have
encountered with ensuring proper alignment of SAP User types with their personnel. This same
challenge now is part of most SaaS solutions as organizations must assess their internal use cases
and align those needs to the way that the SaaS provider has provisioned features to their
subscription offerings.
The contract model.
Thought and preparation around the contract model are critical. SaaS providers are driven to
provision their most robust subscription licenses in order to maximize their shared resource
infrastructure. They have carefully assigned features to each of their subscription offerings in
order to give the appearance of multiple personas, however, they have gotten very clever when
building out the lower-end subscription offerings by carving out those 1 or 2 features which force
users to enroll in a higher level subscription.
As with many other user-based models, what organizations oftenfind afterthe fact is that their
use cases aren’t always what they thought they would be. For example, there are many cases
with SAP where organizations have unknowingly over-licensed users with premium subscriptions
only to learn months or years later that those users are rarely, if ever, leveraging all the features
assigned to the user subscription type.
When contracting for any SaaS solution that exposes several personas forthe same workload,
your contract needs to take into account the likely possibility that your initial user subscription
distribution may not be completely appropriate or accurate. Being able to audit the actual
activities your users are performing and then making subscription modifications during the term
of your contract is critical.
Being able to “step down” your subscription types froma higher-level persona to a lower-level
persona is a “must” and depending on whether or not you have paid for unused benefit with
respect to those higher-level personas, there needs to be a credit-due outcome that can be used
against future subscription payments.

3. Most, if not all, SaaS solutions provide mobility options that accommodate access from non-PC
form factors such as Smartphones and Tablets. All of those extended access options should be
part of the primary user subscription and not treated as an “add-on” with its own separate cost.
As mentioned earlier, since SaaS solutions are constantly being refined and updated, it is
important to require reasonable notice from your provider about any changes to the solution that
are planned 6-12 months before such changes go live. While SaaS providers may push back on
such notice, smart organizations will insist on contract language that provides reasonable notice
and may also wish to have the option to defer receiving any updates if they are concerned about
negatively impacting any integration they have working with the SaaS solution.
As a final recourse to the above, you should ensure that in the event that a pending update to the
SaaS solution may cause material disruption to your operations, that you have a termination for
convenience exit option. Along with this exit option, it is wise also to secure some level of
termination assistance if this same workload needs to be brought back into your datacenter.
Service Level Agreements in the SaaS world tend to favorthe provider, however, if this workload
is currently licensed fromyour SaaS provider as an on-premises solution, then securing service
credits to be applied to future subscription payments if SaaS uptime drops below a negotiated
threshold is completely reasonable
Return on Investment
There is no comprehensive proof that spend for a SaaS solution is going to result in any major
savings when compared to its legacy on-premise alternative. Having said that, the velocity of SaaS
new feature access and the potential benefits that arise fromtheir use could increase yield from
this workloadrunning in your datacenter.