Enterprise Search Solutions: How to Choose and Deploy Site Search

Summary: What actually stalls an enterprise search project is almost never the retrieval algorithm — it is connecting the legacy systems that were never designed for an API. Selection means passing three elimination questions and modeling three cost lines honestly; deployment means treating the integration layer as a first-class citizen of the schedule.

When organizations select a search system, the most common approach is to spread out the feature lists of several vendors and pick whoever has the most checkmarks. The flaw in that method: a platform with fifty features you will never use is not better than one with ten features that happen to cover your real data sources.

This article reverses the order: first eliminate options down to one or two with three questions, then account honestly with three cost lines, and finally make clear where the schedule will actually be consumed.

Key Takeaways

Selection starts with three elimination questions: does search extend beyond the CMS and product catalog, does the team have the engineering depth to run a cluster long-term, and is the primary scenario e-commerce or content discovery.
The cheapest license is almost never the cheapest five-year operating cost: open-source licensing is near zero, but it takes one to three full-time engineers to operate.
Document-level security is a hidden threshold, typically 30–40% of the total build effort, not a configuration toggle.
The schedule bottleneck sits in the integration layer: middleware often decides whether you launch in six weeks or six months.
Knowledge graphs have a threshold: only above 500 employees plus 20 or more connected tools do they yield a clear gain.
Launch is not the finish line: a search platform that is not continuously tuned will silently drift within months until users stop trusting it.

1. Three Elimination Questions

Question one: does your search extend beyond the CMS and product catalog? If it also touches SharePoint, CRM, ticketing systems, and internal knowledge bases, then federated retrieval becomes a hard gate — a platform that only excels at a single data source will fight you the whole way and force you to build substantial integration work yourself.

Question two: does your team have the engineering depth to operate a distributed retrieval cluster long-term? If yes, self-hosted open source becomes credible; if no, you should stay on a managed platform. Operating a production-grade cluster spans six facets: cluster management (node sizing, shard allocation, replica configuration, rebalancing after data growth), runtime tuning, index lifecycle management, monitoring and alerting, version upgrades (requiring planned mapping compatibility and rolling restarts), and backup and recovery. For teams with existing infrastructure engineering capacity, this folds into established patterns; for teams without it, search infrastructure competes with product development for engineering time.

Question three: is your primary scenario e-commerce product search, or CMS content discovery? The two differ completely in relevance tuning and operator intervention tooling — the former needs operators who can adjust ranking, pin results, and configure rules without writing code, while the latter values federation and permissions more.

One more validation step worth writing into the process: ask any shortlisted vendor for a reference customer with a similar data scale and number of connectors, and specifically ask what their first ninety days looked like. Problems invisible on a feature sheet are all written into the ninety-day record.

2. Three Cost Lines: Don't Stare at the License Price

Procurement decisions are most easily distorted by license price. What must be modeled honestly is three lines:

Platform type	License / year	Engineering investment	Practical note
Enterprise managed platform	$200K–500K+	Lowest	Federation, security, and machine learning out of the box
Mid-tier search API	$60K–200K	Medium	Federation needs self-built integration
Self-hosted open source	License near zero, or cloud hosting $50K–300K+	Highest	Requires one to three full-time engineers to operate

The conclusion is direct: the cheapest license is almost never the cheapest five-year operating cost. The premium of an enterprise platform is often recouped through saved engineering hours; the license savings of open source only truly hold when you are already operating the same platform for adjacent workloads; the mid-tier option sits in between but its total cost climbs quickly on high-query-volume sites.

Usage-based billing must also be estimated up front: one search API's Grow plan charges roughly $0.50 per thousand searches plus about $0.40 per thousand records per month. At 5,000,000 searches per month, the managed option is about $4000+ per month, while a self-hosted cluster is about $500 per month — the annual difference is enough to hire a full-time engineer, which is exactly why self-hosting becomes economical again at scale.

Self-built cost references: a minimum viable version is about $36K–108K over 16–28 weeks; a full enterprise platform is about $180K–480K over 28–48 weeks; beyond that, ongoing model-calling and vector-storage costs are roughly $2K–15K per month in the mid-tier market.

Full self-development only makes sense in three cases: the data model is genuinely special, proprietary business logic needs to shape ranking in ways off-the-shelf tools cannot express, or the data volume and connector needs exceed what a general platform handles well. That range is far narrower than vendor marketing claims.

