Back to Blog
Data Engineering

Why Indian enterprises are finally ditching SAP BW for AWS Redshift — and what it takes to do it right

For the better part of a decade, SAP BW was the default answer for enterprise data warehousing in India. It was expensive, it was slow, and it required an IT team just to build a single new dashboard — but it was known. Procurement knew it. Finance knew how to budget for it. And consultants knew how to implement it without being blamed when things went wrong.

That era is ending. We spent six months helping a multi-brand retail group migrate off SAP BW entirely — replacing it with an AWS data lakehouse built on Redshift, Glue, S3, and QuickSight. Here's what we actually learned.

"The technology was the easy part. The hard part was convincing the CIO that the new system was ready before they'd stopped paying the old one."

Why SAP BW is failing analytics teams right now

The problems aren't new — they've just hit a tipping point. Three things have converged to make the status quo unsustainable:

  • Data volumes have outpaced the architecture. SAP BW was designed in an era of structured data and overnight batch jobs. Modern retail generates continuous event streams, customer behaviour data, and real-time inventory signals that BW simply can't handle at cost.
  • Business teams want self-service. The old model — submit a request, wait two weeks for IT to build a report — doesn't work in 2025. CFOs and commercial directors want to query their own data, on demand, without touching a ticket queue.
  • The licensing math has changed. AWS consumption-based pricing, especially at the scale of a mid-sized enterprise, is materially cheaper than SAP's licence + implementation + maintenance model once you account for total cost of ownership over three years.
Our project in numbers
80%
Reduction in report build time
10×
Faster query performance
40%
Less IT dashboard dependency

The architecture we actually built

The target architecture wasn't complicated, but getting there required choices at every layer. Here's what we landed on and why:

Storage layer: S3 as the source of truth

Everything lands in S3 first — raw, unprocessed, immutable. This gives you a full audit trail and the ability to replay any transformation if your logic changes. We partitioned by date and source system from day one, which paid dividends when we needed to backfill historical data.

Transformation: AWS Glue with PySpark

Glue handled the ETL — ingestion from the client's ERP and POS systems, cleaning, and loading into Redshift. We kept the transformation logic simple and readable; anything clever enough to require a comment was a smell that we'd overcomplicated it.

Analytics layer: Redshift + QuickSight

Redshift Serverless removed the cluster management headache entirely. QuickSight gave business users dashboards they could actually use — and the Amazon Q integration meant senior stakeholders could type questions in plain English and get answers without touching SQL or calling IT.

What nobody tells you about the migration

The technical migration was the easiest part. The harder challenges were entirely about people and process:

  • Executive alignment takes time. We spent six months building confidence with the CIO and CFO before a single line of production code was written. Co-creating the CEO pitch using the client's own sample data was the moment that changed the conversation.
  • Data quality issues surface during migration. SAP BW had been hiding data quality problems for years — inconsistent product hierarchies, duplicate customer records, unmapped cost centres. The migration forced the client to fix them. This was painful but ultimately valuable.
  • Training is not optional. Deploying QuickSight and walking away is a recipe for failed adoption. We ran role-specific training sessions for finance, commercial, and operations teams before go-live. Usage metrics post-launch were significantly better as a result.

"Data quality issues don't disappear when you migrate — they become visible. That's uncomfortable, but it's progress."

When a SAP BW migration is the wrong call

Not every organisation should migrate. If your SAP BW implementation is genuinely serving your reporting needs, your data volumes are modest and structured, and your business teams aren't demanding self-service access — the disruption and cost of migration may not be justified.

Where migration makes clear sense: data volumes are growing fast, you're spending disproportionate time on IT-mediated reporting, and leadership is open to modern tooling. In our experience, it's the combination of these three factors — not any single one — that makes the business case undeniable.

Thinking about a migration?

We've done this. If you're weighing up a move off SAP BW — or any legacy data warehouse — we're happy to talk through the architecture and the sequencing. No pitch, just a practical conversation.

AWS Redshift SAP BW Data Lakehouse Amazon Q Migration Analytics
← Previous
Returning to a tech career after a break: what's changed and how to close the gap
Next →
LLM, RAG, or fine-tuning? Choosing the right AI approach for your use case