Migrating Your Software Company from On-Premise to SaaS: Part 1

---

Listen to This Blog Post:

The overwhelming majority of software companies founded over the past fifteen years or so have never known anything other than a cloud-based, single-server-multi-tenant architecture coupled with a subscription revenue model. If you’re running a software business that fits this description, then you’ll (thankfully) never need to navigate the transition that I describe below. If however you’re running a company that is still selling on-premise software under a perpetual-use pricing model (or you’re considering investing in one), then you’ve likely already contemplated making this transition. My sympathies in advance.

Navigating the transition from on-premise to SaaS was perhaps the hardest thing that I had to do as the CEO of my own software business, and I still have the scars to prove it. There’s a reason why this migration is colloquially referred to as the “valley of death” by CEOs, Investors and/or Board Members who have either first or second-hand experience in making this leap. If done properly however, the value that one can add to their business by successfully navigating this transition is staggering: Assuming that the company (and the CEO!) can survive the financial and operational challenges that will arise in the first three years or so, a successful on-premise to SaaS migration could increase the value of a business anywhere between 2x-6x (or more) its current value, all else being equal.

In this post, I will lean on my first-hand experience in making this transition to describe some of the factors that make it so difficult. This isn’t to dissuade you from pursuing it, but instead to ensure that CEOs, Boards of Directors, and investors have a full understanding of the risks and difficulties involved. Plus, a problem well-defined is half solved: We must have a full diagnosis of the relevant issues before we prescribe possible solutions to them.  

In my Part 2 of this blog post, I will share with you the tactics and strategies that worked (and didn’t work) for me to overcome some of these challenges, so that you can drastically increase your own odds of success should you decide to make the leap yourself. You’ll note that I don’t spend any time in either post discussing why you might consider making the transition in the first place, as much has already been written on the topic elsewhere.

A (Highly Simplified) Definition of the On-Premise to SaaS Migration

Though the migration is often discussed as if it’s a singular act, in its most basic form it’s actually composed of two different (though often closely related) fundamental changes to a business. Namely:

1. Primarily Financial: Migrating away from one-time, perpetual use license fees in favor of a recurring subscription revenue model

2. Primarily Product: Re-architecting (or re-writing) your software from a single-server-single-tenant architecture to a single-server-multi-tenant architecture, often necessitating the use of a new or different technology stack (a tech stack refers to the combination of platforms on which both the front and back ends of your software is built)

Though the two changes mentioned above go hand-in-hand more often than not, it’s important to know that some companies have done one without doing the other (namely, changing their financial model without making any real changes to their product). Though this path will create less value than if you were to do both, just doing one has historically proven to be accretive to the value of the business in question more often than not (though your author has an open question regarding for how much longer this will be the case).

The list of challenges and issues that follows should not be considered to be an exhaustive one, but in my experience, it captures most of what will keep a CEO awake at night. Alas, let’s see what the “valley of death” is all about:

Needs of the “Current” Business vs. Needs of the “Future” Business

If you’re making (or contemplating making) this transition, it’s likely that your end market is rapidly changing: Both the way that they buy software (via the pricing model, and which budget – capital or operating – they’re using to fund the purchase) and the way that they consume software (on-premise vs. cloud hosting).

Depending on how you tackle the issue, your world may evolve into a binary universe where on one hand you have your current product (existing on-premise software that is presumably paying 100% of your bills) and your new product (SaaS product that may not yet exist, that is presumably paying 0% of your current bills, but is necessary for the long-term survival of your company). Where do you put your resources?

If all you do is focus on your current product suite, you may hit your near-term sales targets, but you’ll be mortgaging the future of your company as the market is likely moving to SaaS rapidly (indeed, most industries have already undergone this paradigm shift in its entirety, though some laggard industries remain). Conversely, if all you do is focus on your SaaS product, then you run the risk of “starving out” your existing customers who are constantly demanding new features & functions from you. In this way, you may risk losing the primary revenue stream (your current product) that’s funding your ability to work on the new product in the first place! And of course, if you try to do both equally, you’ll likely end up doing a poor job at both.

Hence why the needs of the “current” business often seem to be at odds with the needs of the “future” business (though there are ways to mitigate this, as we’ll discuss in Part 2)

The Complete Overhaul of the Company’s Financial Model

Migrating away from one-time, perpetual use license fees in favor of a recurring subscription revenue model will likely completely change both the revenue and profitability profile of your company. More specifically, in the near-term, both your revenue growth and your profitability will be significantly impaired, even for companies that currently enjoy a large EBITDA cushion.

To use a simple example: Suppose you used to charge your customers a one-time $100 perpetual use license fee. Under a subscription model, you may now be charging them, say, $33/year, or $2.75/month (the 3:1 ratio here is not a rule, merely an illustrative example). Let’s further assume that in year 1 of your transition, you will sign 12 new customers, on the first day of each month.

