The wall is almost always the data model
Most companies that ask whether they need a Dataverse consultant have already built something that works. Someone in operations made an app for tracking supplier claims, it got adopted without anyone deciding it should be, and four teams now depend on it. The question is whether the next step costs a week of somebody's time or three months of somebody else's invoice.
The wall those teams hit is rarely the tool. The wall is a data model designed by a person solving that week's problem, with no reason to think about next year's reporting. One table called Requests with forty columns, a choice column doing the work of a related table, and a text field holding supplier names that appear eleven different ways. It held for six months, and now every change breaks something else.
Before you call anyone, write down what is actually failing. 'Reports take an hour to build and nobody trusts them' points somewhere different from 'contractors can see records that are not theirs'. The first is a modelling problem, the second a security problem, and whoever is excellent at one is often ordinary at the other. If nobody on your side has read a plain description of what Dataverse actually is, start there.
Sometimes a week of training is the cheaper fix
Two of the last five times someone asked me to quote for Dataverse work, I told them not to hire anybody. One team had a capable maker who had never been taught relationships and lookups properly. Four days of training and an afternoon of pair work on their own tables got them further than a fixed-price build would have, and they kept the knowledge.
The second was licensing. The team thought they had hit a platform limit. They had hit the boundary of what their seeded Power Apps entitlement allowed for premium connectors, and the fix was a purchasing conversation with their Microsoft account team plus a change of environment. Anyone who answers that description with a proposal for a data migration is selling you work you do not need.
Storage panic is the third. A team reads a capacity warning, assumes the design is wrong, and plans a rebuild when the real answer is an audit log retention setting and a few attachment columns pointed somewhere cheaper. Read what actually consumes Dataverse capacity before you accept that your model is at fault.
Signals that genuinely justify paying someone
Restructuring a live data model after the fact is the clearest signal. Splitting that forty-column table into supplier, claim and claim line, keeping every record intact, and updating each app, flow and report that touches them has a real failure mode. Doing it while fourteen branches keep working is harder again.
Security is the second. When compliance says a regional manager sees only their region, contractors see only rows they created, and a shared services team sees everything except salary columns, somebody has to map that onto business units, teams, security roles and row ownership. Get it wrong and you either leak data or spend a year hand-managing sharing. Few organisations have anybody in house who has done this at scale.
Integration to a system of record is the third. Pulling supplier master data from an ERP into Dataverse looks simple until you decide what happens when the ERP record is deleted, how you reconcile after an outage, and which system wins on conflict. Connectors and integrations differ in exactly the places that wake somebody at 2am.
Performance and lifecycle finish the list. Tables that behaved at nine thousand rows behave differently at two million, and the fix sits in indexes, view filters and how the app queries. If your production app is being edited in production, your first real release will hurt, and an environment strategy people can follow is worth buying when nobody in house has built one.
The engagement that taught me to buy discovery first
A distribution company brought me in two years ago to quote for what they called a straightforward rebuild. Their returns process ran on a Power Apps app over five Dataverse tables, built by a warehouse supervisor who had since been promoted. Fourteen branches used it, and they wanted it rebuilt in eight weeks.
I asked for ten days of paid discovery first. They pushed back, fairly, since discovery shows up on an invoice with nothing shipped against it. Those ten days found that two of the five tables held the same supplier data with different spellings, that one branch recorded return reasons in a private code nobody else understood, and that the finance report everyone relied on was a spreadsheet somebody reconciled by hand every Friday.
None of that was in the brief. An eight-week rebuild against the original brief would have produced a tidy app and numbers finance could not reconcile, and the argument about whose fault that was would have outlasted the build. The real work came in at fourteen weeks and cost more than their number. They still call the discovery the cheapest decision they made.
What a statement of work has to specify
A statement of work that says 'redesign the Dataverse data model and migrate existing data' gives you nothing to hold anyone to. Name the tables. Name the apps and flows that must still work on the morning after cutover. Say who writes the migration scripts, who validates the results, and what validated means in numbers, such as row counts matching and twelve named reports producing identical figures before and after.
Say who owns the environments and who holds the rights to deploy. Say what happens to the solution when the engagement ends and whether your team can change it without calling anyone back. Say how many days of handover are included and what the handover produces, because knowledge transfer with no deliverable attached means somebody reads a slide deck to your admin on the last afternoon.
Write acceptance in language a business user can check. The finance manager produces the Friday reconciliation without a spreadsheet. A contractor signing in sees only their own claims. Improved data quality is not testable, and you will lose that argument in the closing meeting. Fixed price suits work whose shape you already know, which means the work after discovery. For larger moves, how to scope a statement of work covers the same ground in more detail.
The questions that tell you who you are hiring
In a first meeting, a consultant worth paying spends most of the hour asking about your business rather than your platform. What does a claim represent? Who decides it is closed? What happens when one supplier buys another? Who gets the phone call when the number in the report is wrong? Those questions are about the thing the data describes, and the answers determine the model.
The warning sign runs the other way. Somebody who arrives with an architecture before asking what your data represents is selling a template, and in a room where nobody else knows the platform that will sound reassuring. Ask what they would need to know before committing to that design. A good answer names your tables and your volumes. A poor one repeats the benefits of the design they already drew.
Two more checks. If the person on the sales call is not the person who will do the work, ask to meet whoever will and what else they are staffed on that month. And if nobody asks to see your environments or how you deploy a change today, they are planning to build in production. A discovery workshop that surfaces real requirements is a working session, and you should expect homework.
Before the brief goes anywhere, spend an afternoon writing down the ten questions your business cannot answer from this app today. Take that list into the first meeting instead of your requirements document. If the person across the table starts pulling at those questions rather than answering them, you have probably found the right one.
