TLDR: Databricks Apps is not a 1:1 ServiceNow replacement. Its intended uses are internal web apps tied to data/AI, especially data entry forms and custom operational interfaces; it supports Python or Node.js, React, local IDE-based development, Git-backed deploys, and CI/CD with Declarative Automation Bundles and GitHub Actions.

For your examples

• Cloud PC management console: good fit, assuming it is mainly a custom UI over APIs/data rather than deep ServiceNow-native workflow logic.
• Laptop asset intake form: strong fit; “data entry forms” is an explicit Apps use case.
• Hardware refresh scheduling UI: medium fit; the front end is a fit, but you should validate the scheduling/notification back-end separately.
• M&A transfer wizard: good fit if it is mostly guided forms plus API orchestration.
• Software catalog / app store UI: medium fit; good for the catalog/search interface, but evaluate fulfillment and entitlement workflows carefully.

Cost savings

Possible. Databricks Apps is usage-based: apps are billed per running hour based on provisioned capacity; Medium is 0.5 DBU/hour and Large is 1 DBU/hour, and stopped apps do not incur cost.

The strongest savings case is when you can retire separate hosting/infra work and reduce operational overhead. 

Performance

More controllable, likely to be faster. You can explicitly size apps at Medium (up to 2 vCPUs / 6 GB) or Large (up to 4 vCPUs / 12 GB), and horizontal scaling now supports multiple instances behind one URL for higher availability and concurrency, with zero-downtime deployments; compute cost scales linearly with instance count.