The other poster made some very reasonable suggestion. The answer is largely depend on your app architecture. For example, if it's as simple as an web-app + db, then docker compose image should be sufficient. Do your best to extract some of the more generic features such as email list, storage, log server out of your app and have a shared service for those if possible.

Honestly, managing on-prem VM is actually one of the easiest thing to do in my experience if the entire architecture is in a single bundle.

For the rest of your customers, you can still run K8s. If you aren't concern about scaling, then run webapp + db in a single pod. This is somewhat of an anti-pattern because it changes your ability to scale. If you do want to scale for an individual customer, then move db into its own pod, and then connect to it from your webapp.

Personally, I would rather run your ephemeral load such as webapp in K8s, then run databases on VMs to make it a bit easier to manage.

Depends a lot on what the new application architecture looks like, but one option is this: https://docs.microsoft.com/en-us/azure/azure-resource-manage...

You could use the same templates to deploy both the vendor-hosted and customer-hosted version of the app.

The physical architecture can be anything. A single container, the PaaS App Service, VMs, etc...