Migrating Your Company from On-Premise to SaaS: Part 2

This is the second post in a two-part series on navigating the transition from on-premise to SaaS. You can read Part 1 here.

Listen to This Blog Post:

In Part 1 of this blog, we evaluated some of the more common challenges that companies face when attempting to migrate both their product and revenue models from that of on-premise to SaaS. Though this transition is indeed very difficult to successfully navigate, the companies who do it often benefit from valuations, revenue stability, and profitability profiles that are orders of magnitude higher than their pre-transition values.

I guided my own company through this transition over many years. Eventually, we increased the percentage of total revenue coming from recurring sources from ~40% in 2014 to ~80% in 2020. Within 18 months of the release of our first multi-tenant SaaS product, it grew to account for over 30% of our total revenue base. Though this represented notable progress relative to our starting point, our transition went too slow, required too much time and capital, and came in below our initial targets.

Our progress was slow because of all of the mistakes that we made, which stemmed largely from the fact that I had never led a company through such a transition in the past. In an effort to prevent you from making some of those same mistakes, below I’ve presented a list of best practices that I think you should consider implementing as you navigate your own SaaS transition. Ultimately, my hope is that your journey is faster, cheaper, and ultimately less painful than mine was.

Start Sooner Than You Think You Need To

We sold our software into an industry that was generally considered to be slow-moving, risk-averse, and hesitant to adopt new technologies. When I became CEO in 2014, substantially all of our customers were on-premise, and the majority of the broader market still purchased software via the perpetual-use pricing model. I used this reality as an excuse to justify moving slower than we should have in initiating the SaaS transition, though I knew it was something that we would eventually need to do. In retrospect, I wish we had started sooner, primarily because:

• We waited until the evidence had become overwhelmingly clear that the industry was indeed changing how it purchased and deployed software towards a cloud-first model. What I failed to remember is this: If you find yourself making a decision in the face of near-complete or near-perfect information, then you’re likely already too late.

• We knew that years 1-3 of the transition would create significant financial & operational challenges. I wish we had simply taken our medicine and got it through our system sooner, particularly because my plan had always been to seek an exit (or at least some sort of liquidity event for my investors) within 5-7 years of my initial purchase of the company in 2014.

• We wasted time and money developing more features & functions for an on-premise product that we knew eventually would slowly begin to fade away

• The cost of being too late was far higher than the cost of being too early

If you’re navigating through your own transition now (in 2021), then I’d suggest that the urgency is likely even higher than it was for me in 2014, as the paradigm shift towards cloud (within the industries who have been relatively slow to adopt it) has become even more pronounced in the intervening 7 years.

Change Your Pricing Model Even if Your New Product Isn’t Ready

Recall from Part 1 that though the SaaS migration is often discussed as if it’s a singular act, in its most basic form it’s actually comprised of two different (though often closely related) fundamental changes to a business. Namely: i) Financial (migrating away from one-time, perpetual use license fees in favor of a recurring subscription revenue model); and ii) Product: (re-architecting or re-writing your software from a single-server-single-tenant architecture to a single-server-multi-tenant architecture).

In our case, we had a strong balance sheet (lots of cash and not a lot of debt) in the early years that would have allowed us to weather the financial storm typically seen in years 1-3 of a SaaS transition. Even before we started to build our new SaaS product, we should have changed our pricing model immediately (retire perpetual-use pricing in favor of a subscription model, even though we were still selling our on-premise product at the time). This would have provided us with the opportunity to begin building that critical base of subscription revenue faster, which in turn would have allowed us to return to pre-transition EBITDA & cash flow levels faster as well.  

A note of caution: Before you hastily implement a new subscription pricing structure within your own business, you must first understand if and how you can finance it (see my discussion on this below), particularly if you have any debt outstanding (as you will likely break covenants with your lender that were set based on your perpetual-use pricing model). It’s important to understand that the capital structure of the business must allow for (or at the very least, not get in the way of) the financial and operational realities of migrating a business from on-premise to SaaS.

