This piece is for leaders who have run, or are about to run, a migration and want a clear-eyed view of what lift-and-shift does and does not solve for data workloads. You will get a breakdown of why rehosting alone tends to stall analytics and inflate costs over time, a comparison of the three realistic modernization paths, a look at what a modern AWS data platform looks like layer by layer, and a sequencing model for getting there without freezing reporting for two quarters.
Lift-and-shift, or rehosting, moves a workload onto new infrastructure with the same architecture, schemas, and operational habits. For stateless applications, this is often reasonable. For data platforms, it tends to preserve exactly the problems a modernization program was meant to fix.
A rehosted warehouse or Hadoop cluster keeps its original access patterns: full-table scans, static partitioning, always-on clusters sized for peak load. Cloud infrastructure prices that pattern more precisely than on-prem ever did, so inefficiency that used to be buried in a fixed capital budget now shows up monthly, itemized, and growing. Storage follows the same path: data lands on general-purpose storage with no tiering strategy, so cold data accumulates on the most expensive tier by default rather than by decision. This is not a marginal effect: Flexera's 2026 State of the Cloud Report found wasted cloud spend climbed to 29% of budgets, the first increase in five years, with unoptimized migrations and AI-adjacent workloads named as drivers.
Most legacy data estates share a failure mode: a catalog that lags what exists, permissions granted ad hoc and never revisited, and datasets nobody can confidently say are still in use. Rehosting moves that debt intact. Nothing about copying a metastore or a set of flat files into cloud storage forces a decision about ownership, retention, or access control. Six months after a "successful" migration, the same team is fielding the same question: who owns this table, and can it be deleted. Gartner predicts that 80% of data and analytics governance initiatives will fail by 2027, pointing to exactly this pattern: governance work that gets deferred until a crisis forces it, rather than built into the platform from the start.
On-prem platforms are often built around assumptions that don't hold in the cloud: colocated compute and storage, synchronous batch windows, unmetered network paths. A rehosted platform that separates compute from storage without redesigning for it can introduce latency and cross-AZ transfer costs that never existed before, particularly for high-fan-out ETL jobs reading the same dataset from many workers at once.
The most common outcome of a data lift-and-shift is that the migration becomes the finish line. Dashboards keep working, which reads as success, but the underlying data still has no schema enforcement, no table-level access control, and no metadata a machine learning workflow or an AI agent could safely consume. A governed data platform on AWS is what enables that next layer of use, and rehosting alone does not produce one.
None of this makes lift-and-shift the wrong call. It is often right under a data center exit deadline or a hardware refresh nobody wants to fund again. The problem is treating it as the modernization, rather than one path among three with very different consequences for data.
Every modernization program eventually chooses, explicitly or by default, one of three paths per workload. They are not mutually exclusive across an estate: most organizations run all three in parallel against different systems.
Rehosting lifts a database or file system onto equivalent cloud infrastructure with minimal change to schema, format, or access pattern. It is fast and low-risk short-term, and the right call for workloads nearing end of life, low-value archival systems, or anything on a hard exit deadline. The data-specific cost: format and partitioning stay as inefficient as they were, permissions migrate as-is including any accumulated drift, and the workload gains none of the catalog or governance benefits of the target environment until a second project revisits it.
Replatforming moves a workload to a managed cloud-native equivalent, such as a self-managed Hadoop cluster to Amazon EMR or an on-prem warehouse to Amazon Redshift, while keeping the overall data model largely intact. This buys real operational relief, no more patching clusters, managed scaling, native cloud integration, without a full data model redesign. The catch is that replatforming often ports the source system's partitioning and table design by default, since that is the fastest path to parity. Cataloging and fine-grained access control have to be added deliberately.
Redesign restructures the data model: reorganizing storage into zoned layers, adopting an open table format, rebuilding the catalog, and rethinking access control from first principles rather than migrating existing grants. This is the path that produces a platform capable of supporting both traditional BI and newer consumption patterns like retrieval-augmented generation, because the metadata and access control those use cases need has to exist from the start. Redesign carries the highest upfront cost and the longest timeline to a first working dataset, and it tends to be the only path that avoids paying for the same rework twice.
Figures below reflect ranges observed across data platform modernization engagements rather than a single project; actual numbers vary with data volume, source complexity, and regulatory scope.
| Dimension | Rehost | Replatform | Redesign |
|---|---|---|---|
| Time to first governed dataset (cataloged, access-controlled, query-ready) | 4 to 6 months, often never without a follow-on project | 6 to 10 weeks | 10 to 16 weeks |
| Assumed engineering capacity | 2 to 3 FTEs, mostly infrastructure-focused | 4 to 6 FTEs, mixed infrastructure and data engineering | 6 to 10 FTEs, including governance and platform roles |
| Rework cost when zone, format, or permission decisions get unwound later | 30% to 45% of original migration effort, spent again within 12 to 18 months | 15% to 25% of original effort, usually in catalog and permission cleanup | Under 10%, since zoning and permissions are decided once, up front |
Rehosting looks fastest on a project timeline and is frequently the most expensive path once rework is counted, because the decisions it defers (format, zoning, permissions) get made eventually, just later, under worse conditions, against production data that is harder to touch safely by then.
Whatever path gets a workload onto AWS, the target state that supports both analytics and AI consumption tends to converge on the same four layers.
Amazon S3 remains the storage layer, but the meaningful decision is what sits on top of it. Amazon S3 Tables provide S3 storage purpose-built for tabular data with native Apache Iceberg support, handling compaction, snapshot management, and file-size optimization automatically rather than as a separate maintenance job.
Iceberg's open specification means the same tables are readable from Spark, Athena, Redshift, and third-party engines without a proprietary lock-in point, which matters once an estate has more than one query engine, which most do within a year of going live.
The AWS Glue Data Catalog holds table definitions and schema across the estate, and AWS Lake Formation layers fine-grained, database, table, column, and row-level permissions on top of it, enforced consistently across engines. A rehosted platform almost never has this layer, because retrofitting access control onto data people are already querying is a harder change to land than building it in from the start.
Amazon EMR and Spark cover large-scale batch transformation, Amazon Athena and Amazon Redshift cover interactive and structured query workloads, and Amazon Managed Service for Apache Flink handles continuous, low-latency stream processing where batch windows are too slow, for example, fraud signals or operational telemetry that needs action in seconds rather than hours. All three read and write against the same cataloged tables, which is what keeps a streaming pipeline and a nightly batch job from silently producing two versions of the same metric.
This is where production AI agents built for real operations either have something to read or do not. Retrieval-augmented applications, agents, and BI tools all need the same thing from this layer: a query interface backed by a catalog that knows what a table contains, who can see it, and how fresh it is. A multi-agent platform built on a modernized data foundation shows what this looks like once agents pull from governed tables rather than ad hoc exports, with permission and freshness guarantees built into the platform instead of bolted onto individual queries.
03
The architecture above is achievable on paper by most competent data engineering teams. What determines whether it ships on a reasonable timeline is the delivery engine behind it: who owns which decisions, what gets automated, and how often governance gets revisited rather than set once and forgotten.
The workloads most often stalled in modernization are ones where platform engineers own the target architecture, but no one understands why the source data was shaped the way it was. A workable model pairs a small platform team, responsible for target zones, catalog, and access model, with domain engineers who know the source data well enough to flag when a "straightforward" migration is hiding a business rule inside a stored procedure. An application and database modernization effort running in parallel on the transactional side benefits from the same pairing, since upstream schema changes affect what the data platform team can safely assume downstream.
Manual data discovery, profiling every source table by hand and tracing lineage through spreadsheets, is where modernization timelines quietly lose months. Automated discovery tooling that profiles schemas, samples data, and maps dependencies compresses that phase from a multi-month exercise into weeks, and produces the input that zoning and catalog design depend on. An operational data lake rebuild that cut queue wait time by 75% illustrates the payoff: the throughput gains came from redesigned partitioning and scheduling, decisions only possible because discovery produced an accurate picture of actual usage rather than assumed usage.
Zone boundaries, table ownership, and access grants drift the moment they stop being reviewed. A quarterly cadence that revisits who owns each zone, which datasets are still active, and whether grants still match current team structure catches drift while it is cheap to fix.
The alternative, an annual audit or none at all, means the same catalog-lag and stale-ownership problems that plagued the legacy environment reappear in the new one, just with better tooling to see them in.
Modernization work run as an open-ended backlog tends to stall once the initial migration ships and the visible win has already landed. Structuring the program around discrete phases, each with a defined exit a leader can sign off on, keeps zoning, cataloging, and permission work from being deprioritized indefinitely in favor of the next feature request.
This is the same reasoning behind running discovery, design, build, test, and deploy as signed phases rather than an open-ended engagement: a named exit at each stage is what keeps governance decisions from sliding to "later."
04
A representative modernized setup for a mid-size data estate: raw data lands in S3 under a raw zone, gets validated into a curated zone stored as S3 Tables in Iceberg format, and is cataloged in Glue with Lake Formation permissions at the database and table level. Athena and Redshift Spectrum serve BI queries against the curated zone. EMR handles heavier batch transformation into a consumption zone, while Managed Service for Apache Flink processes anything where minutes of latency, not hours, matter. Retrieval-augmented and agentic applications query the consumption zone through the same Lake Formation boundary as every other consumer, rather than through a separate export pipeline that quietly becomes its own unmanaged copy of the data.
A few decisions here carry outsized cost consequences relative to the effort to get them right.
The practical risk in modernization is rarely technical difficulty. It is the fear that touching a production pipeline breaks something nobody can afford to have break, which leads teams to defer hard decisions indefinitely.
A sequencing approach that avoids both the stall and the big-bang risk generally follows four phases: discover and profile the full source estate before touching anything, stand up target zones and catalog against a small, low-risk dataset first to validate the pattern, migrate remaining workloads in waves grouped by shared source system or shared downstream consumer rather than by convenience, and decommission the source system only after the equivalent governed dataset has run in parallel long enough to build confidence.
Running old and new in parallel for a defined window, rather than cutting over in one step, is what keeps analytics functioning throughout instead of going dark during the migration.