.png)
Don’t Start Coding Until You Answer These Questions
- Christian Steinert
- 3 days ago
- 4 min read
Why your brownfield data migration is probably doomed (and how to fix it before writing a single line of code)
One month.
That’s how long a single report migration dragged on because we dove straight into development without asking the right questions first. And it was completely avoidable.
I realize this newsletter needs to provide value to healthcare data leaders in the mid-market and scale-ups. As a consultant, I often share perspectives from client projects—the wins and the failures. After my recent post about delivering ROI over maintaining perfect best practices, I’ve reflected on how this consultant mindset might differ from yours.
As a full-time employee, you likely have deeper patience and investment with the business to ensure data infrastructure is built right from the start. Though honestly, that’s becoming less common in 2025—AI has raised the bar even higher for data leaders to deliver value quickly, whether you’re a consultant or full-time.
In my opinion, good data consultants are viewed by execs as extremely efficient experts who can assess, diagnose, build, and solve pain points quickly. The expectation of speed forces consultants to take shortcuts in the immediate term to deliver the ROI they promised in the sales offer.
All of that to say: I don’t want to give the impression that I’m failing to place myself in your shoes. I owe it to my audience to relate EXACTLY to healthcare data leaders, and I feel that I’ve neglected the full-time perspective in past issues.
So with this issue, I’m focused on providing project management tactics to ensure your data implementation projects start on the right foot. I want to walk you through one specific example of a brownfield data migration project—a single report—that went sideways for a month due to poor project management.
The Reality: Legacy Chaos Is Your Starting Point
In my experience, the healthcare mid-market is covered with brownfield data infrastructure and countless problems to solve. Legacy code written by a DBA who left two years ago. All data sitting in on-premise SQL Server—more or less a data swamp with massive report tables and stored procedures built for single reports and use cases.
It’s tempting to dive into development, mirroring legacy logic like-for-like (or a refactored version) in the new environment.
This creates massive issues.
You don’t have context for why a query filters on three different procedure codes. Date filtering logic uses a specific time range—why limited to the last 4 months? Additional fields in the SELECT force unnecessary tables and joins that might not actually be needed for the new report.
All of this is problematic because it demands enormous energy and time to reverse engineer, but you don’t have full context for the historical logic’s business reasoning OR the migration’s current business needs.
Pretty soon you’re spending massive time bringing in every field and piece of logic from legacy into the new cloud environment without fully understanding what and why you’re building. Scope creep arises, complexity ensues, and your stakeholders begin to wonder why things are taking so long.
This is obviously a huge issue, but trust me—it happens to developers constantly.
The Solution: Three Steps Before You Code
If your team operates in Agile (I recommend it), look to your Scrum master, project manager, or business analyst to obtain business context for a given report build. Whoever is interfacing with the business and gathering requirements is who you should work closely with.
Next, follow these steps.
Step 1: Confirm Your Understanding of the Report’s Intent
What question is the business trying to answer?
Far too often, we get into development without full knowledge of a given metric or report’s context and intent. Ensure the project manager or business analyst understands the details from a business perspective. Ask strategic questions and try to reveal the details of the report’s business implications.
Is the legacy logic actually correct? Why are specific logic pieces present in the existing report?
If requirements seem generic and you’re met with a lack of awareness on how the report is used, what certain metrics mean, and why they’re calculated a certain way—this is an indicator that more discovery work is needed with the business.
Do not start building until that clarity and confirmation is there. Otherwise you may go down a query rabbit hole that is flat out wrong. I’ve been there.
Step 2: Conduct an Inventory Analysis
Take a look at the legacy code and confirm which fields and tables are actually needed for the new build with the project manager. I typically use Google Sheets to accomplish this. My columns are usually: Field Name, Table or Object Name, Need (Y/N), and Notes.
List out every field from legacy and decide if you actually need it. Also look at new requirements and see what may need to be added. Document it all here.
This narrows what a developer will have to code in the new environment.
Step 3: Begin Development with Clarity
Once the business context is understood and the inventory analysis is completed, you’re ready to develop. Now you can begin building out the Fact and Dimension tables and perform data modeling/OBT without blindly coding or wasting time.
The Bottom Line
The number one takeaway from this issue is the inventory analysis. I think requirements gathering and discovery are table stakes, but process and documentation aren’t talked about enough in Agile data teams.
Again, this assumes a brownfield implementation or data migration. I don’t want you to make the mistake I made of going in and trying to mirror the logic and fields of a legacy query.
Deeply consider what is actually needed for a report in the new environment and new state. Lots of times, legacy logic is just flat out wrong—unnecessary fields, tables, and filter logic that create complexity.
Cut through the noise by syncing with your project manager, the business, and documenting what’s actually needed. The report and its code will set you up for strategic, impactful, and focused development that answers business questions.
Christian Steinert is the founder of Steinert Analytics, helping healthcare organizations turn data into actionable insights. Subscribe to Rooftop Insights for weekly perspectives on analytics and business intelligence in these industries.
Also - check out our free Healthcare Analytics Playbook eBook here.
Comments