Summary: Idle and underused compute accounts for roughly 10 to 15% of typical enterprise cloud spend, according to the FinOps Foundation's State of FinOps research, and legacy pipelines that tangle orchestration with execution are a direct cause. Tatrento´s DataVolve addresses this specific failure mode during migration by profiling legacy packages, separating control flow (state, waiting, sequencing) from data flow (joins, transforms, calculations), and routing each to the layer built to run it, before any target code is generated.
In brief: Legacy data platforms were built for physical servers, where a single script handling both a wait loop and a data transformation cost nothing extra, since the hardware was a fixed cost whether it was busy or idle. Cloud compute bills by active time instead, so that same coupling now means an expensive parallel-processing engine sits active and billing while it waits for a file to arrive or a dependency to clear. Checkout.com hit exactly this pattern in 2026 and cut monthly data platform costs by about 30% once it stopped paying for peak-provisioned capacity around the clock. DataVolve's migration approach exists to prevent that pattern from crossing into the new architecture in the first place.
In This Article:
- What execution and orchestration actually do, and why legacy systems fused them
- The specific cost mechanism that lift-and-shift migrations trigger
- A real 2026 case of this exact waste pattern, and what fixing it saved
- How DataVolve separates the two layers before generating target code
- What FinOps research confirms about where this waste actually comes from
- What decoupling buys beyond cost: recovery, maintenance, consolidation
What execution and orchestration actually do, and why legacy systems fused them
Execution and orchestration solve different problems in a data pipeline, and building them as one thing instead of two is what turns a routine cloud migration into a recurring cost problem.
Execution does the computational work: joining tables, transforming datasets, running the calculation logic itself. Orchestration manages state: deciding when a job runs, checking whether a file has arrived, triggering the next step in sequence. Astronomer, the company behind managed Apache Airflow, documents this exact split in its own architecture as two separate planes, an orchestration plane that schedules and tracks state, and an execution plane that runs the actual workload. That is not a DataVolve-specific idea. It is how the wider data engineering industry has already concluded these systems should be built.
| Execution | Orchestration | |
|---|---|---|
| Job | Runs the computation: joins, transforms, aggregations | Manages state: schedules, dependency checks, sequencing |
| Ideal platform | Parallel cloud compute engine (cloud data warehouse, Spark cluster) | Lightweight orchestration framework (Airflow, ADF, Step Functions) |
| Cost behavior when separated | Bills only while actively processing data | Runs on minimal, low-cost compute |
| Cost behavior when coupled | Sits active and billing while waiting on a dependency | No independent layer to isolate; state logic is buried inside the same script |
| Failure behavior when coupled | A single failure can force a full rerun of the entire job | No way to isolate or restart at the point of failure |
Enterprise data environments accumulate this coupling gradually rather than by deliberate design. In legacy environments, monolithic on-premise stored procedures typically fuse both layers into a single script, with a wait loop sitting directly beside a data transformation query and no boundary between them. That design made sense on physical servers, which required strict sequential processing and cost the same whether they were computing or idling. Moving that structure directly into a modern cloud environment carries a hardware-era assumption into a billing model it was never built for.
The specific cost mechanism that lift-and-shift migrations trigger
Lifting and shifting a coupled architecture into the cloud does not just carry over old inefficiencies. It actively converts them into a continuous financial drain, because the billing model underneath has changed even though the code has not.
| Legacy on-premise hardware | Cloud compute engine | |
|---|---|---|
| Cost model | Fixed cost, paid regardless of activity | Billed on active time |
| Design assumption | Strict sequential processing on dedicated servers | Spin up, process in parallel, finish, shut down |
| Cost of a wait loop | Effectively zero; the hardware was idle anyway | Continuous billing for every second the cluster stays active |
| Cost of a mid-job failure | Rerun the script; hardware cost unchanged | Rerun the entire expensive parallel job from the start |
Migrate legacy code without separating orchestration from execution, and a script that pauses to wait for a dependency keeps a premium cloud cluster active and billing for every second of that pause. Push the coupling further, and a monolithic package that fails deep into a processing sequence leaves no independent orchestration layer to fall back on. Engineers either untangle the state by hand or rerun the entire expensive job from the start.
A real 2026 case of this exact waste pattern, and what fixing it saved
This is not a theoretical risk. Checkout.com, a global payments company, ran into this exact cost mechanism on its own Airflow-based data platform and published the fix in July 2026.
The company had been provisioning its self-managed Airflow environment for peak worker demand and paying for that capacity continuously, regardless of actual workload, the same structural problem a tangled legacy script creates on a smaller scale. Moving to Google Cloud's Managed Service for Apache Airflow, which scales workers dynamically instead of holding fixed peak capacity, cut Checkout.com's monthly data platform costs by about 30%, according to the company. Separately, the migration also isolated individual pipeline failures so one problematic workflow could no longer disrupt the rest of the environment, and cut the time between deployment and pipeline execution from around six minutes to near-instant.
Checkout.com's fix operated one layer up from what a DataVolve migration addresses (it changed who manages the orchestration infrastructure, not how orchestration and execution logic are separated inside individual pipelines), but the underlying waste mechanism, paying for compute continuously instead of only when it is doing useful work, is identical.
How DataVolve separates the two layers before generating target code
DataVolve's approach is structural rather than cosmetic. It deconstructs legacy pipelines during migration, before any target code exists, so coupling has no path to reproduce itself in the new environment.
Before generating a single line of target code, DataVolve profiles the existing environment to map exactly where state-management logic and data-transformation logic intersect inside each legacy package, then separates the two programmatically. Schedules, conditional branching, wait loops, and error handling are identified and isolated as one category, completely apart from the SQL calculations that make up the other. That separation gives migration teams visibility beyond a basic inventory of jobs and tables: it shows how control logic and computation actually depend on each other today, before either one gets rebuilt.
Why the separation matters for cloud modernization
Separating control flow from data flow means each half lands on the platform actually built to run it, instead of both competing for the same expensive compute engine.
DataVolve extracts the control logic and maps it into modern orchestration frameworks. The data-transformation logic, stripped of the routing constraints it used to carry, is compiled into target-native cloud queries and assigned to the execution engine on its own, so compute is designed to activate only once data is actually ready to be transformed rather than sitting active during upstream waits. That separation also makes it practical to consolidate workflows performing similar functions and to review legacy processes against what the business needs today, instead of preserving logic nobody has re-examined in a decade.
What FinOps research confirms about where this waste actually comes from
Independent cost research backs the mechanism directly, and two separate methodologies land in a comparable range.
| Source | Finding | What it shows |
|---|---|---|
| FinOps Foundation, State of FinOps | Organizations early in cost-management maturity see waste approaching 30% of total cloud spend | Idle and underused resources are a leading, named waste category, not a rounding error |
| FinOps Foundation, State of FinOps | Idle and underused resources account for roughly 10 to 15% of total cloud spend on their own | Compute left running while waiting is a distinct, measurable line item |
| Flexera, State of the Cloud Report | Total cloud waste sits at 30 to 35% globally | An independently run survey arrives at a comparable range to the FinOps Foundation |
| Checkout.com, published July 2026 | Ending fixed peak provisioning cut monthly data platform costs by about 30% | A single named company's actual result, not an industry average |
None of these sources frame the problem in orchestration-versus-execution terms specifically, but the waste category they describe, compute that is active without being productive, is exactly what a coupled legacy script produces the moment it moves to a billed-by-the-second engine.
What decoupling buys beyond cost: recovery, maintenance, consolidation
Beyond the direct cost argument, a decoupled architecture changes how failure gets handled, and that difference compounds every time something breaks in production.
Because the orchestrator manages state independently of the execution layer, a failure inside a specific data-transformation node stops that node alone. A data engineering team can fix the specific query at fault and restart the workflow from the point of failure, instead of rerunning an entire multi-hour job to recover from one bad transformation. The same independence simplifies maintenance: engineers can update business logic inside the execution layer without risking the scheduling and dependency rules that live in orchestration, because the two were never written into the same file to begin with.
Where to start
A cloud migration is the point where legacy architectural assumptions either get carried forward unexamined or get replaced deliberately, and which one happens is a design choice, not an automatic outcome of moving infrastructure.
Explicitly isolating how a pipeline runs from what it calculates is what lets organizations arrive at the cloud without importing constraints that made sense on physical servers and nowhere else.
DataVolve is built around this separation from the discovery phase onward. If a migration plan still treats orchestration and execution as one problem, a DataVolve discovery assessment is the fastest way to find out what that coupling is actually costing.
