SAP Migrations

In 2025, enterprise teams are modernizing SAP analytics, reducing operational friction, and delivering governed, scalable data products—often with Snowflake or Databricks as the analytics destination. The challenge is not extracting data. Programs stall because teams cannot transform replicated SAP records into trusted, analytics-ready datasets at scale. The “last mile” work—reconciling financial numbers, handling time-dependent master data, standardizing currency logic, and operating pipelines that survive SAP change—often costs more time than ingestion itself.

A modern migration does not end when tables land in the cloud. It ends when business users can run governed analytics with performance and parity to what they had in SAP BW, SAP HANA, or SAP Analytics Cloud. Organizations that treat transformation and semantic modeling as an afterthought create rework, delays, and loss of trust.

Accelerate SAP Migrations Fast-track SAP migrations to modern platforms by translating years of complex, embedded business logic through AI-assisted automation.

A durable SAP program needs three fundamentals from day one:

• Clear scope tied to business value. Define systems, business domains, time horizons, and what “correct” means down to reconciliation tolerances.
• An architecture that separates ingestion from transformation. Replication handles change capture and movement. Transformation handles business logic, conformed dimensions, and governance.
• Repeatable operational practices. Testing, cutover, and change management must assume SAP schemas and business rules will evolve.

“Three out of four dollars of transaction revenue are flowing through an SAP system. That shows how important it is. If you want to integrate data related to those three out of four dollars, you need to integrate SAP.”

— Edwin, Lead Product Manager at Fivetran, via Powering SAP Data Ingestion and Transformations

This guide is for enterprise data engineers, data architects, and IT leaders evaluating SAP migration strategies. It covers SAP ECC, SAP BW, and SAP S/4HANA. It also compares target patterns for Snowflake and Databricks. In addition, it includes practical guidance for SAP data migration, SAP BW migration, and SAP migration best practices that reduce rework during close cycles and executive reporting.

Throughout, we reference accelerators and patterns for SAP transformations, including Coalesce—a data transformation platform that accelerates SAP-to-Snowflake migrations with pre-built accelerators from partners like Hakkoda. Coalesce emphasizes a compiled approach (efficient tables and views, rather than fragile views-on-views), governance without drag, and familiar BW-style modeling on Snowflake. For the broader portfolio of use cases, see the Coalesce solutions hub.

Scope: systems, domains, and success criteria

Before you choose platforms and services, define what success looks like. Otherwise, scope expands until timelines and budgets fail.

Most SAP programs start with a technical question: “How do we move SAP data?” However, a better starting point is operational: “Which outcomes must the new platform deliver, and for whom?” That question forces you to define business domains, critical metrics, and acceptance criteria up front.

An enterprise sap migration can mean several initiatives. Mixing them is a common root cause of scope creep.

Common targets include:

• Reporting modernization: replicate SAP data into Snowflake or Databricks and rebuild analytics outside SAP.
• Application modernization: execute an SAP S4 Hana migration (ECC → S/4 conversion), then modernize data consumption.
• Platform consolidation: reduce data warehouse sprawl by moving BW, HANA-native marts, and external data into one cloud platform.
• Data product delivery: publish governed, domain-owned datasets (Finance, Sales, and Supply Chain) for multiple consumers.

In addition, some programs are actually a SAP database migration (for example, AnyDB → HANA). That is a different effort than moving analytics workloads to Snowflake. Therefore, treat them as separate tracks unless you intentionally couple them.

After you define goals, build an inventory. Keep it honest, including customizations and “tribal knowledge.”

Inventory categories that matter for planning:

• Systems: SAP ECC, SAP BW, SAP S/4HANA, SAP HANA sidecars, APO, EWM, SuccessFactors, and Ariba
• Extraction interfaces: tables, extractors, CDS views, ODP sources, and SLT feeds
• BW assets: InfoObjects, DSOs and ADSOs, CompositeProviders, Open Hub outputs, and process chains
• Custom assets: Z tables, Z extractors, ABAP transformations, and customer exits
• Consumption: BusinessObjects, SAC models and dashboards, custom apps, and spreadsheets

This inventory is not busywork. Instead, it becomes your first estimate of transformation complexity, test scope, and parallel-run needs.

Many teams scope by SAP module or by table group. That usually ignores dependencies and creates churn.

A more resilient sequencing strategy is:

1. Master data first (when feasible): company codes, plants, materials, customers, vendors, chart of accounts, and cost centers.
2. Finance ledger backbone early: it anchors reconciliation expectations across every domain.
3. One end-to-end process next: for example, Order-to-Cash from sales order through billing and receivables.
4. Adjacent domains after that: Procurement, inventory, manufacturing, and HR—based on analytics demand.

