Most organizations running ServiceNow can name their edition, their release family, and their module lineup without hesitation. Fewer can say with confidence which of five deployment patterns was chosen on purpose.
There are five ways to run the platform, and all five fall out of two decisions.
Decision One: Who Holds the License
Either the organization holds it directly, or an MSP delivers ServiceNow as a managed service on the organization’s behalf. That single choice determines who owns the relationship with ServiceNow, who carries upgrade responsibility, and how much control the end customer keeps over release timing.
Decision Two: Where It Runs
Three options sit under this decision: ServiceNow’s own cloud, ServiceNow-managed infrastructure on Azure or AWS, or an organization’s own infrastructure using Private Stack, ServiceNow’s self-hosted deployment model for sovereignty, air-gapped, and compliance-restricted environments. If an MSP is delivering the service, there’s a third decision layered on top: a dedicated instance per customer, or a shared instance separated into domains.
The Distinction Everyone Collapses
ServiceNow running as SaaS on Azure or AWS gets confused with self-hosting on those same clouds constantly, and they are not the same decision. The Azure or AWS SaaS option is a procurement and data-residency play. ServiceNow still owns and operates the application. Self-hosting on that same infrastructure through Private Stack is a completely different world: the organization or its partner owns and operates every layer, load balancer, application server, and database, with ServiceNow supplying the application software and upgrade packages. Same underlying cloud, entirely different operating model.
If a partner is hosting the instance, almost everything else follows from one question: dedicated or shared. Ask that first, and the rest of the tenancy conversation gets a lot shorter.
Domain Separation Only Really Goes One Direction
For MSPs choosing between a dedicated instance per customer and a shared instance split by domain, this is the detail that gets missed most often. Domain separation can be disabled, but it can’t be cleanly removed. ServiceNow’s own guidance is direct about why: a domain-separated instance still runs on a shared database, which undermines any requirement for true data isolation even after separation is turned off. Practitioners who’ve actually tried to walk it back report the same thing: disabling the two properties that control data and process separation gets you partway, but a genuinely clean reversal typically means standing up a new instance and migrating everything over, not flipping a switch back.
Reversibility Deserves More Weight Early
That one-way quality is exactly why reversibility belongs in the decision from the start, not as an afterthought once a pattern is already running. Ranked from most to least reversible: ServiceNow’s own cloud and ServiceNow-managed Azure or AWS sit tied at the top, both leave every future option open since ServiceNow still operates the application either way. A dedicated MSP instance comes next, the cleanest exit among the MSP-delivered paths. Self-hosted Private Stack ranks below that, reversible in principle but heavier to unwind given how much infrastructure an organization or partner owns directly. A shared, domain-separated instance sits last. It’s the fastest and cheapest way in, and the hardest of the five to leave.
Start From the Constraint, Not the Preference
Sovereignty requirements, industry regulation, and contract terms pick the pattern far more often than architectural taste does. A bank with strict data residency rules doesn’t get to prefer ServiceNow’s cloud if regulation says otherwise, and an MSP serving cost-sensitive customers doesn’t get to prefer dedicated instances if the economics don’t support it. The deliberate version of this decision starts with the constraint an organization is actually operating under, then works forward to which of the five patterns satisfies it, rather than starting from whichever pattern feels most familiar and hoping the constraints line up.
This is the same framework KeenStack works through with a client the first time the question of where an instance should live actually comes up. Getting it right early matters more than most teams expect, since the CMDB and everything built on top of it inherits whatever assumptions the underlying instance pattern locked in on day one.
Not sure which of the five patterns your organization is actually running, or whether it still fits? Get in touch with KeenStack and we’ll help you map it against your actual constraints.
