As SaaS adoption rises, traditional ISVs with on-premises solutions face enormous pressures to develop cloud-based SaaS offerings. This pressure comes not just from competitors and other market forces, but from the ISV’s existing customers.

For traditional ISVs with single-tenant offerings, the prospect of rearchitecting their entire application to adopt a multi-tenant, cloud-native approach is unrealistic. They want the benefits of a SaaS model quickly without significant restructuring of their current software — or want to get to the cloud first and restructure later.

In this guide, we’ll identify strategies for migrating to a public cloud platform like Amazon Web Services or Microsoft Azure while limiting any changes to your existing software application. We’ll show you the benefits and trade-offs of each architectural choice, and also the path forward after migration to modernize your SaaS solution.

Part 1: Building a Business Case for SaaS

Migrating to a cloud-based SaaS model is more than just a technology decision. When you migrate to cloud, you’re offering an entirely new line of business, which often changes your core value proposition to customers. Before migrating, you will need to develop a solid business case for the cloud and understand how it changes everything from customer onboarding to pricing.

As you begin to develop your business case, do your research on how other software companies have made this transition and why. According to a survey of ISVs conducted by Forrester Research, ISVs ranked the following reasons for migrating to the cloud: 

• 90% wanted to develop SaaS as a response to customer demand
• 80% wanted to increase agility & respond more rapidly to changing customer demands
• 78% viewed SaaS as a way to streamline R&D and delivery costs
• 78% believed SaaS could aid expansion into new customer segments
• 71% developed SaaS because they were losing customers to SaaS competitors

Let’s break down a few of these migration reasons one-by-one:

#1: Competitive Pressure & Company Survival

SaaS is the fastest growing IT market segment in the world. Converting from traditional software to cloud-based SaaS is a top priority for 43% of companies in 2020 — a significant jump from 29% in 2019. In other words, your competitors already have plans to move to the cloud or are already in the cloud. Customers expect a cloud-based SaaS option. 

#2: Improve Agility & Streamline R&D

It’s notoriously difficult to put a dollar value on improving agility, so in building a business case, focus on the cost of not having one or two key features that your competitors have. Pull together data on a) lost prospects due to missing features b) churned customers due to missing features c) competitor user/revenue grown due to key features. 

#3: New Customer Segments

If enabling your software requires a significant upfront investment, you’ve likely focused your go-to-market efforts on mid-market and enterprise customers. When your customers can purchase a SaaS solution without capital investment, you can often expand into smaller markets. 

#4: Protect Existing Customer Base

It’s almost always cheaper to retain a customer than to acquire a new one. If your customers are jumping ship to get cloud-based software elsewhere, use data on customer churn and put a dollar value to that lost business. For most software companies we talk with, this is the single biggest financial motivator for cloud.

Addressing Business Concerns

Alongside the business case for cloud, you also need to address business concerns of migrating to cloud. Here are a few of the most common concerns or questions we hear, and how to address them with your team. 

How Do We Manage the Cloud?

When you sell SaaS, you’re also selling your own infrastructure maintenance services. Your SaaS platform runs on top of cloud resources that you manage, and the degree to which those resources are high-performant, secure, and reliable obviously has an impact on customer satisfaction.

Traditional ISVs that offer their solutions in a web application are used to managing the infrastructure that supports their software. However, companies that install their software in their clients’ data centers are used to offloading this responsibility to customer IT teams. Large-scale infrastructure management can be a new and unfamiliar universe. 

76% of companies make the mistake of underestimating the time & effort of cloud management, causing significant pain for the business. The last thing you want is an under-staffed, stressed, under-trained IT team managing the infrastructure for your brand-new, mission-critical line of business — that’s a recipe for career-ending IT mistakes. The best options include creating a dedicated operations team just for the SaaS line of business, or outsourcing to a Managed Services Provider (like TechCelerated!). We’re obviously biased, but for mid-market companies without the capital to invest in building out a whole new cloud migration and management team, working with an experienced Managed Services Provider can actually save you money and headaches in the long run. In case you’re interested in the financials that support this statement, check out our extensive cloud management budget guide. Outsourcing cloud management can reduce risk to the business, especially during those critical early stages of launching your SaaS product when an unexpected failure due to lack of cloud expertise can ruin a product launch.

