The real answer is a range, and the range depends on five drivers you can estimate before talking to anyone. Here's how we scope it, what the hidden costs are, and when you shouldn't migrate at all.

Every migration conversation starts with the same question and gets the same useless answer: "it depends." It does depend, but on knowable things. If you can count your source systems, estimate how much undocumented logic lives in your current pipelines, and list the reports that absolutely cannot break, you can get to a defensible budget number before a single vendor call.

Here's how we think about it.

The five cost drivers

1. Source system count. Each source (Salesforce, your production database, Stripe, the ERP) needs a connector, historical backfill, and someone who understands its quirks. A company with 4 sources and a company with 20 are running different projects. Managed connectors (Fivetran, Airbyte) keep this cheap for standard sources; the expensive ones are the internal systems and the vendors with bad or rate-limited APIs.

2. Undocumented transformation logic. This is the driver most teams underestimate. Fifteen years of stored procedures, scheduled SQL jobs & Excel macros encode business logic nobody wrote down. Migrating the data is easy. Reverse-engineering what the old pipeline meant to do, deciding what to keep, and re-implementing it in tested models is where the hours go. A rough tell: if nobody at your company can explain how revenue is calculated end to end, budget more.

3. The report surface you have to protect. The migration isn't done when the data lands; it's done when the reports leadership already relies on produce the same or better answers from the new platform. More reports, more validation. We handle this with a parallel run (old & new systems side by side, reconciled weekly). It adds cost up front and removes the much larger cost of a broken report surface at cutover.

4. Team availability on your side. Someone who knows the business logic has to answer questions. If your analysts can give a few hours a week, the project moves. If every question waits five days, the timeline (and the bill) stretches. This is free for you to fix and worth real money.

5. Compliance & access requirements. SOC 2, HIPAA, PII handling, row-level security. None of these are exotic, but each adds design and review time. Flag them in the first conversation, not week six.

What the numbers look like

With the caveat that these are services costs (platform costs below), based on the engagements we scope:

  • Small (~4–6 sources, modest logic, a handful of critical reports): roughly $25K–$60K, 8–10 weeks.
  • Mid (~8–15 sources, real legacy logic, a report surface people fear): roughly $60K–$150K, 10–14 weeks.
  • Complex (15+ sources, compliance requirements, embedded/customer-facing reporting): $150K–$250K+, and worth splitting into phases rather than one heroic cutover.

The spread inside each band is mostly driver #2. Two companies with identical source counts can differ 2x on cost because one has documented, comprehensible logic and one has a decade of archaeology.

Platform costs are separate and recurring: for mid-market workloads, expect roughly $2K–$10K/mo across warehouse compute (Snowflake, BigQuery, Databricks) and ingestion tooling once you're in steady state. Anyone quoting platform costs without seeing your workload is guessing; a two-week audit produces a real estimate.

The hidden costs nobody quotes

  • The parallel run. You pay for two systems for 4–8 weeks. That overlap is why the cutover itself is uneventful.
  • Report rebuilds. Dashboards pointed at the old warehouse need re-pointing, and a chunk of them were broken already. Decide deliberately which ones deserve to survive (usually fewer than you think, which pulls the budget back down).
  • Your team's hours. Interviews, validation reviews, access provisioning. Budget a few hours a week from the people who know the data.
  • Deciding what not to migrate. Every warehouse accumulates dead tables, and migrating everything "to be safe" means paying to move tables nobody queries. An audit that deletes before it moves pays for itself.

When you shouldn't migrate

We sell migrations, so read this list as against our own interest:

  • Your current setup is slow but correct, and the real complaint is dashboard usability. That's an analytics problem, not a platform problem, and it's cheaper to fix.
  • Nobody trusts the numbers. A new platform won't change that on its own (the doubt migrates along with the tables). Fix the modeling and testing layer first or alongside.
  • You're pre-product-market-fit with three sources and one analyst. Postgres and a BI tool are fine. Come back in a year.

How to get a real number

Our modernization engagements start with a one-week discovery: source inventory, logic audit, report tracing, and a fixed-price SOW with the phasing laid out. You can run the same exercise internally: count the sources, list the reports that can't break, and try to get one revenue number explained end to end. However long that explanation takes is your best single predictor of migration cost.

If you'd rather we did it, tell us what you're running today and we'll tell you which band you're in, within one business day.

Dealing with a version of this?

Send us a few sentences about where things stand. A partner reads it and replies within one business day, whether or not we're the right fit for the work.

Keep reading