This sequencing reduces reinvention. Conformed dimensions and shared logic (currency, fiscal calendar, and hierarchies) show up everywhere. If you postpone them, every downstream team re-implements them.

If your biggest pain is month-end close reporting latency, sequence like this:

• Core facts: BKPF and BSEG (ECC) or ACDOCA (S/4HANA Universal Journal)
• Master data: SKA1 and SKB1, CSKS, CEPC, T001, and T880
• Currency and calendar: TCURR, fiscal variants, and posting period controls
• Then: profitability, product costing, margin reporting, and allocations

If supply chain visibility is the priority, sequence like this:

• Material master and texts (MARA and MAKT), plants (T001W)
• Inventory movements (MATDOC in S/4HANA, MSEG and MKPF in ECC)
• Purchase orders (EKKO and EKPO), vendors (LFA1)
• Then: production orders, deliveries, quality, and batch genealogy

Strong sap data migration best practices turn correctness into measurable targets:

• Latency: near-real-time, hourly, daily, or close-cycle only
• History: 13 months, three years, seven years, or full retention
• Reconciliation tolerances: exact match vs defined rounding rules
• Security model: row-level security by company code, plant, and controlling area
• Performance SLAs: response time targets for top dashboards
• Auditability: lineage, change control evidence, and SOX requirements

If you do not define these early, the program becomes an endless debate between “technically loaded” and “business-ready.”

Because SAP touches finance and regulated reporting, governance and sign-off must be explicit.

Typical roles include:

• SAP Basis and SAP Security: authorizations, transports, and system stability
• Data Engineering: ingestion pipelines, orchestration, and reliability
• Data Architecture: target standards, domain boundaries, and conformance rules
• Business Data Owners: metric definitions and reconciliation sign-off
• InfoSec and Compliance: PII classification, masking, and retention policies

Document a RACI for source changes, schema drift, backfill approvals, and metric certification. Also agree on who can declare a domain “cut over.”

After scope, architecture is the next decision that is hard to undo. The next section translates scope into a target reference design that can handle SAP volume and semantics.

Choose a target architecture for SAP to Snowflake migration and when Databricks fits

After scope comes architecture. SAP is not just another source. SAP data includes compound keys, time-dependent master data, language-dependent texts, complex hierarchies, and delta behaviors that do not resemble common SaaS systems. Therefore, a generic ELT pattern often breaks under SAP volume or produces mismatched totals.

A proven pattern for SAP to Snowflake migration separates concerns into zones:

• Ingestion and landing: immutable extracts (files or transient staging) with load metadata preserved
• Raw: standardized types with minimal transformations, while keeping SAP keys and audit fields
• Curated: conformed dimensions, business logic, historization rules, and deduplication
• Consumption: semantic marts, aggregates, BI-friendly views, and certified datasets

This architecture supports coexistence because you can validate curated outputs while leaving BW and SAP reports intact. It also improves governance because you can restrict broad access to curated and consumption layers.

Plan explicitly for these SAP patterns:

• MANDT (client): multi-tenant separation inside the same SAP system
• Language fields: text tables keyed by SPRAS
• Time validity: master data with validity windows (explicit or implicit)
• Hierarchies: stored separately, often versioned and date-valid
• Reversals and clearing logic: especially in Finance and SD
• Huge facts: BSEG, ACDOCA, and MATDOC can reach billions of rows

Consequently, design with these implications in mind:

• Include MANDT in keys, partitions, and filters.
• Use “as-of” joins for time-dependent master data.
• Treat text joins as enrichment, not primary keys.
• Expect late-arriving facts and retroactive corrections.

Replication platforms move data and track change. However, they should not become your semantic layer.

A resilient SAP architecture assigns:

• Replication layer: extract, CDC and delta, load reliability, and basic normalization
• Transformation layer: modeling, conformance, currency, SCD and historization, and governance

This separation also reduces vendor lock-in. For example, you can switch ingestion approaches later without rewriting every downstream mart.

Snowflake is a common target because it supports governed SQL analytics with strong concurrency and low operations overhead. However, SAP workloads expose predictable pitfalls:

• Views-on-views sprawl: deep nesting increases compilation and runtime cost.
• Poor physical design for large facts: clustering and partition patterns matter for pruning.
• Unbounded transforms: scanning all history daily drives compute cost.

Best practices that help include:

