Your data pilot is not temporary

A request landed with me recently, forwarded by an account team on behalf of a business unit. Paraphrasing: we’re starting a BigQuery evaluation, could you create a project and grant the team Editor rights? It’s just a PoC.

I’ve had some version of this conversation a dozen times, and the interesting part is never the access request. It’s the word temporary. That word is carrying an enormous amount of weight, and in my experience it cannot support it.

The project that never dies

The proposal is always reasonable on its face. A pilot is small and short-lived, so it shouldn’t need the full onboarding path: the design review, the security sign-off, the classification exercise. Give it a lightweight project, let the team learn something, and if it works out, migrate it into the proper estate.

I’ve never once seen that migration happen.

The reason is structural rather than cultural. The migration is scheduled for the moment the pilot succeeds, which is exactly the moment the team has a working thing and a stakeholder asking when it goes live. Nobody funds a project whose entire deliverable is “the same capability, in a different place.” So the pilot stays where it is, and a project built with pilot-grade controls quietly becomes a production dependency.

Pilots acquire real data

There’s a second failure that’s less obvious. Pilots start with sample files, and within weeks they’re loading something from a source system, because that’s the only way to learn anything useful.

If your temporary tier has relaxed controls, you have built the one place in the estate where classification is undeclared and controls are weakest. And then real data flows into it.

Promotion, not migration

So we wrote the opposite rule: a pilot touching company data is a workload. It gets its own project in the development environment, with the same controls it would get in production, from day one.

The pushback is fair. That’s more process for something that might be thrown away in six weeks. The answer I’d give is that a pilot which succeeds becomes production by promotion rather than by migration. It was never in the wrong place. You pay one onboarding cycle up front instead of an unfunded migration later.

If that trade doesn’t feel worth it, the honest fix isn’t a temporary tier. It’s making onboarding cheaper for low-classification work.

The same logic covers every irreversible decision at intake: location, jurisdiction, classification, project boundary. Make them where they’re cheap, and be suspicious of any design whose viability depends on a future migration. That migration is competing for funding against features, and it will lose.

The word temporary, in an enterprise data platform, usually means permanent, but without the controls.