3. Document-Level Security: The Item Most Likely to Explode Late

Enterprise search must never surface content a user was never entitled to access in the source system. To achieve this requires permission checks per user on every query — typically the hardest engineering task in the entire stack, taking 30–40% of total build effort.

How the options actually differ varies widely and must be verified item by item:

Open-source retrieval cluster: document-level security usually requires a paid high-tier layer (hundreds of dollars per node per month, before cluster scale). Without it, all documents live in a shared index and cannot enforce per-document access control at query time. Organizations with complex permission models either pay the premium or build their own with filtered aliases and per-user query filters — a sizable custom engineering effort.
Search-API class: permissions are implemented with secure keys carrying embedded filters. Simple hierarchies work, but they collapse when permissions come from nested directory group membership — a user's effective access depends on which groups they belong to, which groups those groups belong to, and which groups are explicitly denied. Mapping that hierarchy into a filter needs custom middleware, and group membership must be recomputed on every change. An organization that reaches this point has effectively already walked most of the self-built path.
Cloud vendor managed search: document-level permissions on some platforms were still in preview as of mid-2026, and native capability covers only the vendor's own storage products. Organizations with documents scattered across other clouds or on-prem file shares must build their own permission-push pipeline, which cancels most of the managed service's benefit.

One more hard constraint is easy to overlook: some search APIs offer no self-hosting option, so all data must remain on the vendor cloud. For organizations with data-sovereignty requirements, on-prem deployment, or isolated-network environments, such options are disqualified outright.

4. Where the Schedule Actually Goes

A counterintuitive but repeatedly verified fact: projects almost never stall on the retrieval algorithm itself; they almost always stall when connecting legacy CRM, ERP, or content-management systems that were never designed with an API in mind.

So the budget must treat integration work as equally important as the software license, not as an afterthought. Connectors for mainstream SaaS are usually straightforward because the platforms provide mature APIs; it is the legacy ERP, older intranet document systems, and in-house intranets that blow up the timeline.

The middleware or self-built connector layer is often the difference between launching in six weeks and launching in six months. This point should be stress-tested with vendors before signing, not discovered after deployment begins.

5. A Seven-Step Deployment Path

The timeline shifts with data volume and legacy-system complexity, but this order is worth planning around:

Assess — inventory every data source, its owner, and its current permission model
Data audit — before content enters the index, flag duplicate, stale, or conflicting content
Build connectors — build or configure a connector for each data source, starting with the highest-value systems
Index — content is crawled, extracted, and organized into a retrievable index
Permission test — verify per user whether search results strictly honor existing access rules
Pilot users — open first to a small group whose data is genuinely messy, and tune relevance on real queries
Go live — roll out fully, name a specific content owner, and establish a rhythm of regularly reviewing zero-result queries

Step 6's "start with the small group whose data is messiest" is deliberate — good results on clean data prove nothing about real-world usability. Step 7's regular review mechanism is the key to preventing silent drift after launch.

6. Two Recurring Mistakes

Treating it as a one-time indexing project. Data sources keep changing; a search platform that is not monitored and re-tuned after launch will silently drift out of relevance within months, only noticed once users stop trusting it. Search is not a deliverable; it is a capability that needs continuous operation.

Underestimating permission complexity. Getting document-level access control wrong is not a small bug — it is a data-exposure incident. This item is underestimated in schedule estimates at a rate possibly higher than all others combined.

7. One Optional Component: Should You Adopt a Knowledge Graph

A knowledge graph is not standard equipment. The empirical threshold is: only above 500 employees and with 20 or more connected tools does the graph layer substantially improve search quality; below that scale, hybrid semantic retrieval alone is enough.

If you truly need one, common backends include Neo4j, TigerGraph, and Neptune, while entity extraction requires a supporting machine-learning pipeline. The criterion simplifies to one sentence: do your queries frequently involve "which component did someone use in a certain person's project" — cross-entity relationship questions of that kind? If yes, it is worth the investment; otherwise, start with hybrid retrieval.

FAQ

Q: How do we choose between building and buying?

A: Look at two conditions. First, does the team have the engineering depth to operate a distributed cluster long-term — if not, do not build it yourself, because production-grade operational complexity should not be discovered in production; second, does the workload extend beyond search itself (log analysis, observability, security monitoring, and so on) — if so, building one multi-purpose cluster is more economical. Beyond that, most organizations should start from a mature platform. The scenarios where self-development truly makes sense are narrow: a special data model, ranking logic that cannot be expressed with off-the-shelf tools, or scale that already exceeds general platforms.

