The Horseless Carriage Problem: Why Financial Services Is Still Calling the Cloud 'Digital Transformation'

The difference between workload relocation and workload transformation? One simply moves your infrastructure. The other reimagines what's possible. Financial services have a huge opportunity with cloud-native architecture, especially for market data infrastructure. Let's explore what is possible when you design from scratch instead of lift and shifting legacy workloads? 

In the early 1900s, automobiles were revolutionary. They were faster, more reliable, and more economical than horses. Yet for years, people called them “horseless carriages”. The name itself betrayed the inability to see beyond what they were replacing. Some call that the comfort zone. 

They couldn't conceive of the automobile as its own category, only as a carriage without the inconvenient horse. It took years before society simply called them "cars" and reimagined transportation entirely. Financial services is having its horseless carriage moment right now, and the vehicle in question is the cloud. 

When New Technology Gets Old Names 

When an industry talks about "digital transformation," it often signals thinking that’s still rooted in the old world. The focus becomes translation rather than transformation—taking on-premises infrastructure, legacy workflows, and decades-old architecture, and adapting them to work in the cloud.  

This is the 2025 equivalent of calling a car a horseless carriage. 

Real transformation doesn't rename the old thing. It builds something fundamentally different. Amazon didn't create "bookstores without buildings." Netflix didn't create "Blockbuster without late fees." They reimagined the entire model from first principles. 

The Lift-and-Shift Trap 

Many financial institutions approach cloud relocation the same way early drivers approached automobiles; they bring all their old assumptions with them. The technical term is "lift and shift": take your existing applications and infrastructure, move them to cloud servers, and call it innovation. 

The result? Cloud deployments that cost more than on-premises infrastructure, deliver minimal new capabilities, and leave executives wondering why they bothered. According to Flexera's 2025 State of the Cloud Report, 84% of enterprises cite managing cloud spend as their top challenge, with many finding costs exceeding initial projections. C-Level executives asked for more cloud and now they have it, for better or worse. 

This isn't a cloud problem. It's a horseless carriage problem. You're trying to feed hay to a BYD. 

How Other Industries Made the Leap 

Compare financial services with retail, media, or technology companies. These industries didn't "digitally transform"; they rebuilt. 

Netflix's Journey: Netflix started by mailing DVDs (disrupting Blockbuster), then moved to streaming (disrupting cable), and then created original content (disrupting Hollywood). At each stage, they asked, "What can we do now that we couldn't do before?" not "How do we do the old thing in a new place?" 

They built cloud-native infrastructure that scales globally, delivers content in milliseconds, and optimizes costs dynamically. They didn't lift and shift their DVD warehouse operations to AWS. 

Uber's Approach: Uber didn't create "taxis with an app." They reimagined urban transportation from scratch. Dynamic pricing, algorithmic matching, cashless payments, and driver-partner models. None of this was possible in the taxi framework. They had to think beyond "horseless carriages" to create something genuinely new. 

Airbnb's Model: Hotels didn't become Airbnb by "digitally transforming" their booking systems. Airbnb succeeded by asking entirely different questions: What if anyone could be a host? What if trust could be built through reviews rather than brand names? What if hospitality wasn't about standardization? 

Cloud Relocation as a Business Model vs. an IT Project  

The challenge many financial institutions face is treating cloud relocation as an IT project when it could be a business model question. The focus naturally gravitates toward where the servers are, rather than what becomes possible when infrastructure is fundamentally different. 

Cloud-native architecture isn't about virtual machines in someone else's data center. It's about: 

• Elastic scaling: Resources that grow and shrink with demand, not fixed capacity 

• Serverless computing: Paying for execution time, not idle servers 

• API-first design: Systems that integrate easily, not monolithic applications 

• Event-driven processing: Real-time responsiveness, not batch-and-queue 

• Microservices: Small, independent components, not tightly coupled systems 

When you lift and shift, you get none of these benefits. You get your old infrastructure in a more expensive location. 

The Market Data Parallel 

Market data infrastructure faces the exact same problem. Firms are trying to take their outdated terminals, their on-premises data feeds, their legacy integration patterns, and make them work in "modern" environments. 

They're still thinking about market data in terms of bundled technology and data, vendor-specific tools, and infrastructure designed around a specific provider's ecosystem. 

What if instead we asked: What does market data infrastructure look like if we designed it today, from scratch, for a cloud-native, AI-driven, multi-vendor world? 

The answer wouldn't look anything like a terminal. It would be neutral infrastructure that: 

• Treats data providers as interchangeable sources 

• Supports real-time and historical data equally 

• Enables AI workflows natively 

• Costs what it actually costs to run, not what vendor lock-in allows someone to charge 

FAQs 

Q: How long does it typically take to transition from lift-and-shift to cloud-native architecture? 

A: The timeline varies by organization size and complexity, but most transitions happen in phases over 12-24 months. The key is starting with one workload or use case, proving the model, then expanding systematically. 

Q: Can legacy systems coexist with cloud-native infrastructure during the transition? 

A: Absolutely. A hybrid approach is common and often necessary. The goal is to build new capabilities cloud-native while gradually relocating legacy systems through APIs and microservices that bridge both worlds. 

Q: What's the ROI difference between lift-and-shift and true cloud-native architecture? 

A: Cloud-native typically delivers significantly lower operational costs and faster deployment cycles compared to lift-and-shift. The bigger gains come from new capabilities: real-time analytics, AI integration, and elastic scaling that weren't economically viable before.