--- title: "Data Warehouse Consulting: What You Get and When You Need It" description: "What data warehouse consulting should leave behind: platform fit, modelling, a semantic layer with owners, and the questions to ask before you hire." canonical: https://shipshapedata.com/resources/data-architecture/data-warehouse-consulting/ language: en-GB author: "Emile Van Zyl" author_role: "MarTech Automation Consultant" author_url: https://www.linkedin.com/in/emile-vanzyl-enhancing-your-human-advantage/ date_published: 2026-10-28 date_modified: 2026-10-28 --- # Data warehouse consulting: what you get and when you need it > What data warehouse consulting should leave behind: platform fit, modelling, a semantic layer with owners, and the questions to ask before you hire. Section: Home > Resources > Data & architecture Canonical page: https://shipshapedata.com/resources/data-architecture/data-warehouse-consulting/ By Emile Van Zyl, MarTech Automation Consultant (https://www.linkedin.com/in/emile-vanzyl-enhancing-your-human-advantage/) | published 2026-10-28 Most organisations that look for data warehouse consultants already have plenty of data. It sits in a finance system, a CRM, an ERP and a set of spreadsheets that do not agree with each other. Reports take days to assemble, and meetings start with an argument about which number is correct. A warehouse is meant to fix that, but only if the engagement that builds it leaves something your teams can understand and run. Data warehouse consulting is specialist help to design, build and hand over a central store for reporting and analysis. A good engagement covers platform choice, ingestion, modelling, a semantic layer, testing and documentation. It should leave you with a modelled, documented warehouse on the right platform, with named owners for each dataset, and not a set of pipelines. This guide is for the person who has been asked to sort out reporting, or to get the organisation's data ready for AI, and needs to decide whether to bring in outside help. It explains what the work covers, how to choose a platform by fit, how the warehouse should be modelled, why the semantic layer matters most, and which questions to ask before you sign. If you want the basics of the technology first, our guide to how data warehousing works covers them. ## What data warehouse consulting covers A data warehouse pulls data from several operational systems into one store built for reporting and analysis rather than day-to-day transactions. Consulting is the work of designing that store, building it and handing it over in a state your own people can run. The work usually falls into six parts. - Assessment: an inventory of source systems, current reports, data quality problems and the decisions the business needs to make. - Platform choice: selecting a cloud warehouse that fits your existing estate, skills and workloads. - Ingestion: moving data from source systems into the warehouse on a schedule, with checks that each load completed. - Modelling: shaping raw data into tables that represent the business, such as orders, customers and products. - Semantic layer: one agreed definition of each metric, such as revenue or active customer, used by every report and tool. - Governance and handover: access controls, documentation, data owners and a runbook for when things fail. Many engagements also include a move from an older warehouse or an on-premises database. That work has its own discipline: mapping, reconciliation and a planned cutover. Our data migration framework sets out the stages. What separates a useful engagement from an expensive one is the end state. Pipelines alone do not give you a warehouse. A warehouse is useful when the tables are modelled, the metrics are defined once, every dataset has an owner, and someone other than the consultant can explain how a figure was calculated. > A warehouse that only the consultant can explain is a liability, not an asset. ## Signs you need a data warehouse consultant Not every organisation needs outside help. A team with warehouse experience and time to spare can build one. The signs below suggest that bringing in data warehouse consultants is worth the cost. - Different teams report different figures for the same metric, and nobody can say which is right. - Monthly reporting depends on one person exporting data into spreadsheets by hand. - You run several source systems, such as an ERP, a CRM and a billing platform, that do not share keys. - An AI pilot stalled because the data underneath it was incomplete, inconsistent or hard to reach. - An older warehouse or on-premises database is reaching end of life and needs to move to the cloud. - Your team can build pipelines but has not designed a dimensional model or a semantic layer before. The fourth sign deserves attention. AI amplifies whatever it sits on. A model or assistant built over inconsistent data will give inconsistent answers with confidence. Our guide to what AI-ready data means explains how a warehouse becomes the base for AI work rather than a separate reporting exercise. There are also good reasons not to hire. If your data volumes are small, your sources are few and a well-kept reporting tool already answers your questions, a warehouse may add cost without adding value. A good consultant will tell you that, and so will we. ## Choosing a platform: fit, not fashion The four cloud platforms most organisations shortlist are Snowflake, Databricks, Google BigQuery and Microsoft Fabric. Each can run a serious warehouse. The right choice depends on the cloud you already use, the skills in your team, the mix of workloads you expect and how you want to pay for compute. ### Snowflake Snowflake separates storage from compute, so different teams can run workloads without competing for resources. It runs on more than one cloud provider. It suits organisations whose main need is SQL analytics and sharing data across teams or with partners. ### Databricks Databricks grew from data engineering and machine learning, and it stores data in open table formats on your own cloud storage. It suits teams with strong engineering skills, large volumes of semi-structured data, or plans for data science on the same platform. This is the lakehouse pattern, and our comparison of a data lakehouse and a data warehouse explains the difference. ### Google BigQuery BigQuery is a serverless warehouse on Google Cloud. There is little infrastructure to manage, which suits small teams and organisations already using Google Cloud services, Google Analytics or Looker. ### Microsoft Fabric Fabric brings storage, engineering, warehousing and Power BI into one Microsoft service. It suits organisations whose estate is already Azure, Microsoft 365 and Power BI, where sign-on, licensing and existing skills carry over. Our Fabric and Snowflake fit comparison works through twelve criteria for that decision. A consultant who recommends the same platform for every client is selling a platform, not advice. Ask for the reasoning in writing, including what would change the recommendation. If you are still deciding whether you need a warehouse or a lake at all, start with our guide to data lakes and data warehouses. ## Modelling and the medallion layers Modelling is where most of the value in a warehouse is created, and it is the part most often rushed. Loading raw tables into a cloud platform is quick. Turning them into a structure the business can query safely takes judgement. ### Bronze, silver and gold We build warehouses using medallion architecture, which cleans data in three stages. - Bronze holds raw data as it arrived from each source, unchanged, so you can always trace back and reload. - Silver holds cleaned and conformed data: duplicates removed, types corrected and keys matched across systems. - Gold holds business-ready tables, modelled around the processes people report on, such as sales, stock or support tickets. The layers make problems easier to find. If a gold figure looks wrong, you can check silver and then bronze and see where it changed. ### Dimensional modelling in the gold layer The gold layer usually follows a dimensional design, with fact tables that hold measurable events and dimension tables that describe them. The choice between a star and a snowflake design affects query speed, storage and how easy the model is to understand. Our guide to star schema and snowflake schema covers the trade-offs. Whichever pattern is used, ask the consultant to document the reasons, table by table. ## The semantic layer is the deliverable A semantic layer sits between the modelled tables and the tools that use them. It holds one governed definition of each business term: what counts as revenue, how a churned customer is defined, which date a month-end figure uses. Every dashboard, spreadsheet and AI assistant then draws on the same definitions. Without it, definitions are written separately in each report. Two analysts building the same metric in two tools will make different choices, and the warehouse will produce the same arguments it was meant to end. With it, a change to a definition is made once and every consumer picks it up. The semantic layer also matters for AI. A language model asked a question about your data needs to know what the business terms mean and which tables it may use. Governed definitions and access rules give it that. They are what let an assistant give an answer you can audit, rather than a plausible guess. > One governed definition of your business is the part of the warehouse that lasts. For this reason we treat the semantic layer, with a named owner for each definition, as the main deliverable of a warehouse engagement. A data dictionary sits alongside it, so people can look up what each field means without asking the data team. ## What drives the effort and cost The cost of a warehouse engagement depends on a small number of factors. Knowing them helps you compare proposals and see where scope can be reduced. - The number of source systems, and whether they have usable APIs or need custom extraction. - The quality of the source data, since cleaning and matching records takes longer than moving them. - The number of business processes to model and metrics to define. - Whether existing reports must be rebuilt or reconciled against an older system. - Governance needs, such as row-level security, audit requirements or regulated personal data. - Platform running costs, which depend on data volume, query load and how compute is scheduled. The time a build takes depends on the same factors. A sensible engagement starts with one business area, delivers a working gold layer and semantic layer for it, and proves the approach before widening scope. A first win that pays for the second is a better plan than a programme that tries to model everything at once. ## What to expect after go-live A warehouse is not finished at go-live. Source systems change their schemas, new reports are requested and data volumes grow. The handover decides whether your team can absorb that change or must call the consultant back for every adjustment. By go-live you should have the following in place. - Documentation for every pipeline, model and metric, kept in the same repository as the code. - Automated tests on key tables, with alerts that reach a named person when a load fails or a figure moves outside expected limits. - A named owner for each dataset and each definition in the semantic layer. - Access controls that match who should see what, reviewed with your security lead. - A runbook for common failures, and a period of support while your team learns to run the system. We stay past go-live as part of the engagement, because the first weeks of real use are when gaps in definitions and tests appear. Support should taper as your team takes ownership. It should not continue because nobody else understands the system. ## Questions to ask data warehouse consultants These questions test whether a consultant will leave you with a working asset or a dependency. - Which platform do you recommend for us, and what would change that recommendation? - How will you model our data, and how will you document the reasons for each design choice? - Where will business definitions live, and who will own them after you leave? - How will you test that figures in the new warehouse match the ones we trust today? - What does the handover include, and how long do you support us after go-live? - Which part of the scope would you cut first if the budget were smaller? - Have you advised a client not to build something, and why? The last question is worth asking. A consultant who has never advised against a build is unlikely to tell you when your data is not ready. For the adjacent decisions about outside help, our guide to data engineering consulting services covers pipeline work, infrastructure and governance. ## Where this leaves you Data warehouse consulting is worth paying for when it leaves you with more than pipelines. The test is clear: a modelled warehouse on a platform that fits your estate, one governed definition of each business term, a named owner for each dataset, and documentation your team can work from without the consultant in the room. Start with the decisions the business needs to make, choose the platform by fit, model in stages and treat the semantic layer as the main deliverable. Scope one business area first and prove it before widening. If your data is not ready for the work you have planned, the right advice may be to fix the foundation before building anything on top. Our data foundation service builds this from start to finish: a cloud data warehouse on Snowflake, Databricks, BigQuery or Fabric, medallion architecture from bronze to gold, and a governed semantic layer with owners. If you are moving off an older warehouse, our data migration service reconciles row by row and supports you past cutover. If you are not ready for a conversation, the AI readiness assessment scores your position on the spot with no email gate. Talk to us for a personal reply, usually within one working day, and a straight answer on whether we are the right fit. ## Frequently asked questions Data warehouse consultants design, build and hand over a central store for reporting and analysis. The work covers an assessment of source systems and reports, platform choice, ingestion pipelines, modelling in bronze, silver and gold layers, a semantic layer with one definition per business term, testing, access controls and documentation. A good engagement ends with named owners for each dataset and a team that can run the warehouse without the consultant. Hire one when teams report different figures for the same metric, when monthly reporting depends on manual spreadsheet work, when several source systems do not share keys, when an AI pilot stalled on poor data, or when an older warehouse needs to move to the cloud. If your data is small and a reporting tool already answers your questions, a warehouse may not be worth the cost yet. It should leave a modelled warehouse on a platform that fits your estate, a semantic layer with one governed definition of each business term, a named owner for each dataset and definition, documentation for every pipeline and model, automated tests with alerts, access controls and a runbook. Support should continue for a period after go-live and taper as your team takes ownership. Choose by fit. Snowflake suits SQL analytics and data sharing, and runs on more than one cloud. Databricks suits engineering-heavy teams, semi-structured data and machine learning on open table formats. Google BigQuery suits small teams already on Google Cloud who want little infrastructure to manage. Microsoft Fabric suits organisations already using Azure, Microsoft 365 and Power BI. Ask any consultant to explain the recommendation in writing and what would change it. The cost depends on the number of source systems, the quality of the source data, the number of processes and metrics to model, whether existing reports must be rebuilt or reconciled, governance needs such as row-level security, and platform running costs driven by data volume and query load. Starting with one business area keeps the first phase bounded and shows where further spend is worth it. A data warehouse pulls data from operational systems such as finance, CRM and ERP into one store built for reporting and analysis. It cleans and models the data so figures agree across teams, keeps history for trend analysis, and gives dashboards, analysts and AI tools a single governed source to query rather than each system separately. ## Frequently asked questions ### What do data warehouse consultants do? Data warehouse consultants design, build and hand over a central store for reporting and analysis. The work covers an assessment of source systems and reports, platform choice, ingestion pipelines, modelling in bronze, silver and gold layers, a semantic layer with one definition per business term, testing, access controls and documentation. A good engagement ends with named owners for each dataset and a team that can run the warehouse without the consultant. ### When should I hire a data warehouse consultant? Hire one when teams report different figures for the same metric, when monthly reporting depends on manual spreadsheet work, when several source systems do not share keys, when an AI pilot stalled on poor data, or when an older warehouse needs to move to the cloud. If your data is small and a reporting tool already answers your questions, a warehouse may not be worth the cost yet. ### What should data warehouse consulting leave you with? It should leave a modelled warehouse on a platform that fits your estate, a semantic layer with one governed definition of each business term, a named owner for each dataset and definition, documentation for every pipeline and model, automated tests with alerts, access controls and a runbook. Support should continue for a period after go-live and taper as your team takes ownership. ### Which data warehouse platform should I choose? Choose by fit. Snowflake suits SQL analytics and data sharing, and runs on more than one cloud. Databricks suits engineering-heavy teams, semi-structured data and machine learning on open table formats. Google BigQuery suits small teams already on Google Cloud who want little infrastructure to manage. Microsoft Fabric suits organisations already using Azure, Microsoft 365 and Power BI. Ask any consultant to explain the recommendation in writing and what would change it. ### How much does a data warehouse cost? The cost depends on the number of source systems, the quality of the source data, the number of processes and metrics to model, whether existing reports must be rebuilt or reconciled, governance needs such as row-level security, and platform running costs driven by data volume and query load. Starting with one business area keeps the first phase bounded and shows where further spend is worth it. ### What does a data warehouse do? A data warehouse pulls data from operational systems such as finance, CRM and ERP into one store built for reporting and analysis. It cleans and models the data so figures agree across teams, keeps history for trend analysis, and gives dashboards, analysts and AI tools a single governed source to query rather than each system separately. --- Shipshape Data is a London AI consultancy: we build the data foundation your AI depends on, then the AI on top. Site guide for agents: https://shipshapedata.com/llms.txt | Contact: hello@shipshapedata.com