The Going On-Premise Survival Handbook

Managing Release And Upgrade Cycles

Reduce Upgrade Cycles


One of the biggest shocks to SaaS companies delivering software on-premise is the longer release cycles. In addition, customers may not keep versions up to date, with upgrade cycles up to one year. This puts a lot of strain on the team that has to support older versions of the software.


Many customers are wary of upgrading complex systems because they often break and require full reinstalls and/or lead to an outage. If you can provide simple and stable upgrades, teams are usually more open to more frequent upgrades and it is possible to get down to bi-weekly upgrade frequency with most of your customer base.

Manage Releases And Versioning


SaaS businesses are used to multiple-times-a-day release cycles. Shipping versions on-prem, even with be-weekly updates, poses a challenge for them, especially if the system is a mix of microservices with loosely coupled release cycles.


Again, it is important to use the same platform for your on-premise and cloud deployments. We recommend using Kubernetes for both.


Use Helm, the Kubernetes package manager, and its best practices to transition microservices releases to a package-style approach with clear dependencies. We have a first-class integration with Helm to simplify the build and deployment process.


Picking a right versioning scheme is mission critical for on-premise deployments. Unlike in SaaS deployments, versioning plays a very important role as it is used to inform customers about the frequency of software release cycles and the risks associated with the upgrades.

Adopt semantic versioning and set up clear dependencies between components.

Use clear signaling to the customer on the upgrade risks by using major, minor and patch versions of the software.

For example, with semantic versioning customers would expect patch versions 2.5.1 and 2.5.2 upgrades to be trivial and backwards compatible, upgrades from 2.6.3 to 2.7.3 be possible but a bit more risky and involving potential migrations, and upgrading 2.0.0 to 3.0.0 to be a major undertaking.


Make sure customers are used to a stable upgrade schedule, this allows them to set up planning their side and include upgrades in their development milestones. Here are a couple of recommendations on the upgrade schedules:

Publish bi-weekly upgrades for stateless services, so most of the customer’s deploys are up to date. These upgrades should not run any migrations or perform any dangerous or risky operations. On a monthly schedule, provide a more complex upgrades that involve database schema migrations.

We upgrade the platform (Kubernetes and dependencies) approximately every two months using Telekube’s LTS release upgrade schedules. The Golang programming language is a very good example of a team publishing upgrades on a predictable schedule (in this case, every 6 months).

Manage External Dependencies


Many on-prem deploys are air-gapped, which means they can not make any outbound internet calls to function or update. This makes it impossible to provide installations, patches or updates which pull dependencies from external resources.


We designed our deployments to be entirely self-sufficient using the following methodologies:

The build process scans all Kubernetes docker image dependencies, and packages them with every install. See documentation on tele build.

We ship a self-contained Docker registry that hosts the images, so a cluster remains highly available and can pull images from local registries instead of pulling from the internet.

Publish Installable Software


SaaS companies are usually not familiar with the process of publishing downloadable software. Sending out binaries without an official, centralized way to download and validate software appears unprofessional and results in a bad user experience. Customers end up sharing FTP password protected endpoints and sending passwords over email. In addition, you need a seamless process for sending out updates, patches and monitoring the status of each download.


We built a way for our customers to publish applications so their users can install, download and pull updates manually (for offline situations) or automatically, depending on their security and deployment practices.

Next >> Road to Production