SaaS-querade: When On-Premise Vendors Try to Pass as SaaS Vendors

SaaS-querade: When On-Premise Vendors Try to Pass as SaaS Vendors

Summary: On-Premise software masquerading as SaaS? Who would do such a thing? Well, just about every on-premise apps vendor is SaaS-querading these days and customers could be the ones who get burned.


Customers who don’t see through the fakery will get stuck with old, expensive solutions

Lately, my phone and calendar are getting filled with calls from vendors who want to tell me all about their re-purposed, on-premise applications. The calls have a few familiar aspects but they’re all masquerades. And, mostly, they’re bad for software users.

First, the pattern:

An on-premise vendor, seeing softness in new license sales numbers, starts to (finally) realize that Software as a Service (SaaS) is real. So, the vendor decides that a ‘hosted’ ERP application is a close enough facsimile to a SaaS solution. All the hosted product needs is a bit of SaaS marketing and it’s a done deal. Right? Wrong!

A dear friend of mine is a software marketing pro. She told me that her ERP product is about to get a big splashy marketing campaign announcing its SaaS credentials. I immediately said that this can’t be as its an old school ERP product that the vendor sometimes hosts. She replied that whether the solution is hosted by the vendor or in someone else’s cloud is immaterial to a customer.

That’s really wrong on a number of fronts. To begin with, a hosted on-premise product is likely not a multi-tenant solution. Multi-tenancy permits a vendor to apply a software upgrade once and have it automatically work for dozens or hundreds of customers simultaneously. In a single tenant solution, the software vendor must apply the changes one customer at a time. The latter approach is very expensive and potentially error-prone.

My good friend said that this argument (multi-tenancy) is immaterial to the customer as the responsibility for applying upgrades is the vendor’s problem not the customer’s. Again, this is wrong. This leads to the second point: When solutions are not multi-tenant, they will be more expensive to upgrade and the vendor must either pass those costs on to the customer or the vendor must be willing to offer few upgrades to the product. Seriously, who wants a product with a built-in cost disadvantage? Who wants a product that a vendor is disinclined to upgrade? No one does. Multi-tenancy is a necessary component to true SaaS solutions if the customer is to get frequent upgrades and a lower cost solution.

