10 min read · Case Study
The people in the field must have the necessary tools to build the metrics they need to do their job accurately.
The Situation
The CRM had been the company’s mandated source of truth for years. CRM 1.0 and CRM 2.0 were built around engineering workflows, the milestones, production metrics, and job-level data engineering depended on daily.
Over time, the platform was redesigned around a different set of operational priorities. CRM 3.0 favored a cleaner, more standardized structure with fewer customizations. What that redesign didn’t account for is what happens downstream when you remove specific data points people depend on.
· · ·
The Diagnosis
This engagement covered one workflow specifically, one lane of a company-wide migration, while colleagues handled others in parallel. The work began with a field-by-field mapping of that workflow for three different clients. Each client required different milestone structures, different external submission processes, and different production reporting requirements. The goal was straightforward. Identify every active field in CRM 2.0, find its equivalent in CRM 3.0, and document where clean mappings existed and where they did not.
What the mapping revealed was not a gap here or there. It was a pattern. The migration had been optimized to cut down how many fields someone had to fill in. It had not been optimized around what happened to that data once it was in the system, who depended on it, and what broke when it wasn’t there.
Three Illustrations
The specific fields that disappeared in the migration aren’t mine to detail. But the lessons are worth illustrating, because they aren’t unique to this migration, or even to CRMs generally. They show up anywhere a system gets rebuilt by people who understand the architecture better than they understand the work the architecture is supposed to support. Here are three instances.
Linking Paired Jobs: Imagine certain jobs need to be connected for client calls, milestone tracking, or billing purposes. This might be accomplished with a unique identifier that links them together. If that field is missing, you still need a way to connect the jobs, but now you can’t do it consistently. That opens the door to workarounds, everyone inventing their own fix to solve the same problem, which leads to errors, questions, and more work. A department that depends on that link, billing, reporting, doesn’t matter which, now has to go hunting for information that used to sit in one place. Multiply that across every team that touches the job and a missing field becomes a wasted hour, repeated every time someone needs the answer. That is the opposite of what a CRM is for, a single source of truth.
One Field, Three Functions: CRMs are built to do exactly this kind of work. Used well, they tell a complete historical story. They surface the metrics that matter. They help you size the job in front of you before you commit resources to it. A single well-designed field can quietly carry all three of those responsibilities at once. Now imagine that field disappears in a migration. Not because anyone decided it wasn’t valuable. Because nobody mapped what it was actually doing before they rebuilt the system around a simpler structure. Three separate functions, gone at once. Nobody can size a job the way they used to. Nobody can pull the metric that used to feed reporting. Nobody can point to the historical pattern that used to inform decisions. The fix isn’t obvious, because the people who removed it never saw all three jobs it was doing. They only saw the one they were trying to simplify.
Correction History: Imagine a system that once tracked a widget’s full correction history through a handful of dedicated fields, visible on one screen. Completion date, date submitted to department X, date returned for corrections from X, corrections resubmit date, and widget accepted date. Five fields, thirty seconds, the whole lifecycle. The new system replaces this snapshot with a series of individual child records, each taking five to seven minutes to populate and link properly. The math doesn’t work in either direction. More time to enter the same information, and the information itself scattered instead of centralized. With no snapshot, understanding what actually happened means opening every child record and piecing the story back together. For anyone looking for answers there’s no quick way to tell whether a widget went through multiple rounds of revision, whether there were actually multiple widgets involved, or some combination of both. The system meant to reduce work created more of it, and buried the very history it was supposed to preserve.
None of this is about assigning blame to the people who build these systems. Architecture decisions are hard, and simplification is usually the right instinct. The problem isn’t that a field got removed. It’s that removing it happened before anyone fully understood what that field was actually doing for the people using it every day. A field rarely does just one job. It links, it sizes, it reports, it preserves history, often all at once, invisibly, until it’s gone. That’s what these three examples show from different angles, the same failure each time in a different form. Map what a field actually does before you decide it’s safe to remove. Skip that step, and it’s not just one team that feels it. Every group downstream of that field, the ones who never got a vote in the migration, is left to work around what’s missing.
The Proof of Concept Was Already Failing
Before the formal escalation, I asked leadership for proof of concept. Leadership pointed me to a project team already operating in CRM 3.0 as evidence the system worked in the field. A call was arranged to see how they were managing their work.
The team lead pulled up a spreadsheet.
It wasn’t from CRM 3.0. She was maintaining her own private tracking document because the system wasn’t giving her what she needed.
The one team cited as proof of concept had already reverted to the exact behavior the company had spent years eliminating. The source of truth was fragmenting before the migration was even complete. When this was surfaced to leadership, the response was to stay focused on the three clients being mapped. That team was not the current concern. From a project management standpoint, that was reasonable. From a change management standpoint, it was the most important signal in the room, and the organization was choosing not to look at it.
How the Ask Got Slow-Walked
I raised it. I documented it. I built the formal case for it, field by field, what each one did and what broke without it. I pushed it up the chain.
Getting a straight answer took multiple conversations, when one honest answer on the first would have cost everyone less time and headache.
We are using this out of the box, and we’ll wait and see what breaks first.
What’s worth naming isn’t that the answer was no. Organizations say no all the time, and plenty of those no’s are right. It’s that the process was never built to reach a decision. It was built to outlast the request.
The Handoff
The complete body of documentation, the field mapping, the gap analysis, the sandbox results, the use cases, the specific recommendations, was handed to new leadership on the way out the door. Along with a direct warning. Implementing the recommendations would require organizational authority, and without it, the migration would keep reflecting architectural priorities over operational ones. The evidence is there. The roadmap is written. Good luck.
The Outcome
The fields were not added before go-live. The engineering teams inherited a system missing the data infrastructure they depended on and lived with the consequences for nearly a year.
The predictable result followed. Teams went back to private spreadsheets. The behavior the company had spent years eliminating returned quietly, not out of defiance, but because the system gave them no alternative. The proof-of-concept team had shown it was coming before the migration was complete.
Almost a year later, confirmation came through a former colleague. The fields had been added. The out-of-the-box approach had met reality and it became impossible to ignore. What the documentation had predicted would break had broken. Whether the fix traced back to this roadmap or arrived at the same place on its own doesn’t change what the documentation had already proven.
A long win, but at what cost?
· · ·
What This Signals
Technology migrations don’t fail systems. They fail people. The engineer who can no longer report her own production. The director who walks into a client meeting with data that points blame at the wrong place. The coordinator who rebuilds a spreadsheet at her desk because the source of truth can’t hold what she needs.
The team building the new platform was not negligent. They were solving the problems leadership had identified as priorities, deployment complexity, population burden, system architecture. They built a start-to-finish model that flowed. Billing worked. The structure held. But solving for flow is not the same thing as solving for metrics.
The people in the field must have the necessary tools to build the metrics they need to do their job accurately.
They still needed to size jobs, report production, and track correction cycles accurately enough to challenge a turnaround time. That part was never on the priority list. When the evidence was brought to them directly, across multiple conversations, with documented use cases and operational testimony, the answer was still the same. Out of the box, wait and see what breaks first.
That is not a technology problem. That is a change management problem.
The private spreadsheets that came back after go-live were the proof. The people inside the system had been left behind by it. What the migration was supposed to deliver, one shared system everyone could trust and pull from, was eroding. The out-of-the-box mandate, applied without understanding what the data needed to do, had an adverse effect, quiet, predictable, and completely preventable.
The most dangerous distance in any platform migration is not between the old system and the new one. It is between the people making the decision and the people who will live inside it every day. If you want to build it correctly, you talk to the people who are going to use it, not after go-live, not when things start breaking, but before the first design decision is made. Get it live, see what breaks, see how mad people get, then maybe fix it, is not a plan. It is a failure waiting to happen. People at the top of the org chart are often too far removed from the daily work to know what a missing field costs the person doing the work at eight in the morning. That distance isn’t anyone’s character flaw. It’s built into the structure.
The system goes live. The people find a workaround. Somewhere on someone’s desktop, a spreadsheet grows, quietly undoing everything the organization said it stood for.