• Incremental models for large facts (by posting date, document date, or load date).
• Materialize where query SLAs demand it (close dashboards and executive KPI packs).
• Use targeted clustering only when it consistently improves pruning.
• Isolate compute for ELT vs BI to avoid workload contention.

If you plan to migrate SAP data to Snowflake for financial reporting, prioritize predictable performance during close. “Fast on Tuesday afternoon” is not the SLA that matters.

Databricks can be a strong target when:

• You want open formats (Delta) and lakehouse patterns.
• You expect ML-heavy processing on raw SAP events.
• You need low-cost storage for very large history and occasional compute.

Snowflake often wins when:

• You need governed SQL analytics at scale with minimal platform operations.
• You need secure sharing and strong access control patterns.
• Your BI usage is broad and concurrency is high.

Many enterprises run both. In that case, keep curated modeling standards portable. Also avoid encoding business rules in platform-specific ingestion jobs.

Coexistence often lasts months, especially for Finance. Therefore, design for it.

Operational patterns that reduce chaos include:

• Keep BW running while you validate domain by domain.
• Publish “certified” datasets only after reconciliation sign-off.
• Track lineage from SAP objects to curated tables to BI metrics.
• Freeze KPI logic during close windows to prevent moving targets.

Design zones so you can reprocess curated models without re-extracting from SAP. That capability saves weeks during defects and backfills.

Next, define a defensible plan for ingesting SAP deltas, deletes, and correction behaviors.

SAP data migration and replication strategy tables vs extractors vs CDS and ODP

“The challenges of SAP data migrations are twofold. The first big challenge is getting the data out of SAP, where there’s a lot of SAP-specific complexity to navigate. The second challenge is rebuilding business logic that is hidden away in SAP in order to make the data useful.”

— Malte, Woodlott Partner, via SAP Migrations to Databricks Made Simple

Ingestion sounds straightforward until you face SAP deltas, deletes, and retroactive corrections. A strong SAP data migration plan defines what you extract (tables, extractors, CDS, and ODP) and how you represent change over time.

You can ingest SAP via multiple object types. Most enterprises use a mix.

Tables (direct replication)

• Pros: highest fidelity, broad coverage, and transparent
• Cons: limited business semantics, tricky deltas, and requires SAP table expertise

Extractors (BW-style)

• Pros: business-aware, mature delta mechanisms, and aligns to existing BW logic
• Cons: can hide complexity, may depend on BW configuration, and is often customized

CDS views and ODP sources

• Pros: modern semantic model, aligns with the S/4HANA Virtual Data Model
• Cons: versioning and transport impacts, performance varies, and still needs a delta strategy

A pragmatic rule: use the highest-level object that is stable, performant, and aligned with your acceptance criteria. Use tables when you need maximum control and transparency. Use CDS and ODP when SAP already encoded semantics you trust.

Teams often assume they can load incrementally with timestamps. However, many SAP tables do not provide a reliable updated_at. Therefore, delta strategy must be object-specific.

Define, for each object:

• Initial load approach: years of history without saturating source systems
• Delta mechanism: ODP delta queues, change pointers, extractor deltas, or log-based CDC
• Deletes: soft delete flags vs physical deletes, and how they propagate downstream
• Correction window: reprocessing strategy for backdated postings and updates

Do not assume every SAP table has a reliable updated timestamp. Many do not.

Practical delta examples:

• ACDOCA (S/4HANA): incremental by posting date plus a rolling correction window for late adjustments; optionally incorporate CDC if available.
• VBRK and VBRP (billing): incremental by billing date plus logic for cancellations and reversals; consequently, consider change documents when needed.
• Master data: periodic snapshots or change pointer-based deltas; then handle SCD downstream in curated models.

Expect big numbers. Plan capacity and partitioning for:

• Finance: BKPF and BSEG (ECC), ACDOCA (S/4HANA)
• SD: VBAK and VBAP, VBRK and VBRP
• MM and Inventory: MATDOC (S/4HANA), MKPF and MSEG (ECC)
• Controlling: COEP (ECC), ACDOCA segments (S/4HANA)

Operational patterns that help include:

• Parallelize initial loads by time ranges (year and quarter) and org units when safe.
• Separate “hot” recent periods from deep history pipelines.
• Automate backfills and reprocessing rather than treating them as one-off events.

Replication does not protect you from SAP semantics. Build these rules early:

• Client handling (MANDT): prevent cross-client contamination.
• Currency handling: document vs local vs group currency must be explicit.
• Units of measure: base UoM vs sales UoM, conversion factors, and rounding.
• Language texts: decide default language and fallback logic.
• Time validity: “as-of” joins for time-dependent attributes.

