An enterprise's database licensing is tied to processor cores, and a virtualisation change unexpectedly multiplies the licence cost. How should licensing influence architecture?

What happened

Core-based licensing counts the cores the software could run on, not the cores it uses. In many virtualised environments, a licensed workload on a cluster can require licensing every core in that cluster, because the hypervisor could move it anywhere.

So a decision made for operational reasons — consolidating onto a shared cluster, enabling live migration — multiplies a licence cost that nobody in the change process was thinking about.

Why this is architectural

Licensing terms create constraints that behave like technical constraints but are invisible in every technical review. They shape:

• Placement. Licensed workloads may need dedicated hosts or affinity rules, which conflicts with consolidation and with elastic scheduling.
• Scaling model. Vertical scaling of a core-licensed workload may cost more in licence than in hardware, which inverts the usual scaling ladder.
• Cloud migration. Bring-your-own-licence terms differ by provider and by instance type, and some arrangements are substantially less favourable.
• High availability. Standby nodes may require full licences, making a warm standby cost twice what the infrastructure suggests.
• Non-production environments, which may need licensing at the same rate, making a realistic performance test environment expensive enough that teams do without one — a reliability consequence of a commercial term.

How to handle it

1. Include licence cost in architecture review for anything using licensed software, with the same seriousness as infrastructure cost. It is frequently the larger number.

2. Model placement constraints explicitly, and treat "licensed workloads run here, under these rules" as part of the deployment architecture rather than as an operational detail.

3. Involve procurement early. Terms are negotiable, and architecture choices affect what can be negotiated. Discovering a constraint after committing to a design forecloses options.

4. Evaluate open alternatives on total cost, including migration effort, operational burden and feature gaps — not on licence cost alone. The migration is frequently more expensive than the licence in the short term and cheaper over a long horizon, and that horizon should be stated.

5. Re-examine on every infrastructure change. A virtualisation, cloud or consolidation change can alter licence exposure without touching the application, and there is no technical signal that it happened.

The general lesson

Commercial terms are architectural constraints. An architect who does not know the licensing model of the critical components will eventually design something that is technically sound and commercially unaffordable — and will find out after the design is committed.