Don’t Give Your Customers a Choice on Pricing

Before, during, and even after the release of our SaaS suite of products, we still had a team that was selling our on-premise product, as there continued to be robust demand for it in our industry (though note that some companies decide to stop selling their on-premise products entirely once they develop a suitable SaaS alternative). Initially, we gave our customers and prospects the choice to purchase our on-premise products either through the perpetual-use pricing model or the new subscription model, as we didn’t want to risk losing deals based solely on how we were planning to charge the customer.

If you’re still planning to sell your on-premise product (even if temporarily) please do not do this. Giving customers a choice created huge challenges for us in regards to our ability to do financial planning/forecasting/budgeting, and more specifically to establish an incentive compensation plan for our sales team that was worth the paper that it was printed on. Once we realized our mistake and stopped giving customers a choice (we mandated subscription pricing for all sales, regardless of the deployment model), everything became much clearer, and the blowback that we received from customers was almost non-existent, despite our fears to the contrary.

By offering our customers a choice, we failed to recognize the power of inertia: Our customers and prospects had been “trained” over the course of two decades to buy software in only one way (perpetual-use licenses funded via their capital budgets). When we gave them the choice, they mostly chose the status quo. This left us bearing all of the costs and burdens of a SaaS transition, but reaping none of the benefits via the generation of subscription revenue.

One Salesperson Shouldn’t be Expected to Sell Two Fundamentally Different Things

Once our beta SaaS product was ready, we initially asked our existing sales team to sell it in addition to the on-premise software that they had already been selling. What we quickly learned from this experience is that when you ask salespeople to sell two fundamentally different things, they’ll generally do a poor job of selling both. Moreover, you will almost certainly fail in your attempts to motivate and reward your sales team via their incentive compensation plans, which will become a confusing labyrinth when you try to include two fundamentally different pricing models. Eventually, we fixed this issue, and had one sales team dedicated to our on-premise product (as we decided to continue selling it), and a completely different sales team (with a completely different incentive plan) selling our SaaS product.

Don’t Compensate Your Sales Team Throughout the Life of the Customer’s Contract

In the early months of our transition, we elected to compensate our sales team on an equal monthly basis throughout the first year of a customer’s contract. For example, if we sold a $120/year (or $10/month) contract on June 30^th, 2020, we’d give the salesperson an equal commission payment in each of the first 12 months of that contract between July 2020 and June 2021. After all, we figured this would:

• Help company cash flow when we needed it most, by collecting from the customer upfront, but only paying the commission to the salesperson equally over the course of the next 12 months

• Share the risk of customer cancellation equally between company and salesperson: If the customer canceled within their first 12 months, the company lost a customer, and the salesperson lost however many months’ worth of commission were left between the month of cancellation and month 12 of the customer’s contract.

This was a foolish decision for a few reasons, but namely because any time that you create a “long tail” of commission payments due to a salesperson for a one-time sale that they made in the past, at some point in the future your salesperson may have a month, quarter, or even a full year of “residual” commission payments due to them stemming from sales that they made anywhere between 1-12 months in the past. The effect of this is that these salespeople may not have to make a single new sale in that month, quarter, or year in order to hit their OTE for that period. Even with experienced and driven salespeople, this “long tail” of commission payments creates the risk of them becoming (pardon the crude analogy) “fat and happy”, and thus significantly less motivated to make new sales. The more time that elapses, and the more sales that person makes in the early days, the greater this risk becomes.

What we eventually did (and what we should have done from day one), was give them a one-time, upfront payment when they acquired a new customer. This kept them equally hungry to go out and immediately try to find the next new customer.

Ensure you Have a Clear Plan to Finance the Profitability & Cash Flow Shortfall

