How an engagement would unfold, methodology walkthroughs.

Scenario: a US mid-market SaaS, ~200 TB Redshift estate, ~3,800 objects (tables + views + procedures + scheduled jobs), data team of 8-12 engineers, BI workload heavy on Mondays. The shape we screen for during Discovery and how the methodology would play out.

Discovery Sprint, days 1-10. Full inventory artifact (Appendix A) covering every table, view, procedure and scheduled job. Dependency graph derived from stl_query traffic over a 30-day window. Industry benchmarks (Wakefield Research / Pragmatic Works) suggest 20-40% of analytical estates at this scale carry assets that haven't been queried in 90+ days; the Sprint identifies that specifically for the client and recommends "retire-don't-migrate" candidates. 3-year TCO model carrying Redshift status quo vs Snowflake target state.

DDL gotchas we screen for. Every Redshift → Snowflake conversion runs through our codified rule library — the patterns that consistently break timelines if not screened up front. DISTKEY/SORTKEY → CLUSTER BY mapping is rebuilt from actual prune-ratio data (not naive 1:1 mapping); IDENTITY columns on audit / ledger tables get sequence + application-side gap detection; SUPER → VARIANT translation gets mixed-type column screening; window function NULLS ordering gets explicit annotation. Full detail in the Redshift → Snowflake playbook.

Six-wave Execution. Inventory + DDL freeze → Staging + dual-run → Pilot workload → BI repointing → ELT cutover → Decommission + 30 days hypercare. Per-wave deterministic reconciliation report (row counts, schema parity, float-tolerant checksums, query-result diffs on 50 sampled analytical queries, bounded cell-diff). Typical clock-time at this scale is 10-16 weeks based on public benchmarks and our methodology.

Cost shape under public pricing. Steady-state Snowflake run-rate at this workload typically lands ~30-40% below the source-platform run-rate (Redshift RA3 list + DBA-time-equivalent), before counting any retire-don't-migrate savings. Numbers depend on the specific workload mix; we model your specific shape during Discovery.

Scenario: an Indian BFSI mid-tier (tier 2-3 private bank or NBFC) with AWS spend in the ₹35-50 L/month range running across six environments inside a single AWS account, engineering team of ~20, an upcoming RBI compliance review forcing account-structure cleanup. The shape is common; the methodology below is what our Discovery Sprint + Execution would prescribe.

What we would build. A multi-account landing zone using AWS Control Tower with separate accounts for production / staging / dev / sandbox / shared-services / log-archive; OU layout mapping to the RBI compliance scope; baseline guardrails (no public S3, MFA-on-root, CloudTrail org-wide, GuardDuty everywhere); IAM blueprint based on RBAC + least-privilege with break-glass roles; Terraform-as-IaC organized by account + environment with drift detection. Workload migration from old single-account into the new topology, typically over 8-10 weeks for this size of estate.

FinOps lever pull during the landing-zone work. A landing-zone re-architecture surfaces FinOps waste as a byproduct. Categories we screen for and have public industry benchmarks on: unattached EBS volumes (commonly 5-10% of EBS spend), over-provisioned RDS instances (FlexFinOps research suggests ~30% of RDS instances run below 20% peak utilization industry-wide), idle DR replication paths, always-on dev / staging environments without scheduled scale-down. The FinOps Audit deliverable scopes the specific client number with named owners and effort estimates.

Compliance posture. Security Hub integrated with RBI control mappings; CIS Benchmark Level 2 baseline applied; audit-log retention extended to 7 years per RBI guidance; encryption-at-rest enforced across S3 / EBS / RDS via Organization SCP. Compliance evidence pack ships as part of the engagement deliverable.

Cost shape. The combined landing-zone + FinOps engagement typically pays for itself in cloud-spend reduction within the first quarter post-cutover, based on public FinOps Foundation State of FinOps benchmarks (~25-35% reduction is common for first-time FinOps engagements at India BFSI scale). Specific savings depend on the current account structure and waste mix; the FinOps Audit numbers carry the per-client estimate.

Scenario: a media or consumer company running 200-300 Informatica PowerCenter mappings against an Oracle warehouse, with pressure on Informatica license renewal and a strategic decision to consolidate analytics on Databricks. Migration shape: Informatica → dbt + Airflow, Oracle → Databricks lakehouse, ML platform consolidation onto Unity Catalog.

Discovery Sprint findings (typical shape). At this estate size, the methodology consistently surfaces a similar breakdown: 10-20% of mappings are dead (last run > 9 months ago, owners gone, no downstream consumer) → retired in flight. 10-15% are "lookup-heavy" transforms → translate cleanly to dbt models. 50-65% are "control flow + SQL" mappings → split into dbt models + Airflow DAGs. 10-15% are genuinely procedural (cursor-based row iteration, error-handling state machines) → custom Python + Spark.

Lakehouse architecture. Medallion layering (bronze / silver / gold), Delta tables as the storage format, Unity Catalog for governance + lineage, dbt project structure mirroring the four mapping categories, Airflow DAGs for the control-flow patterns dbt cannot express natively. Iceberg interop kept where downstream tools require it.

Reconciliation. Row-for-row reconciliation against the source Oracle warehouse for every gold-layer table; query-result diff on a sample of 60-80 analytical queries; per-wave signed evidence reports.

Cost shape. The Informatica license drop at renewal time is the headline financial lever; for a 200-300 mapping shop on a single Informatica instance, public license pricing puts annual savings in the €150-300k range. Databricks consolidates analytics + ML workloads; total clock time for an Execution at this scale based on published benchmarks is 18-26 weeks including hypercare.