Under your old perpetual-use pricing model, you’d generate $1,200 in revenue that you’d be able to recognize this year (= $100 * 12 customers). Under the new model however, you’d only generate $215 in revenue that you’ll be able to recognize this year for the exact same 12 new customer acquisitions. This is so because, for any given subscription contract, the revenue that you’re able to recognize in a given year is equal to the number of months (multiplied by the monthly price) in which your obligation to the customer has been fulfilled (i.e. the number of months in which the customer is in possession of usable software).

This means that the only contract for which you can recognize the full $33/year subscription price is the one that was signed on January 1^st, because the customer will have been in possession of a usable piece of software for each of the 12 months of the year. For the customer signed on February 1^st, you’ll be able to recognize 11/12 of the $33/year fee, as the customer will only be in possession of a usable piece of software for 11 months. And so on, all the way through to December, where you’ll only be able to recognize 1/12 of the contract’s value as revenue in this fiscal year. What this creates is a subscription revenue “waterfall” that looks something like this:

This will likely create a big financial problem for you in the early years of the transition: Your company’s entire cost (and thus profitability) structure is almost certainly based off of the old perpetual-use pricing model, where you would have generated $1,200 in revenue from the acquisition of these 12 customers. Under your new pricing model however, those same customer acquisitions are only providing you with $215 in revenue (an 82% decline). Most importantly, this revenue decline will fall straight down to EBITDA (or operating profitability). This drastic fall in both revenue and profitability is generally what folks are talking about to when they refer to the transition as “the valley of death”.

However, it gets worse: Both revenue and profitability are accounting conventions that are subject to manipulation depending on how various rules and best practices (stemming from GAAP, or Generally Accepted Accounting Principles), are applied. More concerning than either of these is the shortfall in cash that is likely to result from your new pricing model: Under the old model, the $1,200 in revenue likely translated to $1,200 in cash (or somewhere thereabouts). Under the new model, even if all 12 customers paid you in full for the entire 12 months of the contract upfront, you’d only collect $396 of cash (12 customers * $33/year/customer).

How will this new cash generation profile interface against an old cost structure that was likely built assuming that $1,200 in cash (not $396 in cash) would be generated from the acquisition of 12 customers?

Access to Capital

In our example above, the decline in revenue, profitability and cash must be financed somehow, otherwise you may quickly run into a situation where your company runs out of cash. Ways to finance this include cost reductions (though this alone certainly won’t cut it), cash on hand, cash flow from ongoing operations, cash from existing lines of credit, or cash from a debt or equity capital raise. You cannot make this transition unless and until you’re confident that the transition itself can be financed. Making things more difficult is the fact that traditional bank lenders often have trouble wrapping their heads around lending to a company that will suddenly not be making an accounting profit for the next 1 – 3 years.

This gets particularly difficult for companies who already have debt on their balance sheets, as debt usually comes with covenants (legally binding promises to achieve and maintain agreed upon financial targets, benchmarks, or ratios during the period in which the debt remains outstanding): If the debt was issued when the company was operating under its old perpetual-use revenue model, then your covenants will likely need to be completely renegotiated (if this is even an option for your bank). If an on-premise software company is being purchased as an investment, then the investors in question must be very thoughtful about how much debt (if any) should be put onto the company’s balance sheet at acquisition.

Sales Incentives

Unless properly managed (more on this in Part 2), assuming you’re planning to utilize the same sales team that you have today to sell your new SaaS product, the change in your revenue model will make it extremely difficult for you to clearly, properly, and fairly incentivize your salesforce via their incentive compensation plans. Some complicating questions in this regard include:

• Does your team have the ability to offer customers both pricing models (and/or both products), or just one?
• Does this change at all for existing customers versus new logos?
• How can you set realistic and easy-to-understand targets for your sales team when you have two products with two completely different revenue profiles?
• Do you base your compensation to them on the value of the contract, the cash received from the customer, or the value of the revenue that you’re able to recognize in the current year? These could conceivably be 3 very different numbers
• How do you maintain their OTE from last year without wild swings in targets and commission rates?
• What happens to their commission payments if a customer cancels mid-contract?
• How do you explain to them that the $100 product that they sold yesterday is now only worth $33, and their compensation will now be based on that lower number?
• How do you treat renewals in years 2+?

Your Engineering Team

Naturally, your Engineering team was built over time with a mandate to build on-premise software. Particularly for employees with longer tenures within your organization, building on-premise software may be all that they know. If you’re re-writing or re-architecting with a view towards a SaaS product, are you confident that these same (primarily on-prem) engineers have the knowledge and experience necessary to do something completely different from what they’ve been doing for years? SaaS software is very different from on-premise software ranging from its architecture, security and multi-tenancy protocols, the tech stack in question, and even the development process itself. Do you have the team to execute on this transition with the speed and quality that will be necessary to make it a successful one? If not, will a brand new team have the proper context, experience and domain expertise to do the same?

