At a previous org, I discovered a team had been using a standalone email platform to send communications to customers. Not the approved MAP. Not something IT had vetted. A completely separate tool, a relic of a long ago acquisition, with a single shared login, manually imported lists, and years of accumulated segments that existed nowhere else.
My first instinct was simple enough: migrate them to our actual platform. Consolidate the data. Get everyone on the same system. Easy.
It was not easy.
Nobody wakes up and decides to create a data silo. They just need to get something out the door.
The Archaeology
When you crack open one of these rogue platforms, it tells a story. Not a clean one. More like walking into someone’s garage workshop where everything is covered in sawdust but they swear they know exactly where the 10mm wrench is.
The list names alone were a journey. There were at least a few variations of “List Name_DO NOT USE” which, if you’ve been in this world long enough, you know means someone sent to the wrong list at least once. My personal favorite was a particular segment of customers that was apparently on its third iteration, helpfully identified with “_V2” at the end.
The email templates were functional in the way that a duct-taped bumper is functional. They worked. They got the job done. They would not survive a brand review. The “Custom Fields” section was mercifully untouched, which I’m choosing to believe was a conscious decision and not a happy accident.
And I’ll be honest: looking at all of it, I felt a wave of nostalgia. Because I’ve been this team. Early in my career, on smaller teams with smaller budgets, you get scrappy. You find a tool that does the thing you need it to do. You build your system. To an outsider it looks like chaos, but in your brain it all makes perfect sense.
It’s not built this way on purpose. It’s built this way because you’re underwater with send requests, last-minute updates, stakeholders who need something out yesterday, and a hundred other things that are all somehow urgent. You find a reasonable line, say “good enough,” and move on. Multiply that by a few years and a few team members, and you’ve got what I was looking at.
Why This Happens
Nobody wakes up and decides to create a data silo. What happens is a team has a job to do, the “official” tool either doesn’t exist yet, isn’t available to them, or has a six-week onboarding queue they don’t have time for. So they find something that works. They sign up. They start sending.
And then a year passes. Then three. The segments grow. The institutional knowledge deepens. The shared login gets passed along when someone leaves. The lists get more specific and more tangled. And suddenly you have a parallel universe of customer data that nobody outside that team knows about, governed by nothing and backed up by no one.
This is not a failure of the team. It’s a failure of the organization to provide the tools and access people needed when they needed them. The team did what resourceful people do. The problem is that resourcefulness has a shelf life.
Why It Matters Now
There was a time when this kind of setup was fine. Maybe not ideal, but fine. That time was about ten years ago.
The rules have changed. GDPR, CAN-SPAM enforcement, CCPA, and a growing list of regional data regulations mean that customer data sitting in an unaudited platform with a shared login is a compliance risk that can actually cost you money. Real money. Not theoretical money.
And that’s just the legal side. A shared password means no individual accountability. No MFA. No audit trail. No way to know who sent what, when, or to whom. No permission controls. Nothing stopping someone from accidentally sending a service outage notification to your entire database instead of the 200 customers who actually needed it. And when that shared password gets passed to a new team member over Slack, or when someone who left the company two years ago still technically has access, you’ve got a problem that nobody is tracking because nobody knows it exists.
The visibility problem is just as bad. When a platform like this is operating outside your marketing stack, it’s impossible for the organization to get a true read on how many communications a customer is actually receiving. Your marketing team is carefully managing cadence and suppression rules in the MAP, trying not to overwhelm contacts, and meanwhile this other team is sending from a completely separate system that nobody else can see. You might be hitting the same customers three times a week and not know it.
And if they’re sending from the same domain as your marketing team, you’ve introduced sender reputation risk that can take months to unwind. When your deliverability suddenly tanks, or your domain shows up on a blocklist, and your email team is scrambling to figure out what happened, the answer might be a platform they’ve never heard of sending communications they didn’t know about.
And then the data. If those segments and lists exist only inside this one platform, maintained by the institutional memory of a handful of people, what happens when those people leave? What happens when the vendor sunsets the product? What happens when someone asks for a comprehensive view of all customer communications and you have to explain that a chunk of it lives in a tool nobody in leadership has ever heard of?
The Hard Part
Here’s what people underestimate about fixing this: it’s not a migration. It’s a translation.
Those segments weren’t built with documentation. They were built with context. “This list is everyone who had a billing issue in Q3 but not the ones who already got the credits” is a segment that lives in someone’s head, not in a filter you can export. Recreating it 1:1 in another platform is somewhere between difficult and impossible without sitting down with the people who built it and reverse-engineering their logic.
Then there’s the change management. You’re onboarding a team into a platform they’ve never used. They need training. They need permissions configured correctly. They need to understand why they can’t just upload a CSV and hit send anymore. And you need to do all of this without disrupting the communications those customers are already receiving, because the emails still need to go out while you’re rebuilding the plane.
This is the part of marketing operations that doesn’t make it into conference talks. It’s not a martech stack optimization story. It’s not an AI play. It’s showing up, peeling back layers, respecting what was built, and carefully unwinding it into something sustainable.
The Takeaway
If you’re in marketing ops, revenue ops, or IT, I’d bet something similar exists somewhere in your organization right now. A tool nobody approved. A shared login. A team that built something that works for them but exists outside every governance framework you’ve put in place.
Nobody’s to blame. But it will become a problem.
The unsexy work of compliance, data governance, and platform consolidation doesn’t generate a lot of excitement. But it does tend to help me sleep better at night when I know it’s been done well. And finding these things before they find you is a big part of what this job actually is.
If you’re staring at your own version of this right now, I’ll leave you with the one thing I wish someone had told me earlier: don’t start with the tool. Start with the people. Understand what they built and why. Respect the scrappiness. Then build them something better.
If you’re curious about your sender reputation, I built a free tool called SendReady that checks SPF, DKIM, and DMARC in seconds.
If you’re planning the migration that comes after the discovery, I put together a MAP Migration Planning Checklist that covers every phase from scoping through decommission.
If this sounds familiar and you want help untangling it, that’s what I do.