Inside the Forge migration engine: ABAP-to-SQL conversion, Medallion layers, and automated reconciliation

There is a healthy scepticism that any good architect brings to the word "accelerator". A migration from SAP BW to Snowflake is, in the end, a data engineering problem — and a strong engineer with dbt, Snowflake and enough time can solve data engineering problems. So the question is not whether Forge can do the work. It is whether it does enough of the work, well enough, to justify itself over a bespoke build the team could run on its own.

The answer is specifics, not adjectives. Five tasks in a BW-to-Snowflake migration are fully automated by Forge, and those five account for the majority of the elapsed time in a manual programme. On the tasks that remain — the ones that genuinely need human judgement — Forge saves roughly 60% of the effort. Added together, that is 75–80% less manual work than building from scratch. This article walks through the four mechanisms that produce that number: the RFC profiler, the ABAP-to-SQL conversion framework, the Medallion build, and the reconciliation engine.

Automated BW object profiling: what the RFC scanner produces

Forge connects to the BW system over RFC and scans the full landscape automatically — InfoProviders, InfoObjects, DataSources, transformations and process chains. Crucially, it does not just list objects; it classifies each one as active, dormant or obsolete based on actual usage metadata and load history. That distinction matters, because the estate worth migrating is the estate that is genuinely in use, not the one the documentation claims exists.

The scanner catalogues every custom ABAP transformation rule, routine and function module, and it maps business-domain dependencies: which BEx queries, reports and downstream consumers depend on which BW objects. In benchmark runs it processes 973 tables in 75 minutes. The same inventory, produced by hand, takes a skilled BW team four to six weeks — and it is precisely this inventory that makes programme scoping, cost estimation and the phased roadmap credible rather than estimated. You cannot price a migration accurately against an estate nobody has mapped.

The ABAP-to-SQL conversion framework: automating the volume, surfacing the exceptions

Custom ABAP transformation logic is the most time-intensive element of any BW migration. It is frequently undocumented, and frequently written by people who no longer work at the organisation. Forge's conversion framework translates that logic into Snowflake-native SQL systematically — but the important design decision is what it does with the work it cannot fully automate.

The Observability Dashboard includes an ABAP Conversion Summary that assigns a confidence score to every converted routine: fully automated, partially automated with review flags, or manual review required. Standard patterns convert cleanly. Complex routines carrying significant business logic are flagged, with their confidence scores, so the delivery team knows exactly which objects need a specialist's attention — before the programme budget is committed, not in month nine when the fixed-price proposal becomes a change request.

Bronze, Silver, Gold: carrying data through all three Medallion layers

Forge does not stop at landing raw data in Snowflake. It carries the estate through all three layers of the Medallion architecture, and the division of labour between automation and client sign-off at each layer is what produces the headline time saving.

Bronze is approximately 60% fully automated; Silver adds around 20% with client review; Gold adds a further 20% with client business sign-off. Read together, that 60/20/20 split is the source of the 75–80% time saving versus a bespoke build — and notice that the human input it asks for is business knowledge and judgement, not engineering hours.

The reconciliation engine: formal validation at every milestone

Automation is only worth anything if it is verifiable, and this is where an accelerator either earns an architect's trust or loses it. Forge's reconciliation engine validates the Snowflake output against the BW source at three levels: row counts, aggregate checks on key figures, and sample-row comparisons. A formal approval gate sits before any go-live — nothing cuts over until it passes — and exportable PDF sign-off reports are generated at each milestone for internal records and audit.

Throughout the programme, the Forge Observability Dashboard reads live from Snowflake: tables loaded versus expected, total row counts, success rate, schema coverage, per-table data freshness in RAG colour coding, per-column null analysis, and the ABAP Conversion Summary. The Pipeline Run History keeps a complete audit trail of every run — a permanent operational reference the client team owns, not a black box they have to take on faith.

What the accelerator actually buys you

So, back to the architect's opening question. A skilled engineer with dbt and Snowflake can build all of this — given enough months. What Forge changes is not capability but time and certainty: the four-to-six-week inventory done in an afternoon, the ABAP volume converted with the exceptions flagged before budget is set, the three Medallion layers carried through on pre-built patterns, and every milestone validated against source with an exportable sign-off.

The engineer's expertise does not disappear — it is spent where it is worth most. On the 20–25% of the work that genuinely needs human judgement, rather than the 75–80% that does not. That is the whole argument for the accelerator, and it is an argument made entirely in specifics.