The problem is 2-fold, 1) a business/contract problem 2) a technology problem.
The business problem is that your on-prem customers need to accept the idea of being being upgraded to the latest version automatically or on a specific cadence (ie every day, week, month, etc). If they're not willing to accept this, they need to pay you more for the extended support (LTS) of an older version. Many enterprises will be hesitant to accept auto-updates b/c they fear that your application will break during update, you can alleviate that concern with technology as well.
The technology problem can be overcome by using a cloud-native architecture for your on-prem product. This will ensure that your product has the level of reliability that is needed for true modern on-prem deployments you're describing. It will allow customers to do canary updates, rolling updates that will minimize downtime (just like you do for SaaS based CD). Multiple repos, different components, no problem, package them as Docker containers and then deliver the new manifest (k8s, swarm etc) that includes the new images. The key to success here is automation. You have to have a level of rigor for automating every production change with automation (often packaged as a new migration container for the new version). There are other systems you can build to solve for this as well, including release channels that will allow you to push different versions to different customers or staging environments based on specific licenses for each customer.
We've spent the last 4 years turning this problem into a product: www.replicated.com and it currently powers the on-prem versions for Travis CI, CodeClimate, CircleCI, Terraform Enterprise, Gradle and many others who know a lot about CI/CD.
The problem is 2-fold, 1) a business/contract problem 2) a technology problem.
The business problem is that your on-prem customers need to accept the idea of being being upgraded to the latest version automatically or on a specific cadence (ie every day, week, month, etc). If they're not willing to accept this, they need to pay you more for the extended support (LTS) of an older version. Many enterprises will be hesitant to accept auto-updates b/c they fear that your application will break during update, you can alleviate that concern with technology as well.
The technology problem can be overcome by using a cloud-native architecture for your on-prem product. This will ensure that your product has the level of reliability that is needed for true modern on-prem deployments you're describing. It will allow customers to do canary updates, rolling updates that will minimize downtime (just like you do for SaaS based CD). Multiple repos, different components, no problem, package them as Docker containers and then deliver the new manifest (k8s, swarm etc) that includes the new images. The key to success here is automation. You have to have a level of rigor for automating every production change with automation (often packaged as a new migration container for the new version). There are other systems you can build to solve for this as well, including release channels that will allow you to push different versions to different customers or staging environments based on specific licenses for each customer.
We've spent the last 4 years turning this problem into a product: www.replicated.com and it currently powers the on-prem versions for Travis CI, CodeClimate, CircleCI, Terraform Enterprise, Gradle and many others who know a lot about CI/CD.