Recently, I posted a poll on LinkedIn asking:
“Should spreadsheets in the enterprise default to being standalone or client-server, unless there’s an exceptional reason not to?”
I included a third response option—“I don’t know what you mean”—because, frankly, I expect it to be the most popular. And that’s the point.
There’s a fundamental misunderstanding in the industry, especially on platforms like LinkedIn, about what “cloud” means when we talk about spreadsheets. That confusion is holding back meaningful discussions about digital transformation in enterprise Excel. It was especially evident in a recent thread by Paul Barnhurst about VBA, where I had to jump in to clarify something that seems obvious once said: there are two completely different meanings of “cloud” in spreadsheet discussions.
Let’s unpack them.
1. Cloud as Shared File Access (Google Sheets Model)
This is the version of the cloud most people think of—what I call Cloud Type 1. It’s the evolution of the old departmental shared drive. In this model:
- A single spreadsheet file is stored in a cloud location like OneDrive or Google Drive.
- Multiple users can open and edit it—sometimes even simultaneously.
- It’s useful for making files accessible from anywhere and sharing them across teams or devices.
Most office users are familiar with this setup. It’s the modern equivalent of a shared network drive, and it works well for lightweight use cases—basic data entry, light calculations, or when you need quick collaboration.
This is not what we mean when we talk about digital transformation of enterprise Excel systems.
2. Cloud as Client-Server Architecture (Enterprise Model)
Cloud Type 2 refers to a totally different concept: client-server architecture, which revolutionized computing over 30 years ago.
- In this model, many independent spreadsheets (clients) perform different tasks.
- They all connect to a shared, centralized data source—usually a database.
- This setup allows complex, distributed business processes to scale efficiently and securely.
- The “cloud” part simply means the server (or database) happens to be hosted remotely, often via Azure or AWS.
This model powers robust systems like enterprise budgeting, forecasting, supply chain analytics, and more. You don’t share one spreadsheet among many people—you allow different spreadsheets (or apps) across departments to interact with the same core data. That’s what allows for scale, control, and governance.
Why It Matters
Many LinkedIn discussions conflate these two models. A recent example: a comment from Tejas Prakash suggested that “spreadsheets are moving to the cloud.” But what kind of cloud? Is he talking about more Google Sheets-type usage? Or does he mean a shift to client-server architecture hosted in the cloud?
From the context, I believe he means the former. But here’s the kicker: corporate Excel systems already use the cloud in the client-server sense. Whether the server is in your company’s data center or hosted on Azure, the architecture remains the same. The key point is that multiple, distinct spreadsheets feed from the same central data—not that users are collaborating on a single file.
Desktop vs Cloud: Does It Matter Where the Data Is?
Some argue that client-server spreadsheets should also “move to the cloud.” But again—what does that mean?
- The data in these systems may already be on the cloud.
- The spreadsheet logic (formulas, VBA, Power Query) lives on the user’s machine—the client.
- Moving that logic entirely into the cloud would require serious compromises in speed, complexity, and control.
In other words: client-server spreadsheets don’t need to be “cloud-based” in the browser sense. They’re already cloud-leveraged in the architectural sense. Putting more of their logic in the browser risks dumbing down the power of Excel just to fit a trend.
Tools Like Power Query, Python, Lambdas – Where Do They Fit?
In the context of client-server Excel, tools like Power Query, Python, Office Scripts, and Lambdas make sense as long as they support modular, distributed design. They should empower spreadsheets to pull in and process centralized data, not force all computation into the browser.
Trying to centralize or restrict these functions under the guise of “cloud migration” can be a step backward—especially if it hampers the spreadsheet’s ability to serve its unique function in a broader business process.
A Real Example: 400 Spreadsheets, One Process
In my annual budgeting demo, I showcase a real client-server model—400 independent spreadsheets working within the same process, driven by VBA, reading and writing to a centralized dataset. It works because each spreadsheet has a purpose, autonomy, and a defined interface with the core data.
When Tejas questioned whether this could work, I realized he hadn’t seen the architecture or grasped the model. He’s imagining the shared-file-on-Drive model, where that kind of complexity would indeed be impossible.
Conclusion: Don’t Confuse the Two Clouds
To conflate these two architectures—shared files vs client-server—is to confuse chalk with cheese. They serve different purposes, and mixing them up makes meaningful discussion impossible.
If you’re talking about spreadsheets moving to the cloud, ask: Which cloud?
Because if the answer is “I don’t know what you mean,” then we haven’t even begun the right conversation.
Add comment