Creation of New Organizational Disciplines

The transition to SaaS often necessitates the creation of completely new organizational disciplines (and/or departments, and/or people) that didn’t need to exist in the previous on-premise regime. Building new organizational disciplines from scratch is incredibly difficult at the best of times, never mind when you’re having to deal with all of the other problems that we’ve discussed thus far. Here are just some of the more common examples of new disciplines that often need to be created:

• Customer Success: Training, onboarding, and ongoing education of customers to ensure they’re getting the highest and best use of your software. Without this discipline, you risk non-renewal of contracts, which eliminates the primary benefit of the subscription revenue model

• DevOps: DevOps is generally responsible for combining the disciplines of engineering, IT, operations, and security to ensure that your software is of high quality, reliable, and secure, particularly at scale. The usefulness of the product itself depends heavily on a robust DevOps group, a group that many on-prem organizations don’t formally have

• Renewals: The true magic of the subscription model generally comes in years 2+ of a contract, where the annual revenue generated from any given customer “stacks” on top of the previous years of revenue generated from that same customer, without the large sales effort that was required to initially acquire that customer in the first place. If you lose a customer within the first 1-2 years of a subscription contract, you lose all of this benefit. Thus, most SaaS businesses need a deliberate strategy (and sometimes a dedicated team of people) focused on renewals

• Development Processes: Most on-premise companies follow a “waterfall” approach to development, characterized by long development cycles (1 month+) comprised of many features and functions packaged into any given release, with release frequencies often being as long as quarterly, semi-annually, or annually. In SaaS, most companies follow an “agile” approach, where work is organized into weekly or bi-weekly “sprints”, comprised of a small number of features, and with releases happening as frequently as daily, weekly, or bi-weekly. Is your current team capable of handlining such a fundamental change to how they work day in and day out?

Culture Issues

Like many large-scale organizational changes, the transition from On-Premise to SaaS will almost certainly create cultural issues that will need to be managed carefully. These cultural issues are typically created when one group of employees get charged with working on the new product, while another group of employees get charged with working on the old one. This latter group (understandably) usually has a very difficult time accepting that not only are they not working on the new and exciting product, but they’re spending substantially all of their time on something that – by definition – will not be the driver of future growth and value creation for the company. If you’re lucky, this group of employees will greet this news with begrudging acceptance. More likely however, the CEO will have to manage an “us vs. them” culture, feelings of demotion or of not being valued, lack of growth and learning opportunities for key technical employees, and voluntary employee turnover, among other issues.

Customer Inertia

You should be extremely careful if a large part of your thesis revolves around getting existing customers to migrate from their old on-premise product to a new SaaS product (once it’s ready). This is because getting your existing customers to make this switch will likely be more difficult, time consuming and expensive than you may think, if you can do it at all. This difficulty becomes particularly pronounced if/when:

• Customers have been using your product for a long time;
• Customers use your product very frequently (i.e. daily);
• Your product is integrated with other important systems of record used at the customer’s site;
• Customers have previously made large financial investments in implementations, integrations, specific configurations, and/or other professional services to make your product work optimally within their environments;
• Customers are happy with the product as it is, and are deriving sufficient value from their existing use cases;
• There isn’t a sufficiently large delta in cost, usability, and/or functionality between the old on-premise product and the new SaaS product

In light of these reasons (and many others, which were omitted for the sake of brevity), you may find yourself in a situation where, after 3-4 years and a substantial investment (in both time and money) in your new SaaS platform, the vast majority of your customer base may still be using your legacy on-premise product suite.

In order to have the majority of your customer base on the new SaaS platform within a reasonable amount of time, you either need to a) Have an incredibly robust new customer acquisition engine exclusive to the new SaaS product (very hard to do); b) Use a “carrot” to incent existing customers to migrate from the old product to the new one (very hard to do for the reasons mentioned above, among others); c) Use a “stick” and EOL (“End-of-Life”) the old product and provide a migration path to the new product (hard to do, and your customers will likely go to a competitor instead); or d) Support both products for so long that, over many years, your new SaaS customer acquisitions will have outgrown the previous base of exclusively on-prem products (very expensive to do, and prolongs the period of time during which you’ll have to manage each of the challenges mentioned in this blog thus far). 

I probably don’t need to tell you that none of these options sound particularly appealing.

In Sum

Reading this laundry list of problems likely won’t be your most inspiring read today. The good news, however, is that we’ve now defined some of the larger problems that you may face, meaning that we’re now in a position to better address them. Despite how daunting this read may have been for you, it’s worth mentioning that many companies have indeed successfully navigated this transition, so it’s not impossible.

Now that you understand the problems, let’s now look at some specific tactics and strategies that you can put into place to maximize your odds of successfully navigating through the valley of death. These tactics and strategies will be the focus of my next post, Migrating Your Software Company from On-Premise to SaaS: Part 2.

---