Will our SaaS Gross Margins Fall?

The short answer: probably not, but it depends. In a survey of traditional ISVs that migrated to the cloud, 82% of ISVs reported that their gross margins were greater or the same as on-premises software margins. Gross margins improved in the years following the initial migration due to price adjustments and cloud optimization work. 

Pricing your SaaS platform relies on a number of factors: competitors’ price points, cloud resource consumption, etc. There’s an enormous amount of tech literature on the subject of SaaS pricing, but top SaaS companies usually rely on a mix of cost, plus pricing and discussions with analysts and investors to arrive at the right price, then refine over time.

Some SaaS products deliver lower-than-expected revenues in the first few years after launch, due to the fact that the product is new to market and is often competing against a whole new group of competitors. This is one of the many reasons why we suggest the “migrate now, refactor later” approach that we’ll outline in the second half of this eBook. 

Is the Cloud Safe? 

Moving to a public cloud doesn’t make you more or less secure. However, if you don’t reconsider the new attack surface and adequately cover key areas of risk — or worse, assume the same security tools and practices you used on-premises are going to “work” on the public cloud — you’re in for some pain. It’s up to your IT team to determine how to identify, then mitigate the new risks inherent in public cloud and unique to your chosen architectures. Understanding how these pieces fit together, and where they satisfy or do not satisfy specific regulations, can be a significant challenge, and one that companies can’t afford to get wrong.

We’ve discussed this topic extensively in these resources: 

• Security Risks in Public Cloud (blog post)
• Infrastructure Security in a Cloud DevOps World (eBook)

How Long is this Going to Take? 

In our experience, launching a SaaS product can take anywhere from two months to two years. The biggest factors in how long it takes:

• The less refactoring you do, the faster you’ll move.. What you refactor vs. lift-and-shift is a balancing act all companies must learn. The good news is that unless you’re running an enormous database, a vendor-specific solution like Oracle RAC, or an archaic piece of technology, refactoring is a choice, not a necessity. We’ll discuss this in the second half of this eBook. 
• You’ll move fastest if moving to cloud is the #1 top-down goal of your entire organization, and everyone from CEO to finance is aligned and ready. We’ve discussed why setting aggressive top-down goals is so crucial here. 
• Compliance is often a significant slow-down in cloud migration projects. In fact, 88% of IT teams claim that compliance is a significant roadblock for cloud adoption. Outsourcing your cloud migration to a partner with compliance expertise is the fastest way to figure out how to architect for compliance.
• You’ll (probably) move fastest if you have a partner. Partners reduce the time and risk of migration. 

The best way to estimate timelines is to call up the leaders of other SaaS companies in your same space or market segment and ask them. 

Part 2: SaaS Migration Models

In the second part of this eBook, we’ll discuss the different migration models you can use to design your target cloud infrastructure for SaaS. 

Multi-Tenant vs. Single Tenant: Definitions

Before you migrate, it’s important to understand your current state of multi-tenancy and decide how multi-tenant you want to be on the cloud. Since this is the most important architectural decision you’ll make, let’s make sure to define our terms first. 

Single Tenant

Each SaaS customer has a dedicated server or infrastructure. The SaaS company maintains separate infrastructures for each of its customers with little or no shared resources. This is sometimes referred to as a “silo” model. 

Example: A healthcare SaaS company maintains a separate AWS account for each hospital that uses its software. The software is often customized per hospital and the AWS accounts are similarly configured but completely distinct.

This approach is normally seen when traditional software vendors try to migrate to AWS without refactoring their software. 

Benefits of Single Tenant Model: 

