I get some version of this question at least once a quarter, usually from a CIO who just sat through a brutal renewal negotiation or is frustrated by the cost of an upgrade: "Was moving to the cloud a mistake?" The honest answer is that most of the people asking it aren't actually asking about the cloud. They're asking about something else entirely, and until they separate the two, they're going to keep making the same expensive decision over and over.
The Cloud Is a Landlord, Not a Product
Let's start with what "moving to the cloud" actually means, because the term has been stretched past usefulness. At its core, it's moving your workloads into data centers that aren't yours, typically a hyperscaler's. You're renting infrastructure: compute, storage, networking, physical security, and a deeper bench of specialized expertise than almost any single enterprise IT shop can staff internally. That's a legitimate, often excellent, trade. You stop being in the business of running data centers and get back to being in the business of running your business.
What people confuse that with is something else: moving to a SaaS or "cloud" product that is still operated like an on-premise system. SAP's RISE is the clearest example in the ERP world, and it's not the only one; UKG and several other major platforms have versions of the same pattern. RISE runs your S/4HANA instance in a private cloud environment, but it's still fundamentally the same application, with an implementation project, an application layer you still manage, and upgrade windows that follow the vendor's cadence rather than a true multi-tenant SaaS release train. You've changed who racks the servers. You haven't changed how the software behaves, and you're still responsible for keeping it current.
The Real Problem Isn't the Move, It's What Happens After
Organizations spend extraordinary sums implementing powerful systems and then barely touch them (on the IT side). I've walked into environments running platforms a decade or more out of date: unpatched, un-upgraded, configured for a business that no longer exists. Gartner's data backs up how common this is: 83% of data migration projects either fail outright or blow their budget and timeline, and the number one cause isn't the cloud vendor; it's the complexity of the legacy environment being dragged along for the ride.
Cloud and SaaS products don't tolerate that neglect the way an on-premise box quietly does. They require you to keep up with patches. They require you to upgrade on a regular cycle, which means your business processes have to evolve and accommodate that cadence. Too many organizations treat this as an inconvenience, or worse, as an imposition being forced on them by the vendor. It isn't. It's the job now. And it was always supposed to be the job; the cloud just removed the option of pretending otherwise.
Standardize or Keep Paying for It
The fix isn't complicated to describe, even though it's hard to execute: organizations need to ruthlessly question how much of their custom code is actually earning its keep. Is this rule, this policy, this workflow actually a differentiator in the market? Or is it just friction you're choosing to carry forward because changing it feels harder than not changing it? Every non-standard configuration you keep is a recurring tax you pay at every future upgrade. Standardize where you're not actually differentiated, and you dramatically shrink what you have to re-fight every cycle.
This is exactly what's playing out right now with SAP's "Clean Core" mandate for cloud ERP. SAP is telling customers, correctly, that heavily customized code is what makes upgrades slow, risky, and expensive, so the public cloud version increasingly forces you to either rebuild that customization as a sanctioned extension or give it up entirely. I've talked to CIOs who treat this as an attack on years of "competitive differentiation." In the vast majority of cases I've actually looked at, it isn't. It's a decade of one-off exceptions nobody had the political capital to remove, now presented back to them as a bill. The organizations that will handle this transition well are the ones asking the standardization question I just described, years before the vendor forces the issue.
Why This Is More Urgent Than Ever
You might reasonably ask why any of this matters more in the age of AI than it did five years ago. It matters more, not less. Cyber-attacks are getting significantly more effective, and AI is a direct accelerant, not a side effect. Ransomware activity was up roughly 42 to 45% in the first half of 2026 alone, and by some industry estimates the large majority of active campaigns now use AI somewhere in the kill chain: from adaptive payload delivery to AI-assisted lateral movement once attackers are inside a network. The economics have shifted too: the underground price of initial access into a target network has dropped sharply as AI tooling makes reconnaissance and exploitation cheaper to automate. The fastest quarter of intrusions now reach data exfiltration in about 72 minutes, down from nearly five hours just a year prior. If you thought you were at risk before, that door has been kicked wide open, and it's swinging faster.
Patch cadence is not a compliance checkbox in this environment. A vulnerability that used to give a security team weeks to respond before it was weaponized now gives them hours. An organization running a decade-old, unpatched instance of a "modernized" cloud system isn't behind schedule; it's an open door with a welcome mat, and AI-assisted attackers are specifically built to find exactly that kind of target faster than a human ever could.
Layer on the quantum horizon and the picture gets worse before it gets better. NIST has finalized post-quantum cryptography standards and is already pushing deprecation timelines for RSA-2048 and ECC-256 well before 2035. The more pressing issue right now is "harvest now, decrypt later": nation-state actors are actively collecting encrypted traffic today, banking on the ability to decrypt it once quantum hardware matures. If your sensitive data has a long shelf life (financial records, IP, health data), it's already exposed to a threat that just hasn't arrived yet.
The Decision in Front of You
None of this is an argument against the cloud. It's an argument against outsourcing your infrastructure while keeping your discipline exactly where it was in 2010. You can try to lock down your network perimeter as hard as you like; modern, AI-assisted attack techniques will find a way in. Not if. When. The organizations in the best position aren't the ones with the newest infrastructure; they're the ones who treated the move to the cloud as the forcing function to finally modernize their security posture, standardize their configurations, and commit to a real patch and upgrade cadence instead of a decade-long grace period they gave themselves by accident.
If you're staring at a renewal, a RISE decision, or a security posture that hasn't meaningfully changed since your last major implementation, that's worth an actual conversation before the next budget cycle locks you in again. Reach out and let's talk through where your organization actually stands.
Comments
Post a Comment