If you are doing SAP hana data migration from HANA-side reporting tables, validate whether those tables already contain derived logic. If they do, decide whether you preserve it or re-derive from base tables for transparency.

Enterprise ingestion needs repeatability. Specifically, aim for:

• Idempotent loads (re-runs do not duplicate).
• Retries with backoff and clear failure states.
• Dead-letter handling for problematic records.
• Schema drift detection and alerting (SAP upgrades add fields).
• Controlled backfills with approvals, especially for Finance periods.

Security often derails SAP projects late, when teams discover restricted fields after modeling.

Plan early for:

• SAP extraction roles (least privilege).
• Field classification (PII, PCI, and sensitive HR).
• Masking and tokenization policies in your target platform.
• Row-level security by company code, plant, and controlling area.

Treat security rules as part of the dataset contract, not as a BI-only concern.

After ingestion, the hardest work starts: transforming SAP records into business-trusted datasets that match BW outputs and Finance expectations.

Transformation is the bottleneck in SAP migration and how to reduce it

Replication is a data engineering challenge. Transformation is an engineering, governance, and stakeholder alignment challenge. It forces Finance, Supply Chain, and IT to agree on definitions, hierarchies, and edge cases. Therefore, transformation becomes the primary bottleneck in many SAP programs.

SAP records are relational and context-heavy. To make them analytics-ready, you often must:

• Conform dimensions across modules (customer, vendor, product, and org units).
• Standardize keys and handle leading zeros and compound identifiers.
• Build SCD strategies for time-dependent master data.
• Resolve hierarchies with effective dates and versions.
• Encode business rules for sign logic, reversals, cancellations, and clearing.
• Create aggregates that match existing BW queries and close reporting.

A strong transformation layer turns “SAP tables” into “business datasets.”

“The whole idea behind migrating is finding a pattern, putting the pattern into Coalesce—that’s the extensibility part of our platform. You can define your own templates, your own user interface elements even. You can apply naming conventions, but you could also implement complex transformations, like SAP-specific currency conversions. If you find a pattern, you can automate that easily.”

— Mark, Sales Engineer at Coalesce, via Demo Dive: Accelerating SAP Migrations

For SAP BW migration programs, teams often ask, “Do we rebuild BW exactly?” A strict rebuild tends to reproduce BW constraints rather than improve them. Instead, translate BW concepts into modern patterns:

• InfoObjects → conformed dimensions and reference tables
• DSO and ADSO → curated fact tables with historization rules
• CompositeProviders → semantic models or marts
• Process chains → orchestrated jobs with dependencies and observability

If business users want BW-style layering, you can still provide familiar layers. However, implement them with cloud-native performance patterns instead of deep view stacks.

Teams often build logic as nested views because it feels fast. Over time, it becomes expensive:

• Queries expand into large SQL trees.
• Optimizers struggle with complexity.
• Debugging and lineage become painful.

A compiled approach materializes the right objects at the right layers—often with incremental models, persistent tables, and selective views. Consequently, it stabilizes both performance and cost.

This is a core area where Coalesce positions itself for SAP transformations on Snowflake. Coalesce compiles transformations into efficient SQL objects, standardizes modeling, and reduces governance friction.

“The combination of Coalesce and Fivetran has helped us re-imagine how to get the most from Snowflake by automating the complicated, manual aspects of ingesting and transforming data. Our team can now build and execute on current projects while planning for future needs, knowing we have the flexibility to deliver and manage optimized pipelines at scale.”

— Ajay Bidani (Power SAP data transformations at scale | Coalesce)

If you want to see how Coalesce frames the transformation bottleneck for SAP-to-Snowflake programs, the SAP data transformations solution page provides a direct overview.

You have three common options. Many enterprises combine them.

Dimensional marts (star schemas)

• Best for: executive dashboards, standardized KPIs, and self-service BI
• Strengths: performance, clarity, and governance
• Watch-outs: conformed dimensions and SCD decisions require alignment

Data Vault

• Best for: long-term historization, auditability, and frequent change
• Strengths: traceability to sources and extension-friendly design
• Watch-outs: you still need consumption marts for BI usability

Wide curated tables one table per domain

• Best for: specific analytics apps, ML features, and fast pilots
• Strengths: easy consumption and fewer joins
• Watch-outs: can become monolithic and unclear on definition boundaries

A practical pattern is to use Data Vault or curated normalized models in the curated zone. Then, publish dimensional marts for consumption.

SAP migrations collapse when each team re-implements shared rules differently. Standardize these once:

