The cloud debt crisis coming for Canadian enterprise IT

Twenty-five years ago, taking a government consulting course in Toronto, I met a manager from a mid-sized Canadian packaging company. His company had implemented SAP. The pitch was familiar: one integrated platform, unified operations, real-time financial visibility.

The accounting module produced numbers. Reports ran. Dashboards showed figures. The system appeared to be working.

But nobody knew if the numbers were right.

Not wrong - uncertain. The previous accounting system had been decommissioned. The manual cross-checks were gone. The experienced accountant who might have glanced at a report and said 'that doesn't look right' had been replaced by a system that produced outputs with complete confidence and no verifiability.

Six months after go-live, the company was bankrupt.

The numbers might have been right. They might have been wrong. Nobody could tell. And that uncertainty - not the numbers themselves - is what killed the company.

I think about that story constantly when I look at how Canadian enterprises are implementing cloud today.

We Are Making the Same Mistake Faster

Canadian organizations are investing heavily in Microsoft Azure. The Microsoft sales motion is built on continuity - the pitch is 'move what you already run on-premises into our cloud.' Active Directory becomes Entra ID. Windows Server workloads move to Azure VMs. The same applications, the same operating model, hosted by Microsoft rather than in your own data centre.

This is not transformation. It is hardware outsourcing at cloud scale. And the people executing it - talented infrastructure engineers who understand Azure services, networking, and identity - are being called architects.

They are not architects. They are infrastructure engineers. The distinction matters enormously.

An infrastructure engineer answers: how do we provision and manage the cloud resources? An architect answers: how do these systems relate to each other? What happens when a dependency fails? Where does data flow, who owns it, and how will we know if something is producing incorrect results?

In most Canadian enterprise cloud programs, the first question is being answered. The second is not being asked.

Cloud Amplifies the Problem

On-premises, sprawl was constrained by hardware procurement. You couldn't spin up a server without capital approval. That friction was inefficient - but it slowed the accumulation of undocumented architectural decisions enough that someone occasionally reviewed them.

Cloud removes that constraint entirely. A developer with the right permissions can provision a new service, create a new database, deploy a new API endpoint, and wire it to three other systems in an afternoon. Each decision is locally reasonable. Twelve teams making locally reasonable decisions produce an environment that nobody designed and nobody fully understands.

Three years in: fifteen different integration patterns, four different identity approaches, storage containers whose access policies were set by someone who left eighteen months ago, data flowing across system boundaries in ways that nobody has mapped. And somewhere in that environment, something is producing outputs that may be right, may be wrong, and cannot be verified - because the architecture that would make verification possible was never built.

The packaging company's question - how will we know if this is working? - is the question nobody in most Canadian cloud programs is asking today.

The Reckoning Is Coming

This pattern has a historical precedent. The ERP wave of the 1990s produced the same dynamic: organizations invested in powerful platforms, implemented them without architectural discipline, and called it a success. Twenty years later, the biggest IT services market in Canada was ERP remediation - billions spent untangling decisions made by organizations that confused software implementation with transformation.

Cloud is following the same arc on a compressed timeline. The early signals are already present: cloud costs running three times projections, security incidents with root causes in architectural gaps nobody designed around, integration failures diagnosed by reading through code because the documentation was never written.

My estimate: three to five years before the pain is visible enough to drive remediation investment at scale. The reckoning will arrive through a combination of spiraling costs, security incidents, and digital transformation programs that fail because the systems they depend on are too fragile and too poorly understood to change safely.

The best time to establish architectural governance in your cloud program was before you started. The second best time is today.

What to Do Now

The solution is not complicated and not expensive relative to the alternative. It requires one thing most Canadian cloud programs do not have: an architect responsible for how the systems work, not just how the infrastructure is configured.

Commission an honest architectural assessment of your current environment - not a security audit, not a cost review, but a map of how your systems actually connect, where the data flows, and where the gaps are. Separate infrastructure engineering from solution architecture. Establish a lightweight architecture review process for significant technical decisions. Document the integration layer now, while the people who built it are still present.

And ask the question the packaging company never asked: how will we know if this is working?

That question does not require a different cloud platform. It does not require a different vendor. It requires a different role with a different mandate - someone whose job is to ensure that the environment you are building is coherent, verifiable, and trustworthy.

The organizations that ask that question now will not need to answer a much more expensive one in five years.