Instance Strategy Mistakes I See Repeated Across Enterprises

[Abhijeet Upadh2]

Instance strategy is one of those topics everyone thinks they understand—until it’s too late to change. I’ve walked into multiple organisations where the instance strategy was treated as a one-time technical decision rather than a long-term operating model choice.

The most common mistake is assuming that fewer instances automatically mean better governance. In reality, a single shared instance across vastly different business units often creates political gridlock. Every change becomes a negotiation, every release is delayed, and innovation slows because the blast radius feels too large. What looks efficient on paper becomes paralysing in practice.

The opposite mistake is equally damaging: spinning up instances too easily. I’ve seen environments with multiple “temporary” instances that somehow became permanent, each drifting into its own version of the truth. Integrations multiply, data diverges, and leadership loses confidence because reports don’t align.

What’s usually missing from these decisions is a clear understanding of why separation is needed. Regulatory isolation, data sovereignty, and fundamentally different operating models are valid reasons. “Different preferences” or “we want autonomy” usually aren’t.

Another overlooked aspect is upgrade velocity. More instances mean more upgrades, more testing cycles, and more coordination. If your organisation struggles to complete one upgrade cleanly, multiplying instances won’t fix that—it will amplify the problem.

Strong instance strategies are revisited periodically, not set in stone. They evolve as organisations mature, merge, divest, or change risk appetite. As architects, we need to challenge instance decisions not just technically, but organisationally. Poor instance strategy doesn’t fail loudly—it slowly suffocates delivery.

[tiagomacul]

This is a necessary discussion because the choice between 'Single vs. Multi-instance' is almost never binary or purely technical. As architects, we must have the humility and business acumen to admit that the right answer often depends on variables that exist far outside the data centre.

In many cases, the most 'technically elegant' architecture on paper suggests consolidation, but the business strategy dictates the exact opposite. A classic example is a Divestiture scenario:

• The Technical View: Maintaining a single instance might seem easier for standardising processes and shared integrations.

• The Business Reality: If a company is preparing to split into two separate entities, the smartest strategy—and the least expensive in the long run—is isolation into separate instances from day one. Trying to untangle processes, data, and licensing from a single shared instance in the middle of a business unit sale is an operational and legal nightmare.

The choice of an instance strategy must pass through a filter of non-technical factors:

1. Funding Model (Chargeback): How does each business unit pay for the platform?

2. Decision Agility: Can HR afford to wait for Finance’s testing cycle to deploy a new portal?

3. Legal Compliance: Are there data residency requirements (GDPR/other) that mandate geographic isolation?

There is no "silver bullet".

The best instance strategy is the one that serves the company's operating model, not the one that satisfies architectural aesthetics. As emphasized in the Now Create methodology, design must always be Value-Oriented: if the instance structure creates friction for the business, the failure wasn't technical—it was a failure of governance