• Currency conversion (TCURR-based) with defined conversion dates.
• Fiscal calendars and fiscal variants by company code.
• UoM conversions with maintained factors and rounding rules.
• Text enrichment patterns (language fallback).
• Standard hierarchies (profit center, cost center, and product).

Treat each as a governed shared asset with documentation and tests.

Many sources explain that transformation matters. However, teams still struggle with what to model first. A practical rule is to choose objects that unlock end-to-end reconciliation quickly.

A sequencing approach that works in practice:

• Phase one (foundation): org units, calendar, currency tables, and a core fact.
  • Examples: T001, T001W, company code settings, fiscal variant mapping, and TCURR.
• Phase two (Finance backbone): universal journal or FI documents plus key dimensions.
  • Examples: ACDOCA (S/4), BKPF and BSEG (ECC), SKA1 and SKB1, CSKS, and CEPC.
• Phase three (process chain): pick one process (O2C or P2P), and model it end-to-end.
  • O2C: sales orders → deliveries → billing → AR.
  • P2P: requisitions → purchase orders → goods receipt → invoice → AP.
• Phase four (industry depth): manufacturing, quality, projects, and asset accounting.

This sequencing produces auditable value early. Specifically, you can reconcile totals and prove correctness.

Validation should happen at multiple levels:

• Fact-level parity: document counts and totals by key fields.
• Dimension parity: active members, valid-from dates, and hierarchy rollups.
• Query parity: reproduce top BW queries in the new platform.
• Financial statement parity: P and L and Balance Sheet rollups.

Finance trusts totals, not row counts. Therefore, build reconciliation packs that mirror how controllers validate close outputs.

Now that you know what to build, the next decision is how to build it fast enough. That is where accelerators, standards, and platform choices matter.

SAP migration platforms and services what you need to standardize

Enterprises rarely struggle to find sap migration tools. Instead, they struggle to standardize an approach that scales across domains, teams, and years. Therefore, “build vs buy” is less about licensing and more about operating model and repeatability.

A complete SAP program typically needs:

• Ingestion and CDC: SAP extractors, ODP and CDS, SLT, log-based CDC, or file-based landing
• Transformation and ELT: modeling, incremental patterns, reusable logic, and materialization control
• Orchestration: scheduling, dependencies, retries, and backfills
• Catalog and governance: documentation, lineage, ownership, and access policy mapping
• Data quality and observability: freshness, anomalies, schema drift, and SLA monitoring
• CI and CD: versioning, promotions, approvals, and rollback

If you only invest in ingestion, transformation becomes your bottleneck. That matches what most SAP-to-cloud programs experience: teams have the tables, but stakeholders still cannot answer basic business questions.

Whether you use internal teams or SAP migration services, evaluate for:

• Maintainability: can new engineers understand the pipelines?
• Metadata-driven patterns: can you parameterize logic across 50+ SAP objects?
• Auditability: can you trace a KPI to source fields and logic versions?
• Performance controls: can you avoid repeated full scans and runaway compute?
• Skill alignment: can BW-skilled teams contribute without writing everything in ABAP?

Coalesce is a data transformation platform that accelerates SAP-to-Snowflake migrations with pre-built accelerators from partners like Hakkoda.

“Within a couple of clicks, I actually have an SAP pipeline that’s full-production-ready, ready to go, and starting to move data over. Six months from now, your SAP pipeline will be working just as well as it is today.”

— David Millman, Partner Solution Engineer at Fivetran, via Integrating SAP Data Into Snowflake

The differentiators map directly to SAP pain points:

• Compiled approach: generates efficient tables and views instead of fragile views-on-views.
• Governance without drag: supports documentation, lineage, and standardization as part of delivery.
• Familiar BW-style modeling on Snowflake: helps teams translate BW expectations into modern patterns.

SAP transformations include repeatable logic: text joins, currency conversion, hierarchy expansion, delta merges, and domain marts. Therefore, pre-built Packages reduce time-to-first-value and reduce long-term defects.

Pre-built SAP packages from Coalesce Marketplace can reduce development time by 80% or more, enabling teams to develop data pipelines and transform data efficiently.

Some organizations modernize onto Databricks or run Snowflake and Databricks together. The core message remains: SAP movement is necessary, but transformation and operations determine success.

For Databricks-specific guidance, see the Demo Dive: SAP migration to Databricks made simple.

You can also reference broader community discussions via the SAP migrations podcast episode and SAP and Snowflake manufacturing context via Accelerating SAP data transformation with Snowflake’s Manufacturing Data Cloud.