As we discussed in Part 1, the early years of a SaaS transition are often characterized by a decline in revenue, profitability and/or cash (both operating cash flow and/or your bank balance). This decline is due, among other things, to: i) The different revenue recognition rules specific to subscription contracts; ii) An annual subscription price often being lower than its perpetual-use equivalent; iii) Insufficient time for subscription contracts to “stack” on top of themselves via renewals; and iv) A company cost structure built on a now-outdated revenue structure.

This creates what many refer to as the “J-Curve” (colloquially referred to as the “valley of death”) that your revenue, profitability, and/or cash flow can follow once you initiate this transition. It looks something like this (simplified for illustrative purposes):

---

What some companies realize too late is that the area shaded in red above must be financed somehow, else your business runs the risk of running out of cash (and thus ceasing to exist). Specifically, you should:

• Build a detailed financial model (your CFO and/or a number of external companies can do this for you) to quantify how much needs to be financed over the next X years to keep your company liquid (area shaded in red above, often anywhere between 1-3 years)

• Depending on your level of conservatism, I would suggest adding anywhere between 20%-50% on top of this number, to account for the risk that you’ve underestimated how long and/or costly the transition will be (we certainly fell prey to this)

• Have a plan to finance this dollar figure (including the 20%-50% buffer). Ways to finance this can include any of (or a combination of) cash already on hand, cash flow from ongoing operations, cash from a debt or equity capital raise, asset sales, existing lines of credit, and so on. Do not begin your transition to SaaS unless and until you’re confident that one (or a combination of several) of these sources will sufficiently fund your upcoming profitability and/or cash shortfall

Collect From Customers Upfront

Because of the cash crunch that your business may face in the early years, insist that the full dollar value of the contract is collected upfront, at the start of the contract, not in equal monthly installments throughout the life of a contract. You can still advertise a monthly subscription price, but collection covering the full term of the contract must be upfront. Though switching to a subscription model almost always impairs your profitability, collecting upfront is one way to limit the extent to which it eats away at your cash.

Be Thoughtful About the Market into Which You’ll Sell Early Versions of Your SaaS Product

By pursuing the SaaS transition, it’s important to recognize that in effect what you’re attempting to do is disrupt yourself before other companies are able to do the same thing to you. It’s thus important to realize that your new SaaS product will likely follow the same path as other disruptive innovations – namely that it will:

• Underperform, and/or lack the features & functions of your existing product (at least for some period of time);
• Be less interesting to existing customers relative to new customers; and
• Be simpler, cheaper, and often more convenient to use relative to your current offerings;

The combination of these three realities often means that early versions of your SaaS product can’t be sold into your existing market, because it likely won’t satisfy the performance requirements of that market. With this reality in mind, the CEO has two broad choices:

1. Wait to release the SaaS product until it’s features and functions are robust enough such that it can satisfy the performance requirements of the company’s existing market; OR

2. Iteratively release the SaaS product well before this point, and sell it into a market in which the weaknesses or deficiencies of the product (lack of features and functions) can be seen as a strength (simplicity, ease of use, low price point, etc.)

My experience strongly suggests that the CEO would be much better off choosing option #2. Among other reasons, option #1 defies most well-understood best practices of agile software development, and will almost certainly include a lot of wasted time and effort, which in turn will lead to a lot of re-work.

More specifically, when following option #2, I would offer early versions of my SaaS product to the smallest end of my existing target market, as they’re likely to have simpler use cases, more finite budgets, and value simplicity and ease of use in comparison to their larger counterparts.

Notice how I didn’t suggest that you seek out a new market entirely, a trap that we fell into for a brief period of time:  

In our case, our company had operated for 20 years selling software to transportation companies that had, on average, 200 trucks, but ranged anywhere between 50 – 500 trucks. Everything about our company (our product, marketing, sales cycles, employees we chose to hire, etc.) was built upon the foundation of serving these “mid-market” customers. However, when we first released our SaaS product, we got very excited about the smaller end of our industry, namely the 1-30 truck market. Specifically, we liked the size of it (it was orders of magnitude larger than our existing target market). At the time, we thought: Didn’t it make sense to sell a smaller, simpler, cheaper solution into a smaller, simpler and more price-conscious market (1-30 trucks)?

