Buyer's checklist

Before you spend a dollar on fixing your data

You're about to evaluate consultants, platforms, or services to fix your data. The quotes are big and the claims all sound similar. This is a short, practical guide to telling a real fix from an expensive disappointment, written from the buyer's side of the table, not the seller's.

The single question underneath all of it: after the money is spent, who is left holding the complexity? If the answer is "you," you've bought a dependency, not a solution. Everything below is a way to find that out before you sign.

Five questions to ask any vendor

Ask these directly. How they answer tells you more than their pitch deck.

1. "After this is built, who runs it day to day?"

If the answer is "you do" or "your team does," and you don't have a data team, you're about to inherit something you can't operate. Listen for whether they keep running it or hand it over and leave.

2. "What happens when one of my source systems changes its export or adds a field?"

Your systems will change. If the answer is hand-wavy, or "we'd scope a change request," you've found the thing that will break in six months and cost you every time. A real answer describes how change is handled as a matter of course, not as a new project.

3. "Do I have to clean up or migrate my data before we start?"

If yes, you're signing up for a rip-and-replace project on top of the fix; more cost, more risk, more time before any value. The better answer is that they take your data as it is, mess and all, and resolve it on the way in.

4. "When two systems disagree about the same customer, who decides which is right, and can I see why?"

This is the heart of the actual work. If they can't explain how conflicts get resolved and how you'd audit that decision, they're moving your data, not governing it. "It just merges them" is a confident-looking wrong answer; that's how two different people get fused into one record.

5. "If I leave, what do I walk away with?"

This is the question that separates a service from a trap, and almost nobody asks it. The answer you want: "all of your data as it came in, with its full history, plus the reporting built on it, in a format you can actually use." The answer that should worry you: anything where leaving means losing your data, or getting it back in a form you can't use. Depending on a vendor is fine. Being unable to leave one is not.

Red flags that a fix will leave you holding the bag

The price is mostly one big one-time number. One-time pricing usually means one-time involvement. The complexity outlives the engagement; the support doesn't. A setup fee alongside an ongoing one is a different animal; what matters is whether most of the money buys work that ends.
"Migration" or "implementation" is a major line item. That's the rip-and-replace project disguised as setup. The tell is whether you're asked to change or clean your systems before you see any value; connecting what you already run, as it is, is a different job.
They demo a dashboard before they explain how the data underneath gets trustworthy. A pretty dashboard on top of unresolved data just makes a wrong number look confident.
They can't tell you how the same customer across four systems becomes one record. That collapse, many messy records into one trustworthy entity, is the job. If it's vague, they haven't solved it.
You can't get a straight answer about leaving. If "what do I walk away with" produces a pause, assume the answer is "not much," and assume that's by design.
Everything depends on the specific people in the room. If the knowledge lives in their consultants' heads, it leaves when they do.

Green flags that you're looking at a real fix

They take your data as-is: no pre-cleanup, no migration project.
They can clearly explain how conflicts get resolved and how you'd audit a decision.
They stay responsible for keeping it running, not just standing it up.
Pricing is predictable and ongoing; you're paying for a result that's maintained, not a project that ends.
Source-system changes are handled as routine, not billed as surprises.
Your data stays yours: you can take all of it, with history, any time, in a usable format.

A strong consultant or a well-run platform will hit some of these too; that's a good sign, not a catch. The difference is whether they're all still true in month twelve, when the consultant has moved on and the platform still needs someone to run it.

When a managed service is the wrong answer

In the interest of an honest checklist: a managed service isn't always the right call, and any vendor who won't tell you that is selling, not advising.

You already have a capable data team and the appetite to own your infrastructure. Then a platform you run yourself may be the better long-term economics. Buy the engine; you have the driver.
You have a single, bounded, one-time job: a migration, a cleanup, a specific build with a clear end and no ongoing need. Then a good consultant is the cleaner path. Don't sign up for a monthly relationship to solve a one-time problem.
Your data genuinely doesn't change and isn't fragmented. If you have one clean source and one question, you may not need any of this. Don't buy infrastructure for a problem you don't have.

A managed service earns its keep when the mess is ongoing, the sources keep changing, and you don't want to hire a team to wrestle it. If that's not you, the honest answer is one of the other paths.

The one-line test

Picture yourself twelve months from now. Is the data still trustworthy without you having become its caretaker?

If yes: you found a real fix.
If you'd be the one keeping it alive: you found another expense.

That's the whole decision. Everything else is detail.

The longer read

You don't have a data problem. You have a data-is-everywhere problem.

One customer, five records, four systems that don't talk. What the mess really is and what "fixed" looks like.