• Total tenant isolation – No need to worry about one customer potentially accessing another’s sensitive data. 
• Reduced blast radius – If a hacker (or employee misconfiguration) causes an outage, there’s a higher chance that it only affects one customer rather than your entire customer base. 
• Customization – Each instance of your software can be customized for each customer’s needs. For instance, if one customer has additional compliance requirements, they can pay more for additional features. 
• No refactoring required – If you’re a traditional software company that already operates in a single tenant model, you don’t have to refactor for AWS. 

Multi-Tenant

Multiple SaaS customers share infrastructure and resources, however, each customer’s data is isolated and remains invisible to other customers. This is sometimes called a “pool” model. 

Example: A retail SaaS company that displays package tracking information has a shared infrastructure and shared customer database, and all customers use this infrastructure. Walmart can’t see Target’s data, but their data is stored in a common database.

Multi-tenant SaaS is often seen in cloud-native companies or companies that have spent significant effort to refactor their software prior to cloud migration. 

Benefits of Multi-Tenant Model:

• Lower ongoing costs – Customers share resources and maintenance costs, leading to lower overall cost per customer. 
• Reduced customer onboarding time – No need to spin up dedicated resources for every customer. New customers can simply be added to an existing platform. 
• No customization – Every customer gets access to the same infrastructure, so no need to spend cycles customizing infrastructure to each customer. Note – this can be a positive and a negative!

Should You Rearchitect for Multi-Tenancy? 

If you read the official literature on SaaS architecture design, you will see most recommend you move towards a fully multi-tenant model. Why? For all the reasons listed above. It’s cheaper to scale, easier to manage, and lets you move faster. There’s no need to scale out an entire new stack every time you onboard a customer. You don’t have to maintain separate customer environments or replicate changes across each customer environment. Nothing on the application or infrastructure level is customized per customer, so your development team is spending less time on unique configurations and more time on universal features. 

If you currently run single tenant on-premises, we usually recommend that you get into the cloud first and rearchitect later. Here’s why: 

• Efficiency — Even companies that lift-and-shift to cloud see some cost and agility benefits. Better to reap those benefits during the (likely long) period you’re rearchitecting your software. 
• Time-to-Market —  IT departments are usually under a lot of pressure to launch SaaS to market quickly. Migrating first and rearchitecting later is obviously faster. 
• Education —  When you migrate to the cloud, you learn a lot about the technical aspects of running a cloud environment. That education process will make future rearchitecting processes more efficient. 
• Compliance —  If you’re currently running single tenant, figuring out compliance in a multi-tenant environment can take time and likely requires outside help. Keeping your applications single-tenant for now can put off these concerns for now.
• Metering — It’s much easier to understand how much data/compute each tenant requires (and to bill them accordingly) when each tenant is isolated.  

In the remainder of this section, we’ll outline two different approaches for maintaining single tenancy and migrate your application to the cloud with minimal disruptions. 

Approach #1: Silo App and Database Tiers

This approach maintains a separate stack for each customer (tenant). For most ISVs, this is a direct translation of their existing on-premises infrastructure. 

If you choose this approach, you must decide what mechanism to use to maintain tenant isolation. For most use cases, there are two options: maintaining tenant isolation by network or by account. 

Model 1: Separation by Network

In this model, all the tenant solution deployments are in the same account, but the level of separation is at the virtual network layer (ex. VPC or vNet.) For every tenant deployment, there’s a separate virtual network, which provides logical separation between tenants. 

The key to scalability in this model is the concept of a hub-and-spoke architecture. The idea is to keep critical security and management tools centralized in a hub network, connected to spoke networks that contain separate tenants. 

What’s in the Hub Network?

– Bastion Host

• NAT Gateway (enables instances in the private subnet to initiate outbound IPv4 traffic to the Internet or other services)
• Active Directory
• Configuration Management Master 
• Intrusion Detection Software

How are Tenants connected to the Hub? 

• Peering between Tenant network and Hub networks, but not from one Tenant network to another.

Do Tenant networks need to be identical? 

No, they appear identical in this diagram because for the most part, that’s the pattern we see in SaaS companies. Tenant networks can be completely different from one another. However, we find it is advantageous to have Tenant networks as similar as possible. Why? Repeatability. 