Tooling decisions only matter if they support your hardest migration variants. Next are two common enterprise scenarios: BW-to-Snowflake and SAP Analytics Cloud content migration.

Migration variants: BW, SAC, and cutover strategies

SAP BW to Snowflake migration translation patterns without losing trust

A SAP BW to Snowflake migration is not just moving tables. It is translating BW semantics, process chain behavior, and reconciliation expectations into a cloud-native stack.

Many BW environments carry years of business logic: currency conversions, exception aggregations, hierarchy versions, and custom transformations. Therefore, the migration strategy must decide what to re-use, what to refactor, and what to retire.

“You want to be able to combine your SAP data with the non-SAP data that might be outside of your SAP system, to build that single source of truth for all of your data that’s relevant to your organization. That could be other applications, marketing tools, other vendors and partners you work with.”

— Sam, Senior Solution Architect at phData, via Integrating SAP Data Into Snowflake

What makes BW migrations difficult

BW contains meaning, not just data:

• InfoProvider design encodes grain and aggregation behavior.
• Process chains encode dependencies and cadence.
• Variables and exits embed business logic.
• Queries embed exception aggregation, restricted key figures, and calculated key figures.
• Open Hub feeds may already represent a curated contract dataset.

In addition, BW often includes custom ABAP logic that has no direct analog in SQL unless you rewrite it explicitly.

A translation map you can use during planning

Use this mapping to create a work breakdown structure:

• InfoObjects
  • Target: dimension tables + conformed keys + hierarchy tables
  • Work: leading zero standardization, text join strategy, and SCD decisions
• DSO and ADSO
  • Target: curated facts (incremental tables) with explicit historization rules
  • Work: record modes, delta merges, and correction handling
• Transformations (BW)
  • Target: ELT models with tests and version control
  • Work: rewrite rules, units and currency, derived fields, and error handling
• Queries
  • Target: semantic marts or BI semantic layer models
  • Work: exception aggregation, KPI logic parity, and performance tuning
• Process chains
  • Target: orchestration DAGs with SLAs and observability
  • Work: dependency modeling, rerun strategies, and backfill strategies

Avoid the view stack BW rebuild trap

A common anti-pattern is reproducing BW layering as a deep stack of SQL views because it looks similar. It often fails due to performance and unclear ownership.

Instead:

• Materialize heavy joins and high-usage datasets.
• Build incremental tables for large facts.
• Keep views for lightweight semantic presentation, not heavy lifting.

Reconciliation strategy for BW parity

BW consumers often trust BW because it survived years of reconciliation. Preserve that trust by validating in BW terms:

• Compare old BW query outputs vs new mart outputs for:
  • period-to-date totals
  • YTD totals
  • organizational rollups
  • exception aggregations
• Validate hierarchy behavior:
  • rollups by version and date
  • node validity windows
• Validate currency conversion logic:
  • rate types, translation dates, and rounding

If you can pass BW-style reconciliation packs, stakeholder confidence rises quickly.

With BW content addressed, many enterprises still have dashboards and planning models in SAP Analytics Cloud that depend on BW or HANA. That introduces another migration track.

SAP Analytics Cloud migration what to move what to rebuild and what to retire

A SAP analytics cloud migration is often overlooked in data platform planning. However, SAC content (models, stories, and planning) is frequently tied to BW queries, HANA views, or S/4 CDS views. Therefore, you need a plan for how SAC consumes the new platform, or what replaces SAC for specific use cases.

Start by classifying SAC usage

SAC typically falls into one of three buckets:

• Visualization only: dashboards and stories that you can rebuild in other BI tools.
• Semantic modeling: SAC models that encode calculated measures and dimension logic.
• Planning: planning models with write-back, allocations, and workflows.

Each bucket has different migration implications.

Common target patterns

• If SAC is mostly visualization, many teams:
  • rebuild dashboards in Tableau, Power BI, or Looker, or
  • keep SAC, but repoint models to curated datasets in Snowflake
• If SAC models encode business logic, you should:
  • move KPI logic down into curated marts where possible, and
  • keep SAC measures thin to reduce duplicated logic
• If SAC planning is critical, treat it as a separate program:
  • validate write-back flows and security, and
  • decide whether SAC remains system of record for planning

Data contracts for SAC consumers

SAC users expect consistent dimensions, hierarchies, and fiscal calendars. Therefore, publish explicit SAC-ready datasets:

• Stable keys and consistent text handling
• Pre-aggregated measures where performance requires it
• Certified hierarchies (profit center, cost center, and product hierarchy)
• Documented grain and filters

This is another reason curated modeling matters. It reduces semantic drift across tools.

