Let’s work though these results and see what they mean for ISVs moving to SaaS.

Layer 1: Do-it-yourself (10%)

At the lowest of the five PaaS layers you build your applications with whatever tools and architecture you want. You select, buy and run the hardware to support your SaaS solution.

Perhaps the 10% is because readers said what they would prefer to do; not what they should do?

Geeks like to play with technology! It seems there are still some who think setting-up racks of servers is a good use of their time.

Facebook can borrow USD100M to buy 40,000 servers.

Salesforce.com can invest tens of millions to run their data centres.

You can’t, however, so forget about it right now.

Layer 2: Managed hosting (18%)

In the second PaaS layer you have full software control, but leave the hardware to a specialist hosting provider. They make some of the hardware decisions, but you are still responsible for most of the technical decisions.

18% is high for this low-level PaaS layer. This could be because the temptation is to buy hosting and offer your on-premise application as a SaaS solution.

The managed hosting providers encourage you to think that migrating your on-premise application to SaaS is a good idea. They are moving quickly from offering commodity cage and pipes and adding services such as security and billing.

Even Sun encourages you to go this route with their recent Solaris On Demand offer.

The new grid-based hosting environments make it easier to provision virtual services and storage. This way you can run multiple instances of your on-premise application; one for each tenant.

This is a quick way to offer something, but there is a critical problem with taking this approach.

You have to be 16 times more efficient

You can probably run an adapted version of your on-premise application, but can you make any money with this approach?

There is a big risk your costs will explode as each new tenant comes on-board. An article from Bob Warfield’s SmoothSpan blog makes this point well.

Assume:

• your annual subscription is about the same as your on-premise licence costs for one year
• your on-premise customers have a 4:1 ratio for the hardware, software and support costs to run your application
• your cost of goods sold must not exceed 25% of your subscription price to make a profit

If you offer your on-premise application as a SaaS solution your costs must be 16 times lower!

If you do not achieve this factor of 16 then you will make a loss with each user. The more tenants you have, the worse it gets. That is not how SaaS should work.

Can you run your on-premise application as a SaaS solution 16 times more efficiently than your on-premise customers?

To be honest, I have my doubts.

Too many application and database instances

Using a managed hosting provider for the application is a better idea that having your own hardware. Even so, your costs will explode as you did not design your on-premise application for SaaS.

Without multitenant support you will need far too many application and database instances running for any given tenant workload. Managed hosting providers price by instance, so this is wasteful and expensive.

That is not your only problem, however.

People costs will kill your margin

The people cost of running and supporting your migrated application will be too large a slice of your subscription revenue.

Remember, your ISV has great skills in building applications, not running them.

This is an inconvenient truth, as operations expertise will be a major contributor to your success with SaaS.

Even with all these problems, your biggest problem is still to come…

80% of your on-premise code is irrelevant

To adapt your on-premise application you must migrate, run and support 80% of your legacy code; code that has no place in your SaaS solution.

You do not need the frameworks, low-level functions and common features. You should use standard services for security, reporting, billing, user management and so on.

The only code you should write for your SaaS solution is for your specific domain. All the rest is a commodity where you should use external services.

Standard SaaS services are easier to setup, use and support than migrating your legacy code. The pay-as-you-go model is also a better match to your future SaaS revenue stream.

Migrating your existing application from on-premise to SaaS might seem at first to be a good idea.

Do not be mislead, however, by managed hosting providers who try to make this sound like a good idea.

The more you think about, the clearer it becomes it is not a good idea.

Migrate your domain skills, not your legacy code

If you start down the migration road you soon find you are in a dead-end. You need to take your domain expertise forward, not your legacy on-premise code.

You should build your SaaS application with the latest tools, using external services for all common processes. Then you can focus on creating the best possible experience in your vertical niche.

Do not waste your time on legacy code and the 80% “stuff” you had to do in the past.

SaaS is a unique opportunity to leave the past behind.

Grab this opportunity in both hands and dedicate yourself to your domain. You have the chance to create a SaaS solution to will surprise and delight your customers.

Coming Up…

In part three of this article I will look at the next layer up in PaaS market: cloud computing. This is where it starts to get interesting for ISVs developing SaaS applications…

Do you agree that do-it-yourself is a hopeless choice for SaaS ISVs? If you decided to go the managed hosting route what have been your experiences? Are you trying to migrate your on-premise application to SaaS? If so, what problems have you run into? Given what you now know, would you migrate given a second chance?