How are new Tenants onboarded?

Create new Tenant environments using pre-defined templates (ex. CloudFormation, Terraform, ARM). Build a template for a standard Tenant network — so all you need to do to deploy tenant infrastructure is click a few buttons and set up some IAM Users in a pre-defined Role. These templates are extremely comprehensive and can include infrastructure choices like server instances and storage, complex networking schema, and security configurations. Central IT can create permissions allowing different departments the right to spin-up specific infrastructure templates. This achieves rapid time-to-market without sacrificing the governance standards of the organization. Collect these templates in a central repository. 

Templates ensure that complex builds for new customers are done quickly and accurately, hitting all the marks for security, compliance, and executive oversight.

Model #2: Segregation by Account

Separating tenants by network can be a simple and effective way to maintain tenant isolation. However, if you’re also maintaining SDLC tiers in a separate network, your architecture can get complicated quickly. This is why SaaS companies are increasingly exploring multi-account architectures. 

Different cloud platforms handle multiple account management very differently. For AWS, use AWS Control Tower, a simple solution that helps automate the process of setting up and configuring multiple accounts. Best practices for a multi-account architecture are embedded in the solution, making AWS Control Tower perfect for companies with complex workloads and larger teams that want to quickly migrate to AWS. If you want more details on segregating tenants by account on AWS, download our SaaS Architecture Guide or our Guide to AWS Control Tower. For Azure, the entire account hierarchy is different; you can have multiple Azure or O365 subscriptions under the same organization, making multi-account management more seamless. 

Approach #2: Silo Web and App Tier, Shared Database

The second approach keeps the web and application tier siloed, but transitions your data tier to multi-tenant. This approach of course requires more refactoring work on the database tier, to either host multiple databases in the same database or to change schema to a cloud-native or NoSQL database. This process is much easier if you have a data access layer that abstracts away the details of the database.

So how does traffic flow in this solution? The easiest way is to handle everything with hosted zones in DNS, so that you can have something like client1.app.com, client2.app.com, etc., and then behind that, a shared database with a tenant ID column. If you have virtual machines behind a load balancer, you need to make sure the machines have the proper permissions to the shared database using IAM Roles. This allows you to control access to your storage and ensures that data isn’t accessed outside of a tenant’s permissions. 

If you’re interested in learning more about this approach, we highly recommend AWS’ SaaS Storage Strategies eBook. It’s an excellent overview of how to partition storage in the most effective way for your application. 

To perform the actual migration, the common method is to migrate tenants one-by-one to the shared database solution. This allows you to reduce the risk of exposing multiple clients to migration error during a single client’s migration. 

The Hybrid Tenant Model

It’s important to note for many ISVs, some clients require complete tenant isolation at the data and compute level, and some are comfortable with shared resources. Therefore, it’s very common for an ISV to have a hybrid approach to tenant isolation. Again, this is made much simpler if there’s an existing data access layer that can route traffic to appropriate pooled or siloed database resources. 

Part 3: Modernization and Future Planning

The approaches described in this Guide focus on minimal disruption to your existing application and delivery. However, there are often a few choices to make during or immediately after the migration process that are both low-medium effort and high impact that are worth making. 

Fully-Managed Databases

The simplest approach to migrating your databases to the cloud is to run them on a regular virtual machine. In our experience, 90% of companies can migrate their database to a fully-managed database service with just one or two days of effort, which translates to a huge long-term win. Companies that migrate to a fully-managed cloud database can see hundreds of hours of saved time and effort spent in the first year alone. 

Amazon RDS and Azure Database are both great options for SaaS companies. They have (almost) every database platform from SQL Server to Cassandra and many other built-in tools to make the transition from on-premises easier. 

We recommend the following approach, use a fully-managed database unless there’s a very good reason that you can’t. Test out migrating your database to a fully-managed database early in the process to see if it’s even possible, then plan around it. 

Tenant Provisioning

