Cloud Migration Is Not Modernization

I keep seeing programs celebrate “we are on AWS / Azure / Alibaba” while the way people work with data barely changed. Landing a VM or a dump into the cloud is not modernization.

Context: By late 2023 a lot of enterprises had finished their first migration wave. In the rooms I sat in, go-live of the landing zone was treated as the finish line. Batch pipelines stayed nightly because “that is what we always did”. Access still went through tickets. Nobody owned the tables. Cost still belonged only to finance.

This post is about that gap - what I saw when lift-and-shift was sold as modernization, and what actually had to change for analytics and ML to work later.

Lift-and-shift vs. what I mean by modernization

Sketch from notes I kept after too many “we are on cloud” steering slides.

Lift-and-shift usually means: same schemas, same jobs, new host. A legacy export lands in a warehouse as a raw dump. Shared admin accounts remain. You discover the bill at month end.

Modernization, when it actually happened, looked different:

• Tables designed around how people query them, not how the source system stored them
• Landing -> curated -> serving layers, with someone responsible for each
• Schedule matched to when the business needs the number, not to an old cron habit
• Least-privilege service accounts
• Cost and retention treated as design choices, not finance surprises

Teams that only moved hosts often had the same pain as before: slow delivery, opaque pipelines, rising cloud bills, and no clean base for reporting or ML.

Five signs the migration landed but nothing really changed

1. The “data lake” is still a file dump.
Parquet in object storage without partitioning, compaction, or serving tables is storage with extra steps. It is not a platform.

2. Only one person understands the nightly chain.
If nobody can draw the path from source to dashboard, you have operational debt. Green jobs in an orchestrator do not fix that.

3. Definitions live in people’s heads.
“Active customer” means one thing in finance and another in marketing. Cloud does not fix that. Without owners and written definitions, every team rebuilds the same logic.

4. Security is still perimeter thinking.
VPN plus broad DB roles made some sense on-prem. In cloud, the same broad roles become a much bigger blast radius.

5. FinOps is a monthly meeting.
Partitioning, materialization, how often jobs run, how long you keep data - those are architecture decisions. Treating cost as a post-hoc finance topic almost always ends in overspend.

What actually changed when modernization worked

Architecture. Explicit layers: landing for raw ingest, curated for cleaned entities, serving for how people query. Design for access patterns, not for “copy the source table”.

A tiny, illustrative example of the serving-layer idea - not a full migration blueprint:

-- serving table shaped for the dashboard filter pattern (date + account)
CREATE TABLE serving.account_daily_kpis
PARTITION BY event_date
CLUSTER BY account_id AS
SELECT
  account_id,
  DATE(event_ts) AS event_date,
  COUNT(*) AS events,
  SUM(IF(event_type = 'purchase', amount, 0)) AS revenue
FROM curated.events
WHERE event_ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
GROUP BY 1, 2;

Operating model. Named business and technical owners. Freshness and quality expectations that someone can be held to. Pipeline failures visible to the people who can fix them.

Engineering habits. Infrastructure as code, some CI on SQL and DAGs, runbooks, SLOs on the critical paths - the same seriousness you would expect from a product service.

Decommissioning. Modernization includes turning old paths off. Running legacy and cloud platforms side by side forever doubles cost and destroys trust in the numbers.

A sequence that kept working when programs recovered

Weeks 1-6 - make the truth visible. Inventory sources, pipelines, consumers, owners. Measure real query patterns and runtimes. Baseline cost by domain.

Weeks 7-14 - stabilize the path to value. Publish serving tables for the top business questions. Add freshness metadata. Fix the worst quality and reconciliation gaps.

Weeks 15-24 - retire the old behavior. Cut duplicate pipelines. Tighten IAM. Set retention. Decommission one legacy domain at a time with signed parity checks.

This principle held across managed warehouses, lakehouses, and mixed platforms. The cloud product was never the modernization. The operating model was.

Why I care about this before ML and analytics scale

Even in 2023, every serious analytics or ML plan assumed trusted, reasonably fresh inputs. A lift-and-shift warehouse rarely gives you that. Teams then bolt more tooling on top of a shaky base and wonder why numbers disagree.

Get the platform operating model right first. Everything you add later - dashboards, scoring jobs, copilots - will amplify what is already there.

From the leadership seat

Questions I kept asking when someone said “migration is complete”:

1. Can we name owners for the top datasets finance and product rely on?
2. Is decommission scheduled, or are we paying for two platforms indefinitely?
3. Do we have parity evidence, or only infrastructure checklists?
4. Can we attribute cost by domain, or is it one opaque bill?
5. Can a new engineer change a pipeline safely without calling the hero on Slack?

If three or more answers were no, we were not done - landing zone or not.

What worked when talking upward was not “we need more time for technical debt”. It was something like: we are live on cloud infrastructure, but not yet on a cloud operating model; here is a 90-day path, and here are the risks if we skip it.

Closing

Cloud migration answers where things run. Modernization answers how data is layered, owned, operated, secured, and paid for.

When a program was “done” but delivery was still slow, costs opaque, and definitions still argued in meetings - we had changed the invoice address, not the platform.