Somewhere in your organisation, a spreadsheet is holding critical operational data together by a thread. It lives on one person's laptop. They built it three years ago. They've since moved to a different team — or left entirely. Nobody else fully understands it.
This isn't unusual. Across organisations of every size and type — from research institutions to government agencies, from healthcare networks to engineering firms — small expert teams quietly build their own data ecosystems. Custom Access databases. Excel workbooks with macros that only the original author can interpret. Local SQL instances that IT doesn't know exist. These shadow databases are everywhere, and they represent one of the biggest risks and missed opportunities in modern data management.
The Problem With Siloed Specialist Data
When expert teams run their own isolated databases, the risks compound quietly over time. If the person who built the system leaves, retires, or is simply unavailable, institutional knowledge disappears with them. There's no documentation, no backup strategy, no handover plan. The data may still technically exist, but it becomes effectively inaccessible.
Beyond the continuity risk, siloed data creates a fragmented picture of what your organisation actually knows. Dataset A sits separate from Dataset B. Insights that could only emerge from combining the two never surface. Decision-makers are flying partially blind — not because the data doesn't exist, but because no one can easily bring it together.
In an era of increasing expectations around evidence-based decisions, audit trails, and organisational transparency, this is no longer just a technical inconvenience. It's a governance risk.
Why Specialist Teams Resist Integration (And Why That's Understandable)
Before you can bring these teams over the line, you need to genuinely understand why they push back. Their resistance is rarely stubbornness for its own sake.
They've been burned before. Many have lived through "centralisation" projects that delivered a clunky enterprise system incapable of handling their specific data nuances — and left them worse off than when they started.
They worry about losing control. Their database is tuned to their workflows. They can run the exact reports they need, right now, without raising a ticket. What happens when IT "standardises" everything and their carefully constructed query no longer works?
They're protective of data quality. Specialists care deeply about provenance, collection methodology, and accuracy. A shared data platform can feel like a place where their carefully curated datasets get diluted or misrepresented by people who don't understand the domain.
They don't trust the timeline. They've watched large IT projects drag on for years, consuming staff time and energy, while the system they actually need to do their job sits in limbo.
These are legitimate concerns. Any integration approach that doesn't take them seriously is doomed before it starts.
How to Approach Resistant Teams: Listen First, Sell Later
The worst thing you can do is arrive with a migration plan and a deadline. The best thing you can do is start with a genuine discovery conversation — not an IT audit, but a knowledge-sharing session.
Sit down with each team and ask: What data do you collect? What decisions does it inform? What would break if this system disappeared tomorrow? Frame the conversation around protecting their work, not replacing it.
From there, look for small, immediate wins. Can you help them with a simple backup and documentation process right now, before any integration happens at all? That builds trust and demonstrates that the organisation is investing in their data — not just trying to absorb it.
Involve them in designing the integration. Give domain leads a seat at the data governance table. Let them define the metadata standards for their own datasets. When people have shaped a system, they own it — and they defend it.
The Benefits Worth Talking About
Once the conversation is open, here's what you can genuinely offer as reasons to integrate:
Resilience and continuity. Their data — sometimes representing years of painstaking collection — becomes protected. No longer dependent on one person's machine or an undocumented local server. Proper backups, documented schemas, and succession planning get baked in.
Better tools without the admin overhead. Integrated platforms open up access to visualisation, dashboarding, and reporting capabilities that would take any individual team months to build independently. The organisation's investment in shared tooling starts working for them.
Cross-domain insights. Data that lives in isolation tells a limited story. Connected to other datasets, it can reveal patterns and relationships that support stronger business cases, better strategic decisions, and more compelling reporting to stakeholders.
Less time on maintenance, more time on the actual work. Right now, someone in that team is the unofficial database administrator — fixing broken queries, troubleshooting failed imports, chasing corrupted files. Integration with proper IT support frees them to do the expert work they were hired for.
Recognition and discoverability. Data that lives in a shared, well-governed platform gets found, cited, and used. Work that sat invisible in a local database starts contributing to the organisation's broader evidence base and public record.
A Practical Path Forward
A phased approach works best. Start with a data register — simply cataloguing what datasets exist, where they live, and who is responsible, without touching the systems themselves. Then move to federated access, where data can be queried from a central layer without forcing teams to abandon their existing tools immediately. Full migration to a shared data platform becomes the final stage, tackled team by team at a pace that allows proper testing and genuine transition support.
The goal is not to delete what specialist teams have built. It's to make sure that work survives, grows, and delivers value beyond the small group who created it.
Navigating data integration challenges across resistant specialist teams? We'd love to hear what approaches have worked — and what hasn't.
