Migrate to Turing
Switching from Algolia or Elasticsearch is one command
Keep the faceted, typo-tolerant search your team relies on, add RAG, cited chat and agents, and run it all on your own infrastructure. No rewrite, no lock-in, no per-record bill.
Point it at your live index
turing migrate reads your Elasticsearch mappings or Algolia settings, turns them into a Turing schema, and streams the records across in a single step. And it's cautious by design:
Preview before you commit
--dry-run shows the schema Turing derived. Nothing is written until you're happy with it.
Prove parity, then cut over
compare replays your real queries against both engines and reports the relevance difference.
Reshape fields on the way in
--overrides-file renames, retypes or drops any field, and your source index stays unchanged.
# Elasticsearch: mappings → schema, docs imported
turing migrate elasticsearch \
--index products --site Products
# Algolia: --use-llm infers types for schemaless data
turing migrate algolia \
--index catalog --site Catalog --use-llmEverything you rely on carries over
The concepts map almost one-to-one. Where a hosted feature is paid, beta or vendor-locked, Turing ships the equivalent in the box, on the search engine you already operate.
| Concept | Algolia | Elasticsearch | Viglet Turing |
|---|---|---|---|
| Where documents live | Index | Index | Semantic Navigation (SN) site |
| A single record | Record (JSON object) | Document (_source) | Document, indexed via REST or a connector |
| Schema & field config | Index settings (searchableAttributes…) | Mappings | Field manifest as code (POST /api/sn/manifest) |
| Faceting | attributesForFaceting | Aggregations | Native facet fields, no extra query DSL |
| Typo tolerance | typoTolerance | Fuzzy queries | Typo-tolerant + spell-check in the box |
| Synonyms | Synonyms API | Synonym token filter | Engine synonyms (Solr / Elasticsearch) |
| Semantic / vector search | NeuralSearch (paid add-on) | kNN over dense_vector | Embedded Lucene KNN or your engine's vectors, fused via hybrid RRF |
| Relevance tuning | Custom ranking + tie-breaking | BM25 + function_score | BM25 + opt-in hybrid RRF (keyword + vector) |
| AI answers over your content | Ask AI (hosted beta) | ELSER + your own LLM glue | RAG, cited chat & agents built in |
| Front-end UI | InstantSearch.js / React | Build it (elasticsearch-js) | React SDK + zero-dep vanilla-JS SDK (headless) |
| Query API | Hosted search API | _search DSL | POST /api/sn/{site}/search on your host |
| Hosting & data residency | Fully hosted SaaS | Elastic Cloud or self-managed | Self-hosted: content & embeddings never leave your infra |
High-level mapping as of 2026; verify current vendor capabilities.
And you come out ahead
The same search, plus hybrid ranking
Faceting, typo tolerance and synonyms carry over, with hybrid keyword + vector ranking on top.
AI answers, no glue code
RAG, cited chat and agents over your own content ship in the box, with nothing to assemble or host separately.
Your front-end barely changes
Swap InstantSearch or elasticsearch-js for the React or zero-dependency vanilla-JS SDK. The same UI, on your infra.
And your data never leaves your network
A hosted SaaS keeps your index, and increasingly your users' queries, in someone else's cloud. Turing runs on your own hardware: documents, embeddings and query logs stay put.
- Self-hosted under Apache 2.0
- Content & embeddings stay on-prem
- Bring your own LLM & search engine
- No per-record or per-search billing