What we eventually came to learn however was that the 1 – 30 truck market was completely different from the market that we had spent 20 years serving. Even though both markets were engaged in fundamentally the same business activity, we learned that the smaller end of the market experienced completely different business problems from mid-market and enterprise customers. Not only that, but seemingly everything else was different too: The sales cycles, the decision makers, the approval processes, the levels of technological sophistication, the financial resources and wherewithal, the most pressing problems that they needed solved, and so on.

In our pursuit of selling our new SaaS product into an end market in which the product’s deficiencies would be seen as strengths, we ended up “over-reaching”, and pushed ourselves so far down market that we violated the product/market fit that we had spent the past 20 years cultivating.

As you release your own new SaaS product (particularly early versions of it), I think starting down-market makes sense, but ensure that you honor the product/market fit that you already have and target smaller customers within the existing range of the market that you already serve. In our case, instead of trying to sell our SaaS product to 5 or 10 truck companies (a market we came to learn that we knew nothing about), we should have started at ~50-60 truck companies.

Spin Off an Entirely Different Company 

This is the most important lesson of all, and purposely I’ve saved it for the end as it builds on substantially every other lesson discussed thus far: If given the opportunity to do this transition again, I would spin off a different company entirely for the emerging SaaS business. This separate company would include its own teams (sales, product, engineering, customer success, etc.), its own targets and incentive plans, its own separate set of financial statements, and even its own physical space.  

Remember that, in effect, the SaaS transition represents your attempt to disrupt yourself before another company has the ability to do so. As Clay Christensen says in his infamous book “The Innovator’s Dilemma”: “Rational resource allocation processes in established companies consistently deny disruptive technologies the resources that they need to survive, regardless of the commitment that senior management may ostensibly have made to the program”.

Said another way, the needs of your “current business” will be in constant conflict with the needs of your “future business” (See Part 1 for why this is a problem), and in most cases, the needs of your current business will win, as they pay 100% of your current bills, and represent 100% of your current customers. In this way, you may hit your near-term targets, but you’ll be mortgaging the future of your business, even if management has thoroughly communicated the importance of developing the newer technology. The spin-off company would be laser-focused on commercializing the new technology, while the existing business can remain laser-focused on hitting existing revenue, profitability, and/or customer acquisition goals.  

Depending on the state of the existing business, I would staff the spin-off company with some of my best people, and have them focus solely on the SaaS business to avoid being repeatedly withdrawn from the project to solve problems for existing customers (this “context switching” is a massive productivity killer, and as mentioned above, the existing customer – who presumably is always going to be screaming loudest – will almost always win).

I would ensure that the spin-off company was staffed only with those employees who, deep in their bone marrow, believed in the importance of the new project, and who had the technical know how to successfully execute on it with the required levels of speed and quality. As mentioned in Part 1, some of your existing employees may have spent substantially their entire careers selling, developing, architecting, testing, or supporting on-premise software, and those skills may not directly translate to SaaS. More damaging than even an out-of-date skillset however is an attitude or disposition that some long-tenured employees may have that the new SaaS venture is a distraction, and shouldn’t really be pursued at all. People with this mindset shouldn’t be allowed to work on the new project, as it will likely fail even if every lessons above has been stringently adhered to.

Lastly, I would give this spin-off company some set of constraints that would force or incent them to find product/market fit (and commercialization more broadly) as fast as possible. This could include a finite operating budget, a finite timeline, a meaningful incentive program, or some combination thereof. Without these constraints, it would be too easy (as it was in our case) to move too slowly, to not iterate and test enough, and to continue to rely on the profits from the “existing business” to fund the development and commercialization of the “future business”

---

---