Q: Why is open source cheap on license but potentially more expensive in total cost?

A: Because the saved license fee is eaten by engineering hours. Operating a production-grade cluster spans six facets — cluster management, runtime tuning, index lifecycle management, monitoring and alerting, version upgrades, and backup and recovery — typically requiring one to three full-time engineers. So the criterion is: are you already operating the same platform for other workloads? If yes, the marginal cost is low and open source is extremely cost-effective; otherwise it is a brand-new personnel expense. A rough conversion reference: at 5,000,000 searches per month, the monthly gap between managed and self-hosted is on the order of several thousand dollars, and the annual difference is enough to hire a full-time engineer — a threshold worth calculating yourself.

Q: Why is document-level permission so hard?

A: Because permissions are rarely flat. In a real enterprise, a user's effective access depends on which groups they belong to, which groups those groups nest within, and which groups are explicitly denied. Expressing that relationship correctly at retrieval time requires per-user verification of the source system's access-control list on every query, not simply tagging a document. This takes 30–40% of the total build effort, and is also the easiest point to gloss over during selection with a single line of "we support document-level security" — be sure to ask which data sources it covers and how nested groups are handled.

Q: How long does implementation usually take?

A: It depends on data volume and legacy-system complexity. A minimum viable self-built version is about 16–28 weeks, and a full enterprise platform about 28–48 weeks; adopting a mature platform, if the data sources are mostly mainstream SaaS, can launch on the order of six weeks; once legacy ERP, older intranet document systems, or in-house systems are involved, the timeline easily stretches to the order of six months. The gap comes mainly from the integration layer, so during evaluation the connector work should be estimated on its own rather than lumped into "configuration."

Q: Is ongoing investment needed after launch?

A: Yes, and it is the item most easily omitted from the budget. Data sources keep changing; if retrieval relevance is not re-tuned, it will silently drift within months, only noticed once users stop trusting it. The recommended mechanism: name a specific content owner, establish a rhythm of regularly reviewing zero-result queries, and run periodic regression checks on the relevance of high-value queries. Treating search as a one-time deliverable is the leading cause of post-launch failure.

Q: Do multi-region, multi-language searches need separate indexes?

A: It depends on whether retrieval behavior truly diverges by region. If each market differs greatly in language, products, and content, separate indexes (or at least independent analyzers and synonym dictionaries) usually work better; if the difference is mainly at the interface layer, a shared index with regional filtering suffices. The real decision point is query semantics: does the same word point to different intents in different markets? Also note that permission models may have compliance differences across regions, which deserves separate design more than the index structure does.

About Tengence

Tengence Search is Tengence's product line for enterprise site search and enterprise search, covering federated ingestion, hybrid retrieval, permission filtering, and performance operations — helping enterprises turn search from a one-time deliverable into a sustainably tunable capability. Tengence (TENGENCE) is an enterprise growth engine for the AI era, focused on public-traffic acquisition and private-domain conversion.

Data Sources

Enterprise Search Software: Features, Benefits & How to Choose——Elsner Technologies: the argument that ranking by feature count is invalid and the method of verifying with a reference customer's ninety-day record; projects stall on legacy-system connections rather than algorithms; the seven-step implementation path; two common mistakes.
Coveo vs Algolia vs Elasticsearch——Sengo: the three elimination questions; the three TCO cost lines (enterprise $200K–500K+ / mid-tier $60K–200K / open source near-zero license but one to three engineers); trade-offs across federation, document-level security, and vector retrieval.
Enterprise Search Software Cost——Raft Labs: the real threshold of document-level security (Platinum tier, nested AD group collapse, Azure DLS still in preview); Algolia $0.50 per thousand + $0.40 per thousand records; data-sovereignty constraints; Elasticsearch query DSL unfriendly to non-technical admins.
Enterprise Search & Knowledge Graphs: Guide 2026——ITD GrowthLabs: the seven layers of a modern search stack; permission-aware retrieval at 30–40% of build effort; knowledge-graph threshold (500 employees + 20 tools); self-build cost ranges and timelines.
Algolia vs Elasticsearch: Search API Showdown 2026——APIScout: six categories of self-hosted cluster operations; at five million per month managed $4000+/month vs self-hosted $500/month; the applicability boundaries and two decision questions of the two platforms.