Telephony replacement projects tend to arrive with the conclusion already attached — the incumbent system is old, therefore the replacement should be cloud. Sometimes that is right. It is worth reaching by argument rather than by default, because the failure modes are quite different and one of them is much more visible to customers.
Where on-premise still wins
High and sustained call volumes. Per-user cloud pricing is straightforward and predictable; at sufficient scale it also becomes the largest line in the communications budget, and owned infrastructure amortizes better.
Site resilience requirements. An on-premise system with local trunking keeps working through an internet outage. A cloud platform does not. For a contact center, a hospital or an operations site, that distinction can be the entire decision.
Recording and data handling. Where there are specific requirements about where recordings are held and who can access them, keeping the recording platform in a known location is simpler to evidence than negotiating it contractually.
Where cloud wins clearly
Multi-site operations, particularly with small sites. The cost and complexity of deploying and maintaining call control at fifteen branches is substantial, and centralizing it is a real simplification.
Distributed and remote working, where the endpoint is a laptop or mobile rather than a desk phone.
Capital avoidance and pace. No hardware refresh cycle, no capacity planning, and features arrive without a project.
The hybrid pattern
Most organizations of scale land on a split: on-premise or hybrid call control at the primary site and any operationally critical location, cloud for branches and remote users, with a single dial plan across both.
That is more design work than either pure option, and it is usually the right answer. The important part is deciding deliberately where the boundary sits rather than accumulating it by accident over three separate projects.
The part that carries the risk
Whichever platform you choose, cutover is where telephony projects fail visibly. Number porting has external dependencies and fixed lead times outside your control. Parallel running is worth the extra cost wherever the topology permits it. And the rollback plan needs to be tested rather than described, because the failure is immediate and every customer sees it.