Other on-premise vendors are trying to convince me that their SOA (service oriented architecture) stack is also a Platform as a Service (PaaS). This is another marketing stretch. A SOA stack is good for integrating other applications and technologies with on-premise applications. While these integration capabilities are desirable, they are a far cry from the cloud-enabled, rapid development and extensible platforms offered by Salesforce (i.e., and NetSuite (i.e., NS-BOS) to name but a few. Those platforms are so powerful, third parties have built huge new product lines that are tightly integrated with the core offerings of the PaaS provider. A PaaS is more than integration. PaaS permits users, resellers and others to develop entirely new applications.

Other on-premise vendors are trying to pass off a workflow management capability as a PaaS. Again, this isn’t true. Most workflow management tools allow a customer to alter workflows and other functionality in a pre-existing software package. These tools rarely offer a full development platform that permits the creation of all-new applications. To that end, I’ve seen firms build entire MRP, harbor management, accounting and other solutions using a PaaS. You’re not going to get that far (easily) with a workflow tool.

The hype machinery is also going full-bore to convince software buyers that SaaS-enabled applets or bolt-on applications around older on-premise applications are a great value or proof that the vendor is delivering on SaaS. That, too, is a bit of a stretch as the cloud-based applications may possess different technical architectures than the on-premise applications they are supposed to work with.

Those architecture differences could make configuration changes a challenge. Suppose you want to tailor the new cloud-based application. Will its configuration changes work with the old on-premise product? Probably not. Those changes will need to be replicated with a different set of tools in the on-premise application. And, that’s assuming those changes are even possible in the older products. This spring brings an exceptional level of FUD (fear, uncertainty and doubt) to the applications world.

And, I fear the FUD will continue to grow at an exceptional rate. Software buyers really need help now. The misdirection and misinformation may create too many opportunities for bad decisions. Sir Walter Scott may have had it right in 1808 when he said “Oh, what tangled web we weave. When first we practice to deceive.” I think he’d want to update those lines today…..

Topics: Data Centers, CXO, Cloud, Emerging Tech, Software, IT Employment


Brian is currently CEO of TechVentive, a strategy consultancy serving technology providers and other firms. He is also a research analyst with Vital Analysis.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Another point - scalability

    Thanks for calling out the posers.

    You're point on what it takes to have a SaaS platform to actually a real business app is spot on. In our space of enterprise content management, we've started making the line in the sand
    - the kinds of skills it takes to deliver something useful (if your platform requires a programmer, you might just be a poser)
    - how long it takes (if a project plan for your platform is measured in months you might just be a poser)
    - how many different people are involved (if your platform's projects require a project team that involves 6 people in your company you've never met before, you might just be a poser).

    Another point though is scalability. We're seeing companies come to us who have tried their vendor's SaaS poser app because it seems comfortable, only to see it run out of gas long before they hit their needed volumes. This relates to things like multi-tenancy, operational expertise, etc.

    You quoted a literary figure, and I used Foxworthy, so Ill end with a the literary version of the phrase we both used in the early days of client/server and more recently by our now president: "You can clean up a pig, put a ribbon on its tail, spray it with perfume, but it is still a pig."
  • It's about control.

    The biggest factor here is likely control, not

    Companies are by nature conservative, and no
    they do not like upgrading constantly, no
    matter where it is hosted.

    They also like to have a level of control - and
    they hate having the upgrade cycle out of their
    control. The last thing they want is for
    something to break in the middle of the day
    because the vendor pushed out something that
    was still buggy.

    Plain and simple: They want to update when they
    say so, not when the vendor says so. They want
    to test before they upgrade.
    • SaaS upgrades vs on-premise

      SaaS vendors typically offer a means for controlling the introduction of new functionality. Such as turning new features off by default and allowing the customer to enable them when they are ready. My department deals with a number of SaaS vendors and have been through many upgrades without incremental expenses or negative ramifications.

      With SaaS there is a steady stream of new functionality being added with minimal effort.

      By comparison, the last time our on-premise ERP system was upgraded the project took over a million dollars in consulting and a team of people 15 months to do it. The next upgrade will be deferred for as long as possible to avoid a similar expense and effort.

      An IT organization should focus on adding business value and not get caught in a recurring cycle of upgrading existing solutions. I view an on-premise upgrade to stay on a maintained release a waste of money that benefits the vendor more than the company.

      Joe Graves
      Stratus Technolgies
      • Is there a risk?

        I agree with you in that upgrading a solution because your current version may lose vendor support can be a waste of money. I guess the question is how risky is it to lose that vendor support?

        I have worked with a number of companies running unsupported versions of software. I have been called to do upgrade assessments for them and, from my experience, it comes down to the following:

        1. Is the current solution you have continuing to add value to the business? If your system supports a core process or processes and continues to provide a cost efficient means to an end, you may want to consider passing on the upgrade.

        2. How strong is the internal team supporting the solution? If your team has proven successful at managing the service the solution is delivering with little help from the vendor, again, you may not need the upgrade. An examination of Service Desk incidents against the solution and support tickets from the vendor's support records will be good indicators. They should give you a good idea of how much risk you would be assuming in operating without vendor support.

        3. Is there functionality in the latest version that would add more value than the cost of the upgrade? While the first item I noted above looks at the current standing and the second looks at the past, this question is forward looking. If there are capabilities that the newest version features that allow you to address current or imminent requests from the business (regulatory compliance comes to mind), then the upgrade may very well be worth the time and expense.

        I think the three points above provide a sound scorecard for determining whether or not an upgrade is necessary.
  • Some numbers on the topic from Softletter

    A preview of the April issue of SaaS U Journal:

    These numbers are pulled from Softletter's forthcoming SaaS Report. This is the fourth year in a row we've conducted the survey from which the report is based. In the first year, the numbers for mult-tenancy were almost exactly reveresed; nonetheless, the SaaS market grew strongly in this period.


    Are your SaaS customers served by a centralized data architecture (multi-tenancy) or do you have separate databases for each customer?

    Centralized data architecture: 61%
    Separate database for each customer: 24%
    We provide both options: 14%
    Other, please specify: 1%

    We think these numbers are important because they contradict a major theme promulgated by many SaaS consultancies and pundits; SaaS systems must incorporate multi-tenancy to be "truly SaaS." As these numbers show, this is clearly not the case; currently, 38% of our respondents either don't offer multi-tenancy or provide it as an option.

    Don't get us wrong; we think there are excellent business reasons to incorporate multi-tenancy into your products; the ability to mine that data created by customer interaction with your SaaS system is an excellent marketing reason, never mind the technical challenges of scaling out with a single instance infrastructure.

    But there are many markets that don't want or strongly object to "co-mingling" their data in any common or integrated data object. In these cases, many vendors have made a business decision to give their customers what they want and to not concern themselves with religious debates over technical purity. To almost all customers, SaaS is defined by three simple factors:

    I don't buy a license for this application.
    I don't install it on my hardware.
    I pay for in on a recurring business.

    That's it. Companies that attempt to redefine SaaS as something more than this are usually consultancies trying to sell something or technical purists who enjoy theological tussles. It's the customer and/or your market that will determine the importance of multi-tenancy in your sales and marketing efforts. For most of them, its presence will simply be a "tick list" item as relational databases became in the 80s, when everyone advertised their DBMS as relational while few customers ever cared (or understood) exactly what that meant.

    rick chapman

    By Rick Chapman Managing Editor and Publisher at Softletter
  • RE: SaaS-querade: When On-Premise Vendors Try to Pass as SaaS Vendors

    Here at Birst (, we see this on a regular basis. A company comes in thinking that the big traditional BI vendor's new "SaaS" offering will provide the same value that we do - fast to get started, scalable, easy to maintain, full BI features, etc. But then they find that it's not true SaaS, it's not easy to get started, not easy to maintain, it's actually expensive, and the vendor gutted the features in order to get it out there.

    And then they come and talk to us, or another BI vendor, because getting rid of the BI headache and having manageable BI costs is actually what they wanted, and we're the ones who can deliver.
  • That needed saying - and one other thing !

    Thanks for going over this, Brian. As a SaaS vendor we
    get frustrated at the speed with which on-premise
    people's marketing machines are shoving SaaS wrappers
    on traditional apps - but if we raise red flags, it
    just sounds biased.

    I'll add one other benefit of SaaS which accrues to
    the vendor more than the customer, and which we've
    learned over eight years of delivering pure SaaS, and
    that's having an ongoing relationship with the
    customer. No ship-and-forget ; we end up working with
    customers long-term, get suggestions for enhancements,
    and priceless feedback, plus the pure satisfaction of
    seeing people use our product. A huge SaaS plus.
  • RE: SaaS-querade: When On-Premise Vendors Try to Pass as SaaS Vendors

    I agree with this post as there is a lot grey cloud area
    being spun by vendors and the customer is being confused
    by information overload and as you pointed out, deception
    in some cases. We also wrote a post on The future of
    Cloud Computing for SMB's on our blog. Which extends
    this pov and illuminates other aspects that SMB should
  • RE: SaaS-querade: When On-Premise Vendors Try to Pass as SaaS Vendors

    It's a transition period for Cloud & SaaS. May be it?ll take some time for the buzz to settle down & some standards to evolve. Till then SaaS-querades will have their way into the market. Let the customer/market decide what succeeds in the long run?Here?s a good read on the basics of SaaS:
  • Surely there is also more to SaaS...

    @rick names 3 dimensions by which customers think of SaaS, but to me they are necessary but far from sufficient. Others, like @netevidence and @burster touch on why the 3 alone are not sufficient, and I think the biggest reason is actually the business model and the go-to-market model. The latter G2M incorporating all the touchpoints including admin and support and innovations and advocacy. For vendors you have to be able to find enough customers at a low enough cost of acquisition and retain them as long as possible while driving all costs down and all complexity of interaction out. That's a heck of a lot more than hosting your battered out ERP system and calling it SaaS as you rightly point out.<br><br>@netevidence really makes those points, and that's little to do with deep technology e.g. how it is hosted, although overall it can only be achieved by a integrated range of technology e.g. web to forums to analytics to email systems etc. <br><br>SaaS has to deliver value day 1, on-premise delivered a promise on day 1 and then after the usual project disillusionment the team left and the customer had a whole lot of sunk cost. That relationship building to which @netvision referred isn't going to be in the DNA of the on--premise vendor for one simple fact - it is not the way their people are compensated.<br><br>I too get frustrated with the "host a product" and call it SaaS, although it's often hard to explain to people who don't know what they don't know. But hey! It's their money let them try and if they can pull it off good on them.

    @llaratte great post, that's excellent.
    <br><br>Walter Adamson @g2m