In the age of AI, we need to to be cognizant that the technical bottlenecks are shrinking. What's possible is changing at a breakneck pace. The risk is not capitalizing on this by taking the time to truly understand your business, end-to-end, and planning change that maximizes ROI.

Transformation Means Changing How People Work, Not Just What Software They Use

There's a particular kind of organization that reaches out to us on life support. Revenue is declining. In one case, it was membership — fewer renewals, fewer people attending meetings, opening emails, signing up for courses, showing up to conferences. Every metric pointed the same direction, and the leadership team had already diagnosed the problem before they picked up the phone: the website needed a refresh.

They weren't wrong that something needed to change. They were wrong about which "something."

The Digital Part Isn't the Problem. The Transformation Part Is.

By the time some organizations get to us, they've already spent the money. I've seen legacy companies invest anywhere from $200,000 to $500,000 in a new system — a beautiful, modern replacement for whatever they had before — that didn't move a single meaningful metric. The CEO pulls the purse strings tight, the project gets quietly labeled a failure, and re-approaching the same leadership team to say "the last attempt didn't fail because of the technology" is one of the harder conversations in this business.

With the association client, we had the advantage of getting there before they'd built anything. And what we found first wasn't a technology gap — it was a research gap. No customer interviews. No focus groups. No objective discovery. No competitive analysis against other associations solving the same problem. Nobody had actually asked why membership was dropping. The assumption was that a website refresh would fix it, full stop.

Here's the pattern I've seen play out in roughly nine out of ten legacy transformation projects: if this organization had gone straight to a dev shop, that dev shop would have built them a genuinely beautiful new system. And it wouldn't have fixed a thing. Everyone treats "digital" as the salve. Almost nobody sits with the word "transformation" long enough to look inward first.

Everyone Wants to Design the Future. Almost Nobody Wants to Map the Present.

Legacy technology projects have a gravitational pull toward the future state — mockups, prototypes, screenshots of the shiny new thing. It's the exciting part, and it's genuinely more fun to talk about than what already exists. But the future state has always been the easier 20% of the work, and with AI now compressing how fast that 20% can actually get built, it's shrinking further by the month. The current state is where the real risk lives, and it's the part almost everyone tries to skip.

Before we design anything new, we need real answers to unglamorous questions: What systems are actually involved in today's processes — all of them, not just the obvious ones? How is data captured, stored, and used, and by whom? How well maintained is the legacy data, honestly? Do the current systems enforce any data entry rules that would give us clean data to migrate, or is what's in there going to bring its inconsistencies with it? What reports does someone run every week to keep the lights on, and what internal controls exist that a new system would need to preserve?

Nobody asks these questions because they're not exciting. But every legacy transformation that goes sideways, goes sideways because somebody skipped this part.

Every Legacy Organization Has a Helen

There's almost always one person — let's call her Helen — who's been there for decades, has lived through two or three previous attempts to modernize, and has the scar tissue to prove it. Most vendors treat Helen as an obstacle: the person who says "we tried that before" or "that won't work here." We've learned to do the opposite. Helen is the single best source of institutional truth in the building, and she's usually the person nobody bothered to interview before the last three failed projects.

We double down on the Helens. We need her to walk us through exactly why previous attempts failed, and we need her to become a champion of the new effort rather than a skeptical bystander watching it happen to her department. An organization that ignores its Helen is choosing to repeat mistakes she could have told them about on day one.

The Fear That Keeps Companies Stuck

Legacy organizations tend to default to one of two instincts, and both keep them stuck. Either they keep layering new tools on top of old technology, patch over patch, until nobody fully understands how anything connects anymore — or they get so afraid of disruption that they approve a small, fragmented project touching one system, instead of looking at the whole business at once.

That fear is understandable. Tackling everything simultaneously feels risky. But the alternative — small, disconnected fixes approved in isolation — doesn't reduce risk. It just spreads the same risk out over more time, with less visibility. My advice is almost always the same: analyze the whole first. Map the current state across the entire business before deciding how to phase the implementation. Phasing is smart. Phasing without first understanding the whole is how you end up rebuilding the same fragmented mess with newer tools.

Leaders are consistently surprised by what this mapping reveals — not just the number of systems in play, but the sheer creativity employees have used to work around broken processes. And today, with AI tools now sitting in the mix, that creativity has multiplied. It's a bit of a wild west. The result isn't more efficiency with fewer systems — it's the opposite. More offline workarounds. More disconnected tools. More variability in how the same job gets done from one person to the next.

The Real Risk Isn't Moving Too Fast Anymore

For years, leaders have treated technology as the constraint — the thing that determines how ambitious a transformation can be, and how many years it's realistically going to take. That math no longer holds. AI is compressing the distance between "we know what we want to build" and "it exists" faster than most leadership teams have updated their sense of what's possible. A five-year transformation roadmap that felt appropriately cautious a couple of years ago may now be the riskier choice, not the safer one — because the goalposts, the competitors, and the tools themselves are all moving faster than that plan accounts for.

The organizations that get stuck usually aren't the ones that moved too fast. They're the ones still operating on an old assumption about how slow "careful" is supposed to be.

To be clear, this isn't an argument for skipping the current-state work — if anything, it raises the stakes on doing it well, because building faster just means compounding mistakes faster too. But once an organization genuinely knows what it's building and why, the actual construction — the 20% everyone gets excited about — has gotten dramatically cheaper and faster to execute than it was even two years ago. The leaders who benefit most from this moment aren't the ones with the biggest budgets. They're the ones willing to challenge their own assumptions about how long transformation is supposed to take, and how much technology is really holding them back versus how much fear is.

What Actually Fixed It

For the association client, the fix started with mapping the entire business and its data flows — from the moment a prospect first landed on the website, all the way through to becoming a paying member. We looked at everything: the website, the CRM, internal data systems, the offline spreadsheets people had quietly built to track what the "real" systems couldn't, invoicing, email, financial and operational reporting. And underneath all of it, we did the research nobody had done before — real conversations with members and real interviews with the employees running the systems every day.

The result: an organization that had been running on ten disparate systems consolidated down to three. Time to perform mission-critical functions dropped by 30%. And Helen — after decades of holding the institutional memory together through failed attempt after failed attempt — finally got to retire, knowing the thing she'd tried to build for years had actually stuck.

Bolting digital onto a legacy business is rarely a technology problem wearing a disguise. It's usually an organization that skipped the hard, unglamorous work of understanding how its people actually work before it tried to change what they work with. The fix isn't a better system. It's the discipline to map the whole business — the people and the process, not just the software — before you touch any piece of it.

Why We Build It This Way

A dev shop would never have found Helen. Neither would a brand agency, or a CRM vendor brought in to fix one system in isolation. Each of them was hired to solve a piece of the puzzle, and none of them was positioned — or incentivized — to sit down with the person who actually understood why the last three modernization attempts failed. That's not a knock on any of those specialists. It's just not the job they were hired to do.

Our methodology starts with exactly that kind of whole-business mapping, in the Plan phase, before any system gets touched — because the people who hold the real institutional knowledge and the systems that encode the current process have to be understood together, not handed off to different vendors who never talk to each other. Getting the association down from ten systems to three, and getting mission-critical work done 30% faster, wasn't a technology win. It was what happens when the same team that talked to Helen also mapped the data flows, interviewed the members, and designed the future state — instead of three separate vendors each guessing at what the other two had found.