A global professional services firm with 8,000 consultants maintained institutional knowledge across forty-seven separate systems. Project proposals lived in a document management system. Client engagement histories lived in a CRM. Technical methodologies lived in a wiki. Subject matter expertise lived in internal blogs and mailing list archives. Lessons learned lived in post-engagement reviews stored on a shared drive that predated the current document management system.

When a partner prepared a proposal for a new engagement, they needed to answer three questions: have we done similar work before, who in the firm has relevant expertise, and what methodologies and templates are available. Answering these questions required searching across multiple systems with different search interfaces, different metadata schemas, and different access controls. The average time to assemble a proposal was three weeks, and partners estimated that sixty percent of that time was spent searching for existing knowledge rather than creating new content.

The firm had tried to solve this problem three times. Each attempt was a migration project — move everything into a new system that provided unified search. Each migration failed because the scope of consolidation was overwhelming and the disruption to ongoing work was unacceptable.

Why migrations failed

The forty-seven systems were owned by different groups with different workflows. The CRM was owned by the sales organization and was optimized for pipeline management, not knowledge retrieval. The wiki was owned by the methodology group and was optimized for process documentation, not project history. The document management system was owned by IT and was optimized for compliance and retention, not search.

Each system had been configured to serve its primary users. Forcing all forty-seven systems into a single platform required either accepting the lowest common denominator of functionality — which degraded the experience for every primary user — or building a platform sophisticated enough to replace all forty-seven systems, which was a multi-year, multi-million-dollar project that the firm had already attempted and abandoned three times.

The migration approach also failed because of data semantics. A “client” in the CRM was defined by a sales relationship. A “client” in the document management system was defined by an engagement contract. A “client” in the wiki was defined by an industry classification. These were not the same entity, even when they referred to the same organization. Unifying them required a semantic reconciliation layer that understood the different definitions and could map between them.

The approach: knowledge layer without migration

We built a knowledge layer that sat on top of the existing systems without replacing any of them. The knowledge layer indexed content from all forty-seven systems, reconciled the semantic differences, and provided a single search interface. The original systems continued to serve their primary users with their existing workflows. The knowledge layer served the cross-cutting need: find relevant knowledge regardless of which system it lives in.

The connector layer was the most critical component. Each of the forty-seven systems had a different interface — REST API, database view, file system export, webhook, or screen scraping for the oldest systems. The connectors were lightweight adapters that extracted content and metadata from each system and normalized it into a common ingestion format. The connectors ran on different schedules depending on the source system’s change frequency. The CRM connector ran every fifteen minutes. The shared drive connector ran nightly. The wiki connector ran on webhook notification.

The entity resolution layer reconciled the semantic differences between systems. A “client” entity in the knowledge graph was constructed by merging the CRM’s sales relationship, the document management system’s engagement contract, and the wiki’s industry classification into a single entity with multiple facets. When a partner searched for “Acme Corp engagements,” the knowledge layer returned results from all three systems, unified under a single client identity.

The knowledge graph connected entities across systems. A person entity linked to project entities they had staffed. A project entity linked to methodology entities that had been used. A methodology entity linked to the wiki pages that documented it and the templates that implemented it. This graph structure enabled queries that were impossible in any individual system: “show me consultants who have used the agile delivery methodology on financial services engagements in the last two years.”

What we gave up

The knowledge layer was eventually consistent, not immediately consistent. Content updates in source systems appeared in the knowledge layer after the next connector run. For the CRM, this was fifteen minutes. For the shared drives, this was up to twenty-four hours. Partners who needed immediate search results for newly created content had to wait for the next sync cycle or search the source system directly.

The second trade-off was search precision. The knowledge layer indexed content across systems with different metadata quality. The CRM had structured, validated metadata. The shared drives had almost no metadata — file names and folder paths were the only organizational structure. The knowledge layer’s search relevance was limited by the lowest-quality metadata in the system. Full-text search mitigated this but did not eliminate it.

The third trade-off was access control. The original systems had their own access control models. The knowledge layer had to enforce the most restrictive policy for any piece of content. If a document was visible to only senior managers in the document management system, the knowledge layer could not show it to associates, even if the CRM data about the same client was visible to everyone. The access control reconciliation was complex and required ongoing maintenance as permissions changed in source systems.

Results

Proposal preparation time dropped from three weeks to one week on average. Sixty percent of the time savings came from the unified search interface — partners could find relevant past engagements, available methodologies, and subject matter experts in a single search rather than querying multiple systems. The remaining forty percent of time savings came from the proposal assistant, which used the knowledge graph to suggest relevant content for new proposals based on client, industry, and engagement type.

Expertise discovery was the most adopted feature. Before the knowledge layer, finding a consultant with specific expertise required asking around — sending emails, calling practice leaders, checking project staffing records. The expertise finder used the knowledge graph to identify consultants based on their engagement history, methodology usage, and published content. Within six months, seventy-two percent of internal staffing requests were initiated through the expertise finder.

The decision heuristic

When your knowledge lives in many systems and your users need to search across all of them, do not migrate. Migrate only when a single system can serve every primary user better than their current system. If no such system exists, build a knowledge layer that indexes and reconciles content from existing systems without displacing them. The migration approach consolidates systems. The knowledge layer approach consolidates search. The second is faster to deliver, less disruptive to adopt, and more tolerant of the semantic differences that make migrations fail.