If you maintain a siloed structure in the cloud, you will need to replicate entire systems in order to add new customers (tenants). When you first migrate, this may not be a top priority, but as you grow, reducing customer onboarding time will be crucial. The secret to automating tenant provisioning is utilizing your cloud platform’s native Infrastructure-as-Code (IaC) tools and a configuration management tool. 

IaC offerings like AWS CloudFormation and Azure Resource Manager enable engineers to manage infrastructure through the use of declarative templates, utilizing the data format language, JSON. The value of this approach is tremendous. Templates can be checked into a source code management system, linted and validated using tools and IDEs. Entire environments can be quickly duplicated, modified and deployed to build out new tenants. Templates can also kick off bootstrapping, creating a seamless bridge into the operating systems where machine images and configuration management can take over. In addition, any infrastructure change can have an audit trail and proper process built around it, automated to reduce human error and disparate configurations. Over time, you can carefully control common security and/or compliance configurations. Your company can develop a collection of templates for various tenant use cases (i.e. by pricing tier, industry, product suite, etc.) 

Terraform is a popular alternative that connects to cloud service APIs directly rather than using CloudFormation. Many companies prefer Terraform because it’s platform-neutral.

The alternative, build your environment manually in the cloud console. As time goes on, it is highly likely the environment will change and any additional environments will be built differently with many custom configurations that require custom documentation. Each environment has its own deployment process, and likely its own “specialists” – so deployment is dependent on the availability of one or two key engineers. Additionally, there is a high chance of “forgetting” something important, such as a key security configuration. 

We’ll admit, writing cloud templates has a steep learning curve, especially for systems engineers. That’s why we recommend this as a post-migration task for new cloud teams or outsourcing this automation to a partner to get it up and running more quickly. 

Building a Multi-Regulatory Compliance Framework

Today’s SaaS providers often find themselves needing to satisfy the security and compliance requirements of many different types of customers. An identity management platform may have clients in banking, healthcare, and hospitality. Each of these customers will have different concerns around security, and may ask to audit the SaaS platform against different industry regulations. Measuring the same organization against PCI, HIPAA, HITRUST, GDPR, ISO, and SOC2 can be very challenging for a mid-sized software company.

Each regulation will have dozens if not hundreds of different control groups, and your information security team will need to translate your technology choices into different formats while covering multiple special requirements. 

If this sounds like you, make a long-term goal to transition from different environments and requirements for every customer to a single framework that satisfies all of your compliance requirements. We call this a Multi-Regulatory Framework —  allowing you to address all of the underlying infrastructure requirements, and enforce the right security and information logging systems across all of your workloads. Fulfilling all of the various audit requirements is just a task of reformatting the same data to fit each individual audit.

So, how does this actually happen? Start by translating all of your compliance frameworks into their required infrastructure configurations. Remove all of the regulatory language variations and find the common core. You’ll discover the result is a relatively short list of required infrastructure configurations that are very common across PCI, HITRUST, SOC2, etc. At TechCelerated, we use a list of required features very similar to this: 

Once you’ve consolidated all of your required security configurations into a single matrix, ensure that every tenant maintains these configurations (with templates and configuration management, see above). Once you’ve baked these requirements into core templates, you’ve made it easy to build-out new compliant customer environments without having to do a majority of custom configurations. When a customer asks for documentation proving you meet a particular compliance framework, you can provide your core approach to infrastructure security, which usually satisfies 90% of common questions. 

We’ve open-sourced our most common architecture designs that meet the above multi-regulatory requirements: 

• AWS Architecture Design Guide
• Azure Architecture Design Guide

Summary

Launching your SaaS product to market is a huge milestone in your company’s history. We hope this guide helps you migrate quickly and prioritize elements of your application that should be modernized. 

Building a fully-automated cloud infrastructure is complex, and most ISVs companies want their team to focus on delivering better software — not configuring and maintaining infrastructure. That’s why companies turn to TechCelerated. We have worked with hundreds of SaaS companies to build and manage their AWS environments. If you want to learn more about TechCelerated, visit our website at www.techcelerated.com or contact us to get a free quote.