Main idea

Granting a large account that its payroll product's database lives in its own Azure environment opens a question nobody asked: does that customer also control schema changes, and therefore the pace of production releases?

The two are not linked, and conflating them is expensive. A customer asking to keep its data on its own side is not asking to govern the vendor's migrations. It wants control over where, not over how the product evolves.

Hence a boundary that states itself in one sentence: the customer controls where their data lives, the vendor controls how the product evolves.

Why it matters

This boundary is what makes the arrangement viable. Without it, granting the hosting amounts to handing over the delivery calendar, and the vendor loses what makes an online service what it is.

It also gives a clean acceptance criterion: hosting on the customer's side is compatible with this model only if migrations stay automated and vendor-driven, within an agreed security framework.

Nuances and limits

The boundary is clear to state and contested in practice: a customer whose internal policy forbids any unapproved change cannot accept it as is.

And it doesn't settle everything: where the data sits carries consequences for monitoring and for responsibilities, which still have to be decided separately.

Open questions

• What do you do with a customer whose governance forbids precisely the automated migrations?