Companies that go looking for data infrastructure consulting usually describe the problem as a tooling problem. The warehouse is slow, the dashboards disagree, the pipelines break on the first of the month, and somebody has proposed moving everything to a new platform. The search is for a firm that can pick the right stack and build it.
Sometimes that is exactly the job. More often the stack is the visible symptom of decisions that were never made: what the data is for, how fresh it has to be, who owns it when it breaks, and what it is allowed to cost. A new platform built on top of those open questions inherits them. Below is what the consulting work covers in practice, the 4 decisions it should settle before anyone writes a pipeline, and how to tell advice from a platform sale.
Infrastructure is a set of commitments, not a set of tools
Every data platform is a bundle of commitments that are cheap to make and expensive to unmake. Where the data lives. Which format it is stored in. Which team is paged when a load fails at two in the morning. How the bill grows when usage grows. The tools are interchangeable to a degree that vendors rarely advertise; the commitments are not.
That is why the useful first question in an engagement is not "which platform" but "which of these commitments are we about to make, and do we know we are making them?" A team that can answer that question can usually choose a platform in an afternoon. A team that cannot will spend months comparing feature matrices and still be surprised a year later.
The 4 decisions to settle before anything is built
1. What the data has to do. Reporting for the leadership team, an operational system that other software reads from, and a feeding ground for AI models are three different jobs with three different shapes. Reporting tolerates yesterday's numbers and needs consistent definitions. Operational use needs reliability and fast reads, and an outage is a business outage. AI use needs history, labels, and a clear record of where each field came from. A platform designed for one of these and then stretched to the others is the most common source of the "slow, inconsistent, fragile" complaint. Writing the jobs down, in priority order, is the first deliverable.
2. How fresh it has to be, and for whom. Real-time pipelines are more expensive to build, more expensive to run, and harder to debug than daily batch loads. They are worth it where a decision genuinely changes in minutes: fraud checks, inventory, routing. They are rarely worth it for a weekly business review. The honest version of this decision is a short list of use cases with a stated freshness requirement next to each, signed by the people who own those use cases, so the architecture is built to the strictest real requirement rather than the most ambitious one mentioned in a meeting.
3. Who owns it when it breaks. Data infrastructure fails at the seams: a source system changes a field, a vendor's export arrives late, a definition drifts between two teams. Each seam needs a named owner, a check that notices the failure before a dashboard does, and an agreed response. Platforms do not supply this. An organisation either designs it or discovers its absence during a board-meeting week. This is also where data governance stops being a policy document and becomes a working practice, which is the territory of data strategy consulting.
4. What it is allowed to cost, and how the bill behaves. Most modern data platforms charge by consumption: storage, compute, and the queries people run. That pricing is flexible and fair, and it means the bill follows behaviour rather than a contract. A single badly written scheduled query, run every hour, can quietly become one of the larger lines on the bill. The decision here is not a budget number. It is a cost model: which workloads are expected to grow, who can see spend as it happens, and what triggers a review. Infrastructure companies themselves treat consumption pricing as a strategic lever, as covered on the cloud and data infrastructure page; buyers should treat it with the same seriousness from the other side of the invoice.
Migration is a sequence, not an event
When the decisions above point to a new platform, the move itself is where most of the risk sits. A migration planned as one cut-over weekend tends to become a long period of running two systems, reconciling numbers that do not match, and losing trust in both.
A sounder plan moves one job at a time, in the order the business can tolerate, and retires the old path for that job before starting the next. Each step has a reconciliation check agreed in advance: what has to match between old and new, to what tolerance, before the old one is switched off. The sequence is a business decision as much as a technical one, because it determines which teams live with disruption first. Where the platform choice is still open, the reasoning in build vs. buy your data strategy applies directly.
Portability: decide how you would leave before you arrive
The question vendors least like hearing is the one that protects the buyer most: if this platform stops being the right one, how do we get out? The answer depends on choices made early. Open storage formats, transformation logic kept in version control rather than inside a proprietary interface, and an inventory of every place the platform's own features have been used are what make leaving a project rather than a rewrite.
Few companies adopt a platform planning to leave it. The point of the exercise is that a credible exit keeps the commercial relationship honest at every renewal.
Consultant or implementation partner: 3 questions
Much of the market sells data infrastructure as an implementation of one platform. That is legitimate work, and sometimes it is precisely what a company needs. It is a different service from independent advice, and the difference shows up in what gets recommended.
- Do you earn anything from the platform you are recommending? Partner tiers, referral fees, and resale margins are common and not improper, but they should be disclosed before the recommendation, not discovered after it.
- What would you leave out of the first phase, and why? A firm that can name what it would deliberately not build yet has thought about sequence. A firm that proposes everything at once is quoting a project, not advising on one.
- How would we leave your recommended platform if we had to? If the answer is vague, the portability question has not been considered, and it will cost more to consider later.
Where this fits
The boundary on our side is deliberate. We shape the decisions above (what the data is for, freshness, ownership, cost model, migration order, and exit) and work alongside your engineers or implementation partners on the build rather than replacing them. Deciding what the data should settle for the business is data strategy consulting; choosing and integrating the systems underneath is IT and software consulting; and where the infrastructure exists to feed AI into everyday work, the sequence that build runs in is set out on how it works and in AI implementation consulting. For the question of what a broader data engagement includes, see data strategy consulting: what it covers.
If a platform change is on the table and the 4 decisions above have not been written down, that is the place to start. Start that conversation here. If the honest answer is that the current platform is fine and the problem is ownership, that is what you will hear.