SaaS Migrations: Changing the On-Premises Mindset
Finding the right SaaS deployment model, that meets customer needs
Anubhav Sharma
Amazon Employee
Published Jul 23, 2024
Over the past 5 years at AWS, I've helped many independent software vendors (ISVs) transition from on-premises to a Software-as-a-Service (SaaS) delivery model. In fact, migrating from on-premises to a SaaS model can prove to be more challenging than building a new greenfield SaaS solution. This is true not only because of the technical complexities of the software that have evolved over multiple years, but also the company's culture, since the business teams are accustomed to delivering the software to the end customer in an on-premises model. Breaking the on-premises mindset is the key to success.
In a typical on-premises model, ISVs deliver their “software” to the customer instead of a “service”. This usually means bundling the software as an executable or docker image, as an example, along with the instructions to deploy the software inside the customer's environment. It's up to the customers when they want to install or upgrade. Also, since the customer deploys the software in their location, they can build direct database integrations if they wish. Occasionally, ISVs also perform customizations specific to the customer.
So the result is a complicated ecosystem of customers running on different versions, with occasional code customizations. This, coupled with the fact that ISVs normally don't have visibility into their customer environments, triggers the desire to adopt the SaaS model.
Coming from the on-premises model, I have seen ISV product and sales teams carry over the on-premises mindset. The immediate reaction to the SaaS migration is to offer the on-premises software in a "cloud-hosted" model, by creating separate environments for each tenant. The end customer still decides when they want to "opt-in" for the new release. So, essentially, instead of giving the software to the end customer, the ISV manages the deployment and upgrades of the software inside their own AWS account(s). In this model, you take away the pain from the end customer by not having them install, upgrade, and manage the software. But customers will still run on different versions. I have seen ISVs running dev, test, and prod environments for each customer in this case to align with the software development lifecycle of the end customer.
The ISV, in this case, is mostly acting as a managed service provider (MSP) rather than offering the software as a service. Now, this could be a valid model when the ISV has a handful of customers and, for various reasons, cannot push their end customers towards the SaaS model. But given the overhead on the ISV to manage bespoke customer deployments, this model is not scalable and does not align with the service mindset of a SaaS model.
Transitioning to a service mindset typically means the end customer values the service they are getting. What this normally means for the end customer is:
- Not worrying about the version of the software or testing every new software release.
- Not having tight (direct database) integrations with the software, instead leveraging API or messaging-based interfaces.
- Ability to configure the software and workflows via an interface, rather than opting for code customizations.
But this transition will take time for the ISV, and I have seen a few variations of how ISVs approach the shift. There are pros and cons for each approach.
In this model, the ISV hosts the SaaS solution inside their own AWS account. The ISV offers a test and production environment for each tenant (end customer). Each tenant is on the latest release (N), but any new release (N+1) is deployed on the test environment first. The end customer is given a specific amount of time to test and validate the new release before the N+1 release is rolled out to the production environment.
This model makes certain assumptions and improvements:
- The tenants are now running on a consistent release and use a common code base.
- The ISV has standardized customizations (if any) using configurations or feature flags. This requires “extensive” research and effort, understanding the variations of customizations and converting them into features.
- There are no direct database integrations, instead the tenant accesses the application using standards like APIs, files, messages, etc.
- The ISV has implemented a “control plane” that has constructs like tenant management, tenant onboarding, centralized observability, and a deployment pipeline that upgrades tenants with the latest release. Importance of control plane is “huge” in the SaaS architecture.
This brings the ISV closer to the service mindset and gives some flexibility to the end customer regarding upgrades. But there are still challenges with this model, especially managing multiple customer environments and software versions. A common challenge in this model is the complexity surrounding fixing bugs. The ISV will need to address the fact that a critical bug will need to be fixed in multiple simultaneous releases. This adds further complications and will affect the agility of the SaaS business.
The next evolution is removing the burden of the N and N+1 release. This means the end customer assumes that the SaaS solution always delivers on its promise, and there is no need to worry about upgrades. After all, it is the responsibility of the SaaS provider to provide a consistent experience across releases and ensure backward compatibility to prevent breaking changes.
We are still assuming a silo model, where tenants don’t share resources. The assumption so far is that the ISV hasn’t invested time to re-architect the on-premises application to share resources across tenants.
This model offers further improvements:
- Rolling out new releases to tenants as soon as they are ready. I have seen cases where the ISV delivers advance notice to the end customers regarding the date their environment will be upgraded to the latest release.
- Removing the burden from the end customer to test the latest release. The ISV ensures that the release is tested against all use cases.
- The ISV offers close to zero downtime during upgrades, using techniques like blue-green deployments.
- Optionally, the ISV can also upgrade tenants in waves, using staggered deployments.
The end-customer enjoys the software as a service, instead of paying attention to the versions or testing releases.
Although the silo model has met the business goals of a service mindset, you can still argue that it is not taking advantage of the economy of scale and adds operational overhead. In fact, unless you re-architect to a pooled multi-tenant model, where tenants share resources, you will not scale beyond tens or hundreds of tenants. So, it is essential to evaluate the architecture for scale, agility, growth, and expansion.
It's challenging to move towards a SaaS model if you are adapted to delivering in an on-premises model. Depending on the profile of your tenants and internal alignment within your organization, you may opt for any of the variations I described in this post. You can mix and match these variations depending on your use case. The "no pain, no gain" proverb is quite suitable here. Moving from a monolithic on-premises application to a multi-tenant pooled SaaS model needs work, but will also reward your business in the long run.
I highlighted a few variations that I have seen in the wild. If you have seen something that is different and has worked well for you in the past, please add a comment, or reach out and let's talk!
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.