The Field Promotion
Your "data person" is about to cost you a fortune in the cloud. It isn't their fault. It's yours.
I can tell you what I’m going to find before I open the server.
I do architecture and data engineering audits for a living, and the pattern is so consistent it’s almost a ritual. One server. One database. Every single table lumped into dbo. Some tables prefixed with staging_. Some that should be, but aren’t. Views with a vw bolted on, built visually in a designer, never optimized. Left joins everywhere, left joins to subqueries joined to other subqueries, with LEFT(), RIGHT(), and SUBSTRING() functions sitting inside the join criteria just to get two systems’ keys to match.
No CTEs. No separation between raw, cleansed, and business-ready data. No materialized views. No caching strategy. No partitioning. No clustering. No layers at all. Just one big room where everything lives together.
On-premise, this is survivable. You already paid for the hardware. The server grinds through those table scans at 2 AM and nobody sees the cost because the cost is invisible.
Then someone in leadership says the magic words: “We’re moving to the cloud.”
The Hard Truth
Microsoft Fabric, Databricks, and Snowflake do not bill like your on-prem server. They bill by consumption. Every one of those left-join scans, every function-wrapped join condition, every unoptimized view stacked on a view stacked on a view: the platform happily executes all of it, and then it sends you an itemized invoice.
Cloud platforms don’t fix bad architecture. They put it on a meter.
I call this the Lift-and-Shift Tax. It’s not a migration cost. It’s ten years of invisible architectural debt becoming a visible monthly line item, at consumption pricing, with interest. And when that bill lands, leadership’s first instinct is to look at the data person and ask what they did wrong.
Wrong question. Let me tell you how that database actually got built.
The Field Promotion
Your company didn’t hire a data architect. Your company grew one by accident.
It started when you were small: a handful of people, everything in spreadsheets. The business grew, the spreadsheets broke, and somebody said, “We need our data in one place so we can report on it.” And then somebody else said the sentence that defines this entire pattern:
“Talk to Sarah. She’s good with data.”
So Sarah got plucked out of accounting, or operations, or wherever she was quietly being excellent, and handed the keys to the entire data estate. No formal training. No mentor. No second engineer to bounce ideas off. No architecture review, because there was no one qualified to review it. She was field-promoted, handed the rank because the company needed a body in the seat, not because anyone equipped her for the role.
And here’s the part leadership conveniently forgets when the cloud bill arrives: Sarah delivered. Under pressure, alone, learning from forum posts and trial and error, she got reports into the hands of the business. The company ran on her work. You probably praised her for it. She was the hero.
I’m not guessing at any of this. I was Sarah. Twenty-six years ago, I was the person who was “good with data,” promoted into a role nobody trained me for, building things the only way I knew how. The difference between me and the 10-Year Junior I wrote about a few weeks ago isn’t talent. It’s that somewhere along the way, I got direction, and most field-promoted data people never do.
The Three Habits Isolation Breeds
When a capable person builds in isolation for a decade, the same three patterns show up every time. Not because they’re careless, but because nobody ever showed them another way.
Modeling by Accretion. There’s no design, only sediment. Every new request adds another table, another view, another join. The database isn’t architected; it’s accumulated. It ends up shaped like the source application instead of shaped like the business. The way out: Impose layers, even on the current system. Schemas are free, on SQL Server and everywhere else. Separate raw landing data from cleansed data from business-ready reporting data into distinct schemas with distinct naming standards. This is Medallion Architecture thinking (Bronze, Silver, Gold), and you do not have to wait for the cloud to start practicing it. A platform organized into layers migrates cleanly. A
dbojunk drawer migrates as a junk drawer.Logic That Lives in One Head. The business rules aren’t documented or layered. They’re encoded in a 400-line view that only one person understands. That’s not a data platform. That’s a single point of failure with a salary. The way out: Get every script, view definition, and business rule into version control and out of one person’s memory. Decompose the monster views into readable, layered steps using CTEs, where each step has a name and a single job. The test is simple: if a new hire can’t follow the logic in five minutes, it isn’t an asset. It’s a hostage situation.
Tool-Shaped Thinking. When the visual designer is the only teacher you’ve ever had, you build what the designer makes easy, not what the engine executes efficiently. The drag-and-drop view builder doesn’t warn you that a function in your join criteria just disabled every optimization the engine had. The way out: Fix the keys, not the joins. Those
LEFT()andSUBSTRING()functions buried in join criteria exist because two systems never agreed on an identifier. Conform the keys once, upstream in the cleansed layer, so every downstream join is a clean match on an indexed column. Then audit the left joins: most of them exist out of habit, not intent, and every unnecessary one forces the engine to scan rows it should have eliminated. On-prem, that’s a slow query. On consumption pricing, it’s a recurring charge.
None of these habits hurt much on hardware you already own. All of them are gasoline the moment you migrate to a consumption-based platform.
The Indictment
So now we get to the uncomfortable part, and leadership, this part is for you.
Your data person is not failing you. You failed them.
You field-promoted a capable employee into one of the most complex disciplines in modern business and gave them nothing: no training budget, no mentor, no peer, no architectural oversight. You praised the speed and never inspected the foundation. You let them carry the entire data function alone because it was working and it was cheap.
It was never cheap. It was deferred. And the cloud migration is where the deferral comes due.
If you lift and shift that architecture into Fabric, Databricks, or Snowflake as-is, you are not modernizing. You are signing up to pay the Lift-and-Shift Tax every single month, while your data person, still alone and learning an entirely new platform under even more pressure, gets blamed for a bill that a decade of your decisions created.
The Migration Triage Protocol
You do not need to fix ten years of debt before you migrate. You need to fix the parts that compound at consumption pricing. Here is the order of operations I use when I’m brought in before a migration instead of after one.
Step 1: Audit before you sign anything. Before you commit to a platform, a timeline, or a budget, get an honest inventory of what you actually have. Which views drive the business? Which ones are dead? Where are the function-wrapped joins and the view-on-view stacks? You cannot price a migration on an estate nobody has mapped. Most of the budget overruns I get called in to clean up started here, with a contract signed against an inventory that didn’t exist.
Step 2: Kill the dead weight. Every legacy estate is full of tables nobody has queried in three years and views built for a report that no longer runs. Migrating them isn’t being thorough. It’s paying cloud rates to warehouse garbage. Archive it, document it, and leave it behind.
Step 3: Pay down the top offenders, not everything. Rank the surviving workloads by how often they run and how much they scan. The nightly job that feeds every executive dashboard gets refactored before migration: keys conformed, joins cleaned, logic layered. The quarterly report nobody loves can lift and shift as-is and get fixed later. Triage is the discipline of fixing what compounds and deferring what doesn’t.
Step 4: Design the target before you move. Define your layers, your naming standards, your ownership, and your access model in the new platform first, then migrate into that structure. Moving the dbo pile over and promising to “reorganize once we’re settled” is the lie every failed migration tells itself. You will never be settled. The mess just acquires a monthly invoice.
Step 5: Pilot one domain and read the meter. Take a single business domain end to end, run it for a full billing cycle, and study the consumption like a CFO. That pilot tells you what the real Lift-and-Shift Tax on your estate looks like while the stakes are still small, and it teaches your data person the platform’s cost model before they’re responsible for all of it.
None of this is exotic. It’s the same boring discipline that separates a migration from an expensive relocation of your problems. And notice what every step has in common: each one requires someone who has done this before. Which brings us to the actual fix.
The Fix
The answer is not to replace your data person. They have something no consultant can walk in with: they know where every body is buried, how the business actually thinks, and why every weird workaround exists. That knowledge is an asset.
What they’re missing is the thing you never gave them: direction.
That doesn’t require a full-time architect on payroll. What it requires is experienced architectural leadership applied at the right moments: designing the target architecture before the migration instead of auditing the damage after, setting standards, reviewing the work, and coaching your data person from field-promoted survivor into the actual architect of your platform. Hours a week of the right guidance, not another body in a seat.
The Verdict
Somewhere in your company right now is a database where everything lives in dbo, held together by left joins and one person’s institutional memory. That’s not an indictment of the person who built it. They did exactly what you asked with exactly what you gave them: nothing.
But the meter is coming. Migrate that architecture untouched and you’ll pay for every shortcut, every month, forever. Or you can do what you should have done years ago, put real direction behind your data person, and migrate something worth running.
The Field Promotion got you this far. It will not get you through the cloud.
This is exactly the problem Gambill Data exists to solve. We provide fractional data architecture and leadership: an experienced architect on retainer to guide your platform and migration strategy, a fractional data leader to set roadmaps and build your team, sponsored one-on-one coaching for your data professionals, or monthly full-day training on Databricks and the modern data stack. Senior direction, at a fraction of a senior hire.
Your data person built your platform alone. Don’t make them migrate it alone. Book a strategy call.
And if you’re the data person in this story, the one who got field-promoted and has been figuring it out solo, the next article is for you.