Next, ground the program in correctness and control: testing, validation, and auditability.

Testing, validation, and operations

Testing validation and reconciliation

The fastest way to lose business trust is to publish dashboards that do not match Finance close numbers. Therefore, validation must be a first-class workstream, not a final checklist.

Validation levels layered controls

Map validation to your architecture layers.

Ingestion-level checks (landing and raw)

• Row counts by table and partition (date, company code, and client).
• Load completeness (no missing partitions).
• Freshness checks (SLA-based).
• Schema drift detection (new columns and type changes).

Raw-to-curated checks

• Key uniqueness (no duplicate documents after merges).
• Referential integrity (facts match dimensions where expected).
• Null thresholds for required fields.
• Duplicate detection beyond simple keys (SAP keys can be tricky).

Curated-to-consumption checks

• KPI parity tests (gross sales, net sales, COGS, and inventory valuation).
• Aggregation parity by fiscal period, org unit, and currency.
• Top-N comparisons (largest customers and top materials).

Reconciliation packs make validation repeatable

Instead of ad hoc comparisons, build a reconciliation pack per domain:

• Control totals by period and org unit.
• Document counts and reversal counts.
• Totals by currency type (document, local, and group).
• Exception listings (what does not match, and why).

Store pack outputs in an immutable location. Consequently, you can use them for audit and regression tests.

Sampling strategies that find real defects

Random sampling often misses the issues that cause escalations. Instead, sample by business significance:

• High-value documents.
• Edge-case document types (credit memos and cancellations).
• Backdated postings.
• Close adjustments and accrual postings.
• Documents with unusual currencies or UoM conversions.

Handling timing differences late postings and reversals

Near-real-time pipelines surface mismatches that are not bugs. Instead, they are timing differences.

Mitigations include:

• Use a rolling correction window (reprocess the last 30–60 days).
• Track “as-of” timestamps for close datasets.
• Freeze or snapshot close datasets at agreed cutoffs.

Automated data quality checks continuous not periodic

Automate checks for:

• Freshness: updated within SLA.
• Volume anomalies: unexpected drops and spikes.
• Null spikes for required fields.
• Duplicate rate changes.
• Schema drift and failed casts.

Route alerts based on ownership. For example, ingestion alerts go to data engineering. KPI parity alerts go to domain owners and analytics engineering.

Performance validation prove the SLAs that matter

Test with realistic workload patterns:

• Dashboard concurrency during business hours.
• Close-period spikes.
• Ad hoc analyst exploration.

Validate:

• Response times for top dashboards.
• Workload isolation (separate compute for ELT and BI).
• Materialization choices (tables vs views).
• Cost behavior under concurrency.

Audit readiness SOX style evidence

Auditors want repeatability and evidence:

• Lineage from KPI → mart → curated model → raw tables → SAP sources.
• Versioned transformation logic with approvals.
• Run logs and reconciliation outputs stored immutably.
• Access logs and segregation of duties controls.

Note: A common financial reconciliation pitfall is incorrect reversal and sign handling. Many mismatches come from modeling reversals differently than BW did.

After you prove correctness, you still need to change how the business consumes reporting. That is a cutover and operations problem, not just an engineering one.

Cutover and operations for SAP cloud migration

Cutover is not a date. Instead, it is a controlled shift of trust, workload, and ownership. Therefore, successful SAP cloud migration programs plan operations as carefully as extraction and modeling.

Cutover strategies big bang vs phased vs parallel run

Big bang cutover

• Move all reports at once.
• Works when reporting is limited and dependencies are low.
• Risks failure when Finance close depends on dozens of interlocked queries.

Phased cutover (domain-by-domain)

• Move Finance first, then Sales, then Supply Chain.
• Works when you can certify domains independently.
• Requires strong domain contracts and change control.

Parallel run (dual-run and coexistence)

• Keep BW and the new platform running side by side.
• Works when trust must be earned over multiple closes.
• Costs more short term, but reduces business risk.

Release management treat transformations like software

Strong SAP migration best practices treat ELT like application code:

• Use Environments (dev, test, and prod) with controlled promotion.
• Version transformations and configuration.
• Require approvals for changes that impact certified KPIs.
• Maintain rollback strategies (previous mart versions).

If transformation code is not versioned, you cannot explain why last month’s close differs from this month’s results.

Ongoing change management SAP keeps changing

Common SAP-driven changes include:

• New company codes, plants, and sales orgs.
• Master data reorganizations (profit center restructures).
• Support packs adding fields or changing extractors.
• New Z objects for local requirements.

Prepare with:

• Schema drift monitoring and impact analysis.
• Data contract reviews per domain.
• Scheduled backfills for master data history changes.
• Certification cycles for semantic marts.

Cost management governance without slowing delivery

SAP transformations can burn compute if you reprocess history unnecessarily.

Cost controls that work include:

• Incremental materializations for large facts.
• Workload isolation (separate compute for ELT vs BI).
• Guardrails: warehouse limits, timeouts, and scheduling windows.
• Cost attribution by domain or project.

A compiled transformation approach often helps. Specifically, it discourages deep view expansion and makes materialization explicit.

Day two operating model who supports what

Define ownership boundaries clearly:

• Ingestion incidents: data engineering owns; SAP Basis supports source access.
• Transformation defects: analytics engineering owns; business validates rules.
• KPI disputes: business owners decide, using lineage evidence.
• Security incidents: InfoSec owns; platform team implements controls.

Also define SLAs:

• Freshness SLAs per domain.
• Incident response times.
• Close-period change freeze windows.

Comparison table cutover approaches

At this point, you have the pieces. Next is a checklist you can use for architecture reviews and program governance.

SAP migration best practices checklist

Teams that deliver durable SAP programs behave differently in predictable ways. Specifically, they control scope, standardize patterns, and treat reconciliation as a product feature.

Use this checklist for program reviews.

Program level best practices prevent runaway scope

• Tie every migrated dataset to a business use case and data owner.
• Sequence by domain dependencies, not organizational politics.
• Define “done” per domain: latency, parity, SLAs, and security.
• Budget transformation and reconciliation at least equal to ingestion.
• Maintain a living SAP object inventory, including Z objects and extractor customizations.

Data level best practices SAP specific correctness

• Always include MANDT in keys and filters.
• Standardize leading-zero handling and key formatting early.
• Define currency types and conversion rules as governed assets.
• Implement a language strategy for text tables (default + override).
• Treat time validity as a first-class concern (SCD and as-of joins).
• Model reversals, cancellations, and clearing explicitly for Finance and SD.

Engineering best practices scale without brittleness

• Build metadata-driven pipelines for repeated SAP patterns.
• Prefer compiled, materialized transformations for high-volume datasets.
• Use CI and CD with Environments, approvals, and rollback plans.
• Document lineage as you build, not after go-live.
• Automate backfills and correction windows for late-arriving SAP changes.

Governance best practices control without drag

• Apply least-privilege access by layer (raw vs curated vs marts).
• Mask PII before broad access, not only in BI tools.
• Certify gold marts, and enforce change control.
• Store reconciliation outputs and transformation versions for audit evidence.

Common anti patterns to avoid

• Migrating everything because storage is cheap. Compute and trust are not cheap.
• Rebuilding BW as deep views-on-views until performance collapses.
• Skipping reconciliation because you loaded all the rows.
• Encoding business logic inside ingestion jobs where it is harder to test.
• Letting each domain invent its own currency and hierarchy logic.

30 60 and 90 day roadmap pilot to scale

First 30 days foundation and pilot scope

• Confirm target architecture and zone definitions.
• Inventory SAP objects for one domain (often Finance or Sales).
• Set up ingestion for a narrow set of high-value objects.
• Define reconciliation packs and acceptance criteria with business owners.

Next 60 days curated models and first certified outputs

• Build curated models with standardized keys, currency logic, and SCD handling.
• Publish first consumption marts for two–three priority dashboards.
• Run parallel reconciliation for at least one close cycle (Finance) or monthly cadence.
• Implement automated data quality checks and alert routing.

Next 90 days operationalize and expand domains

• Harden CI and CD, Environments, and release governance.
• Add additional domain objects using repeatable Packages and patterns.
• Expand certified marts, and deprecate equivalent BW queries where agreed.
• Formalize incident response and cost governance.

Conclusion key takeaways for IT leaders and architects

A successful SAP migration is not a data copy exercise. Instead, it is an engineering and governance program that turns SAP operational records into trusted analytics assets.

The durable patterns are consistent:

• Scope by domains and outcomes, with measurable acceptance criteria.
• Separate ingestion from transformation so each layer stays maintainable.
• Treat transformation as the core workstream because it drives trust and performance.
• Invest in validation and reconciliation early to earn business confidence.
• Operationalize change management because SAP will keep changing after go-live.

If you are collecting implementation references, templates, or examples to support your program plan, Coalesce maintains a central resources library that can help teams standardize how it evaluates and runs migration approaches. For upcoming SAP-related sessions and an events archive, monitor the Coalesce events page.