The CFO and the VP of Sales arrive at the quarterly business review with two different customer churn figures. Both come “from the system”. One is calculated in the subscription billing platform, the other in a spreadsheet that the revenue operations team rebuilds every month from CRM exports. The gap is four percentage points, and nobody in the room can say within five minutes which number is right. The CEO asks the question that starts many data warehouse projects: “Why don’t we have a single source of truth?”
A few weeks later the CTO or Head of Data has three proposals on the desk. The first promises “a modern cloud data warehouse in 12 weeks” for a fixed €140,000. The second lists day rates for a team and a timeline, but no total. The third starts with a discovery workshop and an assessment and prices everything else “after analysis”. Each describes a different service, though all three call it data warehouse consulting.
This article is for the people who have to choose such a service and defend the choice to the board. We do not compare architectures here; we did that in our piece on data mesh versus the data warehouse. This one is about buying: what should be delivered, how it is priced, what it costs and what goes into the contract. The thesis is this: data warehouse consulting is best bought as a transfer of capability, not as a turnkey build. A good engagement ends when your own team can add a new data source and a new metric without the consultant. A turnkey warehouse at a fixed price is usually the most expensive way to buy this service, even when it looks like the cheapest line in the comparison.
What is data warehouse consulting, and how is it different from buying a warehouse?
A data warehouse is not a product you purchase. It is a set of decisions and code that someone has to maintain for years. The platform, whether Snowflake, BigQuery, Microsoft Fabric, Databricks, Redshift or an on-premises database server, is only where those decisions are executed. Data warehouse consulting is the service that helps you make those decisions, write them down as code and teach your organisation how to change them.
Under that single label the market sells at least six distinct services. They are worth separating, because each has a different output, a different pricing model and a different risk profile:
- Assessment and data strategy. A few weeks of interviews, a review of source systems and data quality. The output is a recommendation, a plan and a cost estimate.
- Architecture and data model design. Choice of layers, platform, ingestion and transformation tooling, and a data model for the first business processes.
- Build (implementation). Source integration, transformations, data quality tests, a semantic layer and the first reports.
- Migration. Moving an existing warehouse, for example from an on-premises server to the cloud, or from one cloud platform to another.
- Optimisation. Performance, platform cost, and clean-up of models and dependencies that have accumulated over the years.
- Run and evolve. A standing team or individual specialists who develop the warehouse alongside your people.
The “warehouse in 12 weeks” proposal usually bundles design and build into one fixed-price engagement. The day-rate proposal is typically build and run. The proposal that opens with a workshop is an assessment. Comparing them directly is like comparing an architect’s drawings with a construction crew and a property management contract. The first step in choosing a vendor is therefore to decide which of these services you are buying now and which belong to later stages.
When do you really need a consultant, and when is an analyst with a BI tool enough?
Many companies commission a warehouse because “that is what you do”, and many others postpone one for years even though the cost of manual reporting long ago exceeded the cost of the project. The signs that the problem is real are fairly clear.
The same metric has several values. Gross margin, active customers or inventory turnover come out differently in different departments, because each defines the period differently, excludes different items or pulls data from a different system. That is a definition problem rather than a technology problem, but the warehouse is where the definition is written down once.
Reports are assembled by hand from several systems. If someone in finance spends several days a month stitching together exports from the ERP, the CRM and the warehouse management system, you are already paying for a data warehouse. You are just paying in headcount and spreadsheet risk.
The company is preparing for AI initiatives. In February 2025 Gartner predicted that through 2026 organisations will abandon 60% of AI projects that are not supported by AI-ready data. In the same release it reported that 63% of organisations either do not have, or are not sure they have, the right data management practices for AI. A language model connected to inconsistent data produces inconsistent answers, only faster than a person would.
A source system or a regulation is changing. An ERP replacement, a merger, new reporting obligations. Structured e-invoicing is a good European example: Belgium made B2B e-invoicing mandatory from 1 January 2026, and Poland’s national e-invoicing system KSeF becomes mandatory in stages from February 2026. Structured purchase and sales invoices in one format are a data source many finance teams will want to analyse, and it pays to decide early where and how they will be modelled.
The bill for an existing platform grows faster than its user base. That signals a warehouse that exists but whose usage nobody controls.
When is a consultant not needed? When almost all your data comes from one system and its built-in reporting answers the board’s questions. When the company is small and has one revenue stream. When nobody on the business side will own the metric definitions. In that last case a consultant will build a warehouse that nobody uses. It is better to hire a data analyst with a good BI tool first and return to the topic when their work starts to choke on joining sources.
There is also an in-between situation that is more common than it seems: the company already has a BI tool and a handful of working reports, but every new report takes weeks because the analyst joins data inside the reporting tool itself. This is the point at which a warehouse starts to pay for itself, because the joining logic moves from dozens of reports into one place. You do not need a hundred-slide data strategy then. You need a well-designed first domain and someone to teach your analyst how to work with it.
What should each stage of data warehouse consulting deliver?
The best protection against a bad engagement is knowing what a good result looks like at each stage. The table below is a checklist you can attach to an RFP.
| Stage | Typical duration | What should be delivered | Red flag |
|---|---|---|---|
| Assessment | 3–6 weeks | Business questions with owners, source map with data quality assessment, bus matrix of processes and dimensions, architecture recommendation with alternatives, build and run cost as a range | A slide deck of platform logos without any analysis of your data |
| Architecture design | 2–4 weeks (often combined with the assessment) | Data layers, naming conventions, model of the first process, data quality test strategy, access model, platform cost estimate | No decision on who adds a new source and how |
| First data domain | 2–4 months | Working source integrations, transformations in a repository, tests, semantic layer, reports used by named people | Reports “done” but nobody opens them |
| Further domains | 1–3 months each | New processes in the same model, shared dimensions (customer, product, date) | Each domain has its own definition of a customer |
| Handover | 4–8 weeks, in parallel with the build | Documentation, training sessions, client team independently adds a source and a metric | Handover is a single presentation in the final week |
| Cost optimisation | 2–6 weeks | Platform cost report by team and query, configuration changes, budgets and alerts | ”Buy a reservation” advice without workload analysis |
The durations are indicative ranges for a mid-sized company with a handful to a dozen or so source systems, not a standard. What matters is not the weeks but the outputs in the third column. If a vendor cannot name them before signing, they will not deliver them after.
Pay particular attention to the bus matrix. It is a tool described by Ralph Kimball and Margy Ross in “The Data Warehouse Toolkit” (third edition, Wiley, 2013): rows are business processes (orders, procurement, inventory, returns), columns are shared dimensions (customer, product, date, region). One page shows which processes share definitions and in which order to build them. Even if your warehouse is not built strictly the Kimball way, this document structures the conversation with the board better than any architecture diagram.
Why is the platform choice the least important decision in the project?
This part of the thesis usually draws the most pushback, so it deserves a justification. Data warehouse platforms differ in pricing model, integration with the rest of an ecosystem and a handful of features. Yet every mature platform can store a mid-sized company’s data and answer its queries in seconds. Warehouse projects rarely fail because the wrong platform was chosen. They fail because nobody agreed the metric definitions, the source data turned out worse than assumed, and the reports did not answer the questions the board actually asks.
Whether your warehouse still works in three years depends on things that are independent of the platform:
- The data model. Whether customer, product and period have one definition across all processes. A bad model costs more than a bad platform, because it propagates into every report.
- Data owners. Whether it is clear who on the business side decides what an “active customer” is. Without that, the warehouse cements the dispute instead of settling it. We cover this role in our article on data governance.
- Transformation code in a repository. Whether logic lives in version-controlled code with tests, for example in dbt, or in stored procedures and hand-clicked pipelines.
- Data quality tests. Whether every load checks key uniqueness, completeness and reconciliation with the source system.
- Team capability. Whether your people can change all of this without the consultant.
The platform does matter in three situations: when the company already has a strong commitment to one cloud provider (an enterprise agreement, team skills), when regulatory requirements restrict region or processing model, and when the workload is unusual (very high streaming volumes, semi-structured data at large scale). Outside these, a good consultant should be able to say that two or three platforms are equally suitable and pick the one that best fits your team and your existing contracts.
A consultant who opens the conversation with a platform name is signalling one of two things: either a commercial relationship with that vendor, or a habit of selling what they know rather than what you need. Ask directly whether the firm receives referral fees, partner discounts or implementation credits from platform vendors. The answer does not disqualify the proposal, but it should be on the table.
For the broader background on how architectures have evolved, from warehouse to data lake, lakehouse and data mesh, see our guide to the modern data platform. For a purchasing decision one point is enough: the platform is a means, and the consulting scope should be described in outputs that do not depend on its logo.
How are data warehouse consulting services priced?
The pricing models are the same as in other IT projects, but the nature of data changes their risk. Application code is written from scratch and you know what it should do. Source data is inherited as it is, and you only learn its true condition during the build. That is why a fixed price for an entire warehouse is riskier here than it is for an application.
| Model | When it fits | Risk for the buyer | What to watch |
|---|---|---|---|
| Fixed price per stage | Assessment, architecture design, migration of a precisely defined report set | Risk premium baked into the price; scope change disputes | Precise acceptance definition; written assumptions about data quality |
| Time and materials | Building data domains while scope clarifies | No upper cost limit | Cost cap per domain, progress report every two weeks |
| Capped time and materials | Build with budget control | Vendor may slow down as the cap approaches | Acceptance criteria per domain, not for the whole |
| Team subscription | Run and evolve after the first domain | You pay for availability, not output | Quarterly objectives, delivery pace review |
| Specialists joining your team | You have your own data lead and need capacity | Management and accountability for outcomes stay with you | Skills match, trial period, replacement terms |
| Outcome-based fee | Rare; platform cost optimisation | Disputes over what counts as a “saving” | A measurable baseline before the start |
The combination that most often works looks like this: a fixed-price assessment, then capped time and materials for each data domain with acceptance criteria per domain. After two or three domains, once you know what a typical increment costs, move to a smaller continuous team or to individual specialists working alongside your people. For a broader comparison of these engagement models, see our article on staff augmentation, managed services and outsourcing.
Why not a fixed price for the whole thing? A vendor that agrees to build a warehouse for a fixed sum before seeing your data has two options. It can add a large risk reserve that you pay whether or not the risk materialises. Or it can narrow the acceptance definition so that “warehouse delivered” means working loads and a few reports, regardless of whether the numbers reconcile. Either way you pay more than the proposal shows: once in the price, and again in change requests and in your own team’s time spent on fixes.
The exception is a migration with a countable scope: an existing warehouse, a known number of tables, procedures and reports, and a clear definition that “output after migration equals output before”. A fixed price can be reasonable there, provided the vendor has reviewed the code itself and not just a description of it.
There is also a model that rarely appears in proposals but is worth considering: pricing per data domain delivered against an acceptance definition, with the price agreed after a short analysis of that specific domain. It sits between fixed price and time and materials, and it works once both you and the vendor know the sources well enough after the assessment to estimate a single increment.
What does it cost, and how do you build a budget before talking to vendors?
There is no honest price list for “a data warehouse”, because cost depends on the number and quality of sources, the number of business processes and how much work stays on your side. You can, however, calculate an order of magnitude with a parametric estimate: team composition times duration times rate. It will not replace a proposal, but it lets you judge whether proposals fall within a sensible range.
Here is an illustrative example using the rate ranges on ARDURA’s pricing page (net day rates, 21 working days per month). A team building the first data domain consists of two senior data engineers (EUR 370–520 per day), an architect at half time (we use the senior cloud architect range, EUR 465–650) and a project manager or analyst at half time (EUR 355–485). A month of this team costs roughly EUR 24,000–34,000. Four months to build the first domain comes to roughly EUR 97,000–135,000. An assessment carried out by an architect and one data engineer over four weeks is, on the same basis, in the region of EUR 17,000–24,000. For context, ARDURA’s pricing page puts senior nearshore rates around 35–55% below the average German IT freelance rate of EUR 95 per hour reported by Freelancer-Kompass 2025; onshore teams in Western Europe or the US will price the same plan higher.
This is an illustrative estimate, not a quote: the actual team and duration come out of the assessment. It still shows two things. First, a proposal for “a warehouse in 12 weeks for €140,000” implies either a narrow scope, a small team or optimistic assumptions about data quality, and it is worth asking which. Second, consultant fees are only part of the total cost of ownership. A complete budget should include:
- Consultant fees across the stages.
- Your own people’s time: data owners, analysts, administrators of the source systems. This cost is invisible in proposals but significant in data projects, because only your people know what the fields in the ERP actually mean.
- The platform: compute, storage and data transfer. More on this in the next section.
- Tooling: ingestion, transformation, reporting, data catalogue, monitoring. Some is free in open-source editions, some is priced per user or by volume.
- Run costs after go-live: in a typical warehouse someone has to react to source changes, add metrics and watch costs. That is usually at least part of a data engineer’s time on a permanent basis.
When presenting the budget to the board, show it as a range with assumptions rather than one number, and ask for a staged decision: assessment first, then the first domain, then the rest. We discuss this way of framing IT budgets more broadly in our article on CIO priorities for the 2026 IT budget.
Why can the cloud bill end up larger than the consultant’s invoice?
Cloud data warehouses charge for consumption, and consumption depends on design decisions the consultant makes. That is why their work affects your bill for years after the engagement ends, usually more than their own invoice does.
Two examples from public price lists. BigQuery on-demand pricing is USD 6.25 per TiB scanned, with the first TiB each month free. Imagine a dashboard that refreshes every 15 minutes and scans 50 GiB each time because the underlying table is not partitioned by date. That is 96 refreshes a day, around 4.7 TiB a day and more than 140 TiB a month: close to USD 900 a month for a single dashboard. Partitioning and an incremental model can cut the scanned volume by an order of magnitude.
Snowflake charges compute in credits: a Medium virtual warehouse consumes 4 credits per hour, billed per second with a 60-second minimum each time it starts. According to published pricing summaries, an Enterprise edition credit in the AWS US East region costs about USD 3 (the price depends on edition, region and contract). A Medium warehouse left running all month without auto-suspend uses 2,880 credits, roughly USD 8,600, even if it did real work for only a few hours a day.
Neither example is a flaw in the platform. Both are consequences of decisions about partitioning, refresh schedules, warehouse sizing and suspension, and model materialisation. That is why the consulting scope should include:
- A platform cost estimate for the target workload, with assumptions, not just licence prices.
- Tagging and cost allocation by team or data domain from day one.
- Budgets and alerts configured in your account, not the consultant’s.
- A review of the most expensive queries and models before each domain is accepted.
Write down in the contract who is responsible for platform cost during the build. If the consultant’s team works in your account, it should have an assigned budget for development environments and report its consumption alongside progress.
A separate question is pricing in your contract with the cloud provider rather than with the consultant. Capacity reservations, spend commitments and volume discounts can cut the bill significantly, but only when you know the real workload. A commitment signed on an optimistic estimate from the first week of the project can be as expensive as no commitment at all. It is usually wiser to pay as you go for the first months, measure, and negotiate afterwards.
Which questions should you ask a consultant before signing?
The conversation before signing should test whether the vendor understands your problem or only its own tools. These questions separate one from the other.
“What will you do in the first week?” A good answer includes conversations with metric owners and a review of source data. A bad answer starts with platform configuration.
“How will you check source data quality before pricing the build?” The consultant should want to see data samples, row counts, nulls and duplicate keys. Pricing a build without that is pricing blind.
“Who will add a new source after the project, and how?” This answer tells you more about the architecture than any diagram. If it is “you will call us”, you know the vendor’s business model.
“How do you test transformations?” Look for specifics: uniqueness and completeness tests, reconciliation of totals against the source system, tests that run automatically on every code change.
“Where will the code live and who will have access?” The only good answer is: in your repository, from day one.
“What commercial relationships do you have with platform vendors?” Openness here is a good indicator of honesty in the rest of the proposal.
“Who exactly will work on the project, and what happens if they leave?” Data projects depend on knowledge of your sources, and turnover in the consultant’s team costs you weeks. Ask about replacement guarantees and time to replace. At ARDURA, engagements carry a two-week specialist replacement guarantee and replacement within five business days; whichever vendor you choose, get such terms in writing.
“What security and compliance evidence can you provide?” A consultant with access to production data should be able to show how it controls that access, for example with a SOC 2 report or an ISO/IEC 27001 certificate, or at least documented policies you can review.
“What will you do when the source data turns out to be wrong?” This is the most important question, because it will almost certainly happen. A good answer describes a process: raise it with the data owner, decide between a cleansing rule and a fix at source, record the rule in code and in a test. A bad answer promises that the warehouse will “clean the data”. A warehouse can detect and flag an error; only the process that creates it can fix it permanently.
What belongs in the contract so you do not become dependent on the consultant?
A data warehouse consulting contract should protect two things: access to your data and your ability to keep working without this vendor. Specific clauses:
Ownership and location of code. Transformation code, model definitions, infrastructure configuration and documentation are created in your repository and your cloud accounts. Copyright or a licence passes to you on payment for each stage, not at the end of the whole project.
Data processing terms. A consultant working with personal data of your customers or employees acts as a processor under Article 28 of the GDPR, and the contract must include the processor terms that article requires. For US companies handling health data, the equivalent is a HIPAA business associate agreement. Define the scope of access, the environments in which production data may be used, and deletion at the end of the engagement. Consider whether the build can run on anonymised or pseudonymised data.
Sector requirements. EU financial entities have applied the Digital Operational Resilience Act (DORA) since 17 January 2025. It requires, among other things, a register of all contractual arrangements with ICT third-party service providers and specific contractual provisions. If the warehouse supports regulatory reporting, the consulting scope and contract must reflect that.
Platform exit. The EU Data Act has applied its rules on switching between data processing services, including cloud services, since 12 September 2025. Until 12 January 2027 switching charges may cover only the provider’s costs directly linked to the switch, and after that date they are to disappear. This makes leaving a platform easier, but it does not replace order on your side: code in open formats and documented dependencies are what make such an exit feasible in practice.
Knowledge transfer with a measurable acceptance criterion. Not “we will run a training session”, but “the client’s team independently, with the consultant acting only as reviewer, adds a new data source and a new metric to the semantic layer”. This criterion is the core of this article’s thesis: until it is met, the engagement is not finished.
Notice period and handover support. Agree a notice period (30 days is ARDURA’s standard) and an obligation for the vendor to take part in handing work over to another team. Without this clause, every change of vendor starts with reconstructing knowledge.
Platform cost rules. Who pays for resources consumed by the consultant, what the limits on development environments are, and who responds to a budget alert.
How can you tell after three months whether the consulting is working?
The first quarter is a good moment for a review. Instead of asking whether the project is “on plan”, look at indicators that measure capability, not just progress.
Time to add a new source or metric. How many days pass from request to a working metric in a report? It should shrink with each domain, because the shared dimensions already exist.
Share of changes made by your team. What percentage of commits to the repository in the last month came from your people? If it is zero after three months, knowledge transfer is not happening.
Test coverage. How many models have data quality tests, and how many tests failed last month? No failures with no tests is not good news.
Report usage. Who opens the reports from the first domain, and how often? BI tools measure this out of the box. A report nobody opens does not exist, however well it is built.
Reconciliation with the source. Do key totals in the warehouse match the source system within an agreed tolerance, and are discrepancies explained?
Platform cost per domain. Do you know what each data domain costs per month, and is that cost stable?
If the numbers look good after a quarter, carry on. If not, you have a concrete list to discuss with the vendor instead of a vague feeling that “something is off”. It is worth writing these indicators into the contract as part of reporting, so that the vendor collects the data from the start.
The quarterly review is also the moment to decide on the next engagement model. If the first domain is done and your team is increasingly comfortable making changes, there is often no point in keeping a full consulting team. Scale it down to one or two people supporting your team on further domains, or switch to occasional architecture reviews. A good vendor will propose this step itself. If it proposes growing the team instead, ask which of the indicators above justify it.
When is data warehouse consulting a bad idea?
The honest answer to “do I need a consultant?” is sometimes “not yet”. These are the situations in which an engagement is most likely to waste the budget.
Nobody on the business side owns the metrics. A consultant can propose definitions but cannot approve them. Without someone to settle definition disputes, the project will stall on the first domain.
The problem is data quality at source, not joining data. If sales reps do not enter the customer’s industry in the CRM, no warehouse will show revenue by industry. The data entry process has to change first.
The company expects a project with no team of its own at the end. If nobody will maintain the warehouse, you will build a system that starts breaking at the first ERP change. A continuous support model with a clear scope, or simpler tooling, is the better option then.
The goal is technology, not a decision. “We want a lakehouse” is not a business goal. “We want to know which customers are drifting away before they churn” is a goal from which a scope follows.
The warehouse is expected to settle a political dispute. If two departments calculate margin differently because each wants to look better, a warehouse will not change that. A board decision on one definition will, and the warehouse will then encode it.
In these situations it is better to commission a short assessment with a clear question: whether and when a warehouse makes sense. A good consultant should be able to say “not yet”. If none of the vendors you speak to ever says it, ask them which projects they have advised clients against.
How do you compare proposals that describe different services?
Back to the three proposals from the beginning of this article: a 12-week warehouse at a fixed price, day rates with no total, and a workshop with an assessment. To compare them, reduce them to a common denominator.
Break each proposal into the stages from the table above. Which part is assessment, which is design, which is build and which is handover? A fixed-price proposal often packs assessment and design into the first two weeks, far shorter than the typical range. Ask what the vendor assumes about your data in order to fit that timeline.
Check what the acceptance criterion is. Are you accepting working loads, or reports used by named people? Does acceptance include reconciliation with the source system? Does it include knowledge transfer?
Calculate total cost over two years. Add an estimate of platform, tooling and run costs to the consulting price. A proposal that is cheaper to build but assumes ongoing vendor support can be more expensive over a two-year horizon.
Assess who will do the work. Ask for profiles of individuals, not of the firm. In data projects the difference between a senior who has seen ten warehouses and someone on their first is larger than the difference in day rates.
Ask about the first step. The safest proposal is the one that lets you buy a small, closed stage first and decide on the next one based on its result. If a vendor refuses such a split, ask yourself why.
Finally, ask each vendor for one page answering a single question: what exactly will be working, and who will be able to change it when the contract ends. You can compare the answers in fifteen minutes, and they will tell you more than dozens of pages of proposals.
What are the key takeaways before choosing a data warehouse consultant?
Data warehouse consulting is not the purchase of a system. It is the purchase of decisions, code and skills that your company will maintain for years. That is why its value is measured not by what gets built, but by what your team can change once the consultant has left.
Remember six things. First, decide which service you are buying now: assessment, design, build, migration, optimisation or run. Second, require concrete outputs from every stage, including a bus matrix and data quality tests. Third, treat the platform choice as secondary and ask about the consultant’s commercial relationships with vendors. Fourth, buy the assessment at a fixed price and the build in domains with caps and acceptance criteria. Fifth, include platform cost and your own people’s time in the budget, and put cloud cost control into the consulting scope. Sixth, write knowledge transfer into the contract with a measurable criterion: your team adds a source and a metric on its own.
If you need a team of data engineers to build your first domain, or specialists to strengthen your data team for the duration of the rollout, see how we work in custom software development, or book a call. We start with a discovery phase that takes one to two weeks and ends with a scope, an architecture and an estimate you can take to the board.