ETL Migration ROI: What a 100-Package Estate Really Costs to Migrate

1. Why budgets blow before cutover

The typical scenario looks like this: a 100-to-300-package SSIS estate, or its Talend, Informatica or DataStage equivalent, gets a migration budget set on a "roughly similar to last time" basis. Discovery is a two-week exercise. The estimate assumes every package is about as complex as the ones people remember. Then month eight arrives, and with it a transform nobody has touched since 2014 that encodes a pricing rule Finance still relies on.

The uncomfortable truth is that manual rewrites do not just overrun on cost. They overrun because the cost model itself is wrong: discovery is assumed rather than priced, productivity is overestimated, and the timeline creates costs of its own that were never in the spreadsheet. Fixing the model is the point of this post.

2. Why this matters now

The pressure to move is no longer optional. SSIS is frozen in feature terms. Talend Open Studio users face forced moves to commercial editions. Informatica PowerCenter customers are being pushed towards IICS with repricing attached. Meanwhile Databricks, Microsoft Fabric and Snowflake have become the default target platforms, and the migration path, not the platform, is the bottleneck.

Two things have made the status quo more expensive. UK data engineering salaries have risen sharply, so "just hire a team to rewrite it" costs more than it did three years ago. And CFO scrutiny has hardened: programmes that cannot show a payback period and a risk-adjusted ROI are being paused or cancelled. Finally, every year of delay is itself a line item: another year of dual maintenance, and another year of platform benefits you never collect.

3. Why the manual rewrite cost model breaks

"Manual rewrite" sounds precise but means something loose: engineers open each legacy package, read the logic, and hand-write PySpark, dbt or SQL to reproduce it. The model breaks in four predictable places:

• Discovery is assumed, not priced. Undocumented business logic surfaces in month 8, not month 1, and every surprise lands on the critical path.
• Consultancy day rates dominate the estimate. UK data engineering consultancy rates run at roughly £800–£1,200 per day. Internal loaded costs of £500–£700 per day look cheaper, but they pull engineers off live work, which has its own cost.
• Productivity is overestimated. The industry rule of thumb is one complex package per engineer every one to two weeks, when the logic is understood. When it is not, all bets are off.
• 12–18 month timelines create their own costs. Parallel running, dual maintenance and attrition do not appear on the initial quote, and they are large (see section 5).

To be fair: manual rewrite is sometimes the right answer. Very small estates, or estates where the logic is genuinely being redesigned rather than preserved, are sensible candidates. The problem is applying it by default to 100-plus-package estates where the logic must survive the move intact.

4. Worked cost comparison: a 100-package estate

The assumptions, stated explicitly: 100 packages of medium complexity, targeting Databricks, business logic preserved rather than redesigned, UK-based team.

On the middle column: ELT tools are excellent at ingestion, but they do not translate a 15-year-old package's business logic. That part is still manual engineering, which is why the "cheap tool" row carries a large hidden rebuild cost and lands in the same overall neighbourhood as a rewrite.

On the last column, the honest trade-off: AI-assisted translation still needs human review, and genuinely dead or badly written legacy logic sometimes needs a design decision. The saving comes from eliminating hand-transcription, not from removing humans. The figure a CFO should hold onto: manual rewrite for this estate typically lands north of £1m all-in, while an AI-assisted engagement for the same estate is a fraction of that, with payback inside the first year.

5. The hidden costs nobody budgets for

• Parallel running: legacy and new platforms run side by side for weeks or months to compare outputs, doubling infrastructure and ops attention.
• Dual maintenance: every business change during a 12–18 month rewrite must be made twice, in two technologies.
• Regression testing: without generated parity tests, teams write comparison scripts by hand; coverage is patchy, and auditors notice.
• Regulatory sign-off: finance, insurance and healthcare estates need evidence of correctness. "We eyeball-checked it" does not survive a regulator or an internal audit.
• Attrition risk: long migration programmes bleed engineers, and the knowledge leaves with them.
• Opportunity cost: the platform you are migrating to delivers value only after cutover; every month of delay is unrealised analytics value.
• The discovery iceberg: the estate always contains more logic than the documentation suggests, and programmes discover it at the worst moment.

6. Building the business case: payback and risk-adjusted ROI

Payback period is straightforward: total migration cost divided by the monthly benefit after cutover, where the benefit is licence savings, decommissioned legacy infrastructure, reclaimed engineering time and the new analytics capability the platform unlocks. A worked example for the 100-package estate: if the legacy estate costs £15k–£25k per month in licences, infrastructure and maintenance effort, and a £1m+ manual rewrite takes 15 months to cutover, payback can stretch past three years. A 6–10 week migration pulls payback inside 12 months. Speed-to-cutover is not a soft benefit; it is most of the financial case.

Risk-adjust the manual figure rather than just averaging it. Apply a probability-weighted overrun (large rewrites overrun; a 30–50% contingency is common and often still too small) and a probability-weighted attrition and quality allowance, because patchy regression coverage turns into production defects, which turn into rollback and rework. That produces a risk-adjusted manual cost of £1.3m–£2.2m for this estate, and that is the number the board should compare against a fixed-scope alternative.

One honest caveat: ROI depends on the estate actually being cut over. A migration that stalls at 80% delivers none of the benefit. Timeline risk is financial risk, which is exactly why speed-to-cutover belongs in the ROI model and not just the cost column.

7. The considerations that keep this honest

• Not every package should be translated 1:1. Genuinely dead logic should be retired, and the review step is where those decisions get made, package by package.
• Human-in-the-loop review is a feature, not a compromise: generated code is reviewed and signed off by engineers before it is trusted.
• Parity tests run on synthetic data, so no production data leaves the estate during validation, which matters in a regulated environment.
• Targets include Databricks (PySpark notebooks), dbt models and Microsoft Fabric notebooks; the same estate can be re-pointed if the platform strategy changes.
• Manual rewrite genuinely wins when the logic is being totally redesigned, or for estates of a handful of packages where translation overhead outweighs hand-writing.
• Migration does not de-risk itself: cutover plans, rollback plans and freeze windows remain your team's job, with evidence on the correctness side supplied by the parity suite.

8. The ROI summary

Manual rewrite of a 100-package estate: £750k–£1.8m+ upfront, 12–18 months, high overrun and attrition risk, often £1m+ even before hidden costs. Cloud ELT tooling: cheaper licences, but the business-logic rebuild keeps it in the same cost neighbourhood as manual. AI-assisted translation with human review: 6–10 weeks to production-ready code with generated parity tests, at a cost an order of magnitude below a manual rewrite for estates this size. The calculation that matters is risk-adjusted cost plus time-to-cutover plus evidence of correctness, not headline day rates.

Frequently asked questions