What shapes the investment
Consolidation against another lift and shift
Is data warehouse consulting the right fit?
Start here when
Consider another path when
Most companies do not need a new warehouse. They need the three or four they already have to become one, with a model the business recognises and a cutover nobody notices. We design the model, build or consolidate the warehouse, and migrate onto it in parallel so the old system is only switched off once the new one has been proved against it.
Data warehouse consultants who design the model, consolidate the warehouses you already run, and migrate in parallel so nothing is switched off before it is proved.
Data warehouse consulting is the work of designing, building, consolidating or modernising the central store that reporting and analytics read from: the data model, the load and history strategy, the access and cost controls, and the migration path off whatever is there now.
Data warehouse consulting designs and builds the central store that reporting reads from, including the data model and the migration onto it. Thinklytics works most often on consolidation, turning several inherited warehouses into one, and migrates in parallel so each old system is retired only after the new one has been reconciled against it.
A data model the business can read: conformed dimensions, agreed grain, and history handled on purpose rather than by accident.
Consolidation of the warehouses you inherited through acquisitions or reorganisations, into one store or one federated model with clear ownership.
Migration in parallel. The old warehouse keeps running until the new one reconciles against it, so a cutover is a decision and not a gamble.
Load, history and retention strategy, so the warehouse answers questions about last year without carrying the cost of keeping everything hot.
Access and cost controls set before the bill grows, with the query patterns that drive spend made visible.
A platform sales pitch. Which warehouse to buy is a separate question, and the Data Warehouse Selection tool answers it without us in the room.
A rebuild for its own sake. If the warehouse you have is sound, the work is the model and the loads on top of it.
A lift and shift. Moving a broken model to a faster engine buys you the same disagreements at a higher monthly cost.
Current state model and cost read. What each warehouse holds, which reports depend on it, where the definitions conflict, and what it costs to run.
Target data model with conformed dimensions and an agreed grain, reviewed with the people who will defend the numbers.
Built warehouse or consolidated target, on the platform you already run, with loads, history and retention implemented.
Parallel run and reconciliation against the system being replaced, with the checks written down and repeatable.
Cutover plan and handover: ownership, runbooks, access model, and the cost controls left in place.
Two warehouses answer the same question differently and both are defended.
Each was built for one team's reporting with its own grain and its own dimension logic, so neither is wrong on its own terms and no conformed model exists above them.
The warehouse bill grows every quarter and nobody can attribute it.
Storage keeps everything hot because no retention tier was ever set, and the heaviest query patterns are invisible, so cost is managed by asking people to be careful.
A migration has stalled twice and the old system is still running.
The cutover was planned as a single switch with no parallel reconciliation, so there was never a point at which the business could prove the new numbers and agree to retire the old ones.
Reports about last year are slower than reports about last week, or impossible.
History was handled as overwrite rather than as versioned dimensions, so prior period states were not kept and point in time questions cannot be answered.
Every acquisition adds another warehouse and another set of definitions.
There is no target model to land an acquired estate into, so integration becomes a new silo each time rather than a mapping exercise.
They decide what the warehouse should hold and how it should be shaped, then get you onto it. In practice that is the data model, conformed dimensions and agreed grain, the load and history strategy, retention and cost controls, and the migration path off the systems you are running now. On most engagements the hardest part is not the build, it is agreeing one definition where two warehouses currently disagree.
Do we need a new data warehouse, or can we fix the one we have?
Usually you can fix it. A warehouse that is slow or distrusted is more often a modelling and loading problem than a platform problem, and replacing the engine carries the same model onto a bigger bill. The cases where a new or consolidated target is the right answer are when you are running several inherited warehouses with conflicting definitions, or when the current platform cannot support the history and concurrency you now need.
Data engineering is the movement: ingestion, transformation, orchestration and the alerting that proves a load ran. This is the destination: what the warehouse holds, how it is modelled, how history and retention work, and how you get onto it from what you have. The two meet, and on a consolidation they are usually one programme, but the questions are different.
We do not lead with one. The selection question depends on your existing contracts, the skills in your team, concurrency and history requirements, and what the cost curve looks like at your actual query volume. The Data Warehouse Selection tool on this site walks that decision without us involved, and we build on the platform you already run unless there is a reason not to.
In parallel. The system being replaced keeps running while the new warehouse is loaded alongside it, and the two are reconciled against each other until the business is prepared to defend the new numbers. Each old system is retired only after that, one at a time rather than together. It takes longer than a single cutover and it is the reason a cutover becomes a decision instead of a risk.
Can you consolidate warehouses without taking ownership away from the teams that built them?
Yes, and on a large estate that is often what makes consolidation possible at all. A federated model gives you conformed dimensions and cross unit reporting above warehouses that each unit continues to own. That is what the Rackspace work did across 14 business units. Centralising everything into one team is a different trade and not always the right one.
The number of source warehouses and how differently they define the same entities, how much history has to be reconstructed rather than carried over, whether the business can commit people to agree definitions, and the length of the parallel run. Platform licensing is rarely the driver. Definitional disagreement usually is.
Two is a mapping exercise. Nine or fourteen is a programme, because every pair of definitions has to be reconciled with someone who owns it.
The cost is in how differently the sources describe the same customer, product or period, not in the volume of rows.
Carrying history over is cheap. Rebuilding prior period states that were overwritten is not.
A longer overlap costs more to run and removes most of the risk. It is the main lever you control.
Definitions get agreed by the people who defend the numbers. If they cannot meet, the programme waits.
No prices here. Scope is set after the current state read, because the number of conflicting definitions is what actually sizes the work.
Moving a warehouse to a new engine and consolidating several into one look similar on a plan and behave nothing alike.
The model, the definitions and the ownership, with the platform chosen to suit them.
The platform. The model and the disagreements travel with you.
Parallel run with reconciliation, one system retired at a time.
A dated switch, with rollback as the only plan if the numbers differ.
Retention tiers and query patterns addressed as part of the build.
Often higher, because the same workload runs on a faster engine.
You are running more than one warehouse and they disagree about the same numbers.
An acquisition or reorganisation left you with an estate nobody designed.
A migration has stalled and the system it was meant to replace is still running.
The warehouse bill is rising and nobody can say which workloads drive it.
You cannot answer point in time questions because history was overwritten.
You are choosing a platform and have not started: use the Data Warehouse Selection tool.
The warehouse is sound and the loads are the problem: see Data Engineering Consulting.
The model is fine and the argument is what a metric means: see Semantic Layer Engineering.
11 to 1: Campus data warehouses consolidated into one, with cross-campus report time cut from 5 days to 2 hours and $2.3M a year in infrastructure saved. (Texas A&M University System)
$4.7M to $1.1M: Annual infrastructure cost after 14 business unit warehouses moved to a federated model that kept each unit's ownership intact. (Rackspace Technology)
18 days to 3 days: Monthly close cycle after nine inherited reporting systems were consolidated onto one platform, saving $3.1M a year. (Lumen Technologies Division)