Such-Migration von Solr zu Elasticsearch/OpenSearch

1. Warum die Such-Migration von Solr unausweichlich ist

Viele Magento-Shops, die urspruenglich auf Magento 1 oder in einer frueheren Magento-2-Version aufgesetzt wurden, laufen noch heute mit Apache Solr als Suchtechnologie. Solr war lange Zeit die Standardloesung, wurde aber mit Magento 2.4 offiziell durch Elasticsearch, mittlerweile ergaenzt durch OpenSearch, ersetzt. Fuer diese Shops ist die Such-Migration von Solr keine Option mehr, sondern eine Frage der Zeit, weil aeltere Magento-Versionen zunehmend aus dem Support-Zyklus fallen und Sicherheitsupdates ausbleiben.

Die Such-Migration von Solr zu Elasticsearch ist technisch anspruchsvoller, als viele Teams zunaechst annehmen. Es geht nicht nur um den Austausch einer Konfigurationszeile, sondern um ein fundamental anderes Schema-Modell, andere Query-Syntax und ein anderes Relevanz-Scoring-System. Wer diese Unterschiede unterschaetzt, riskiert nach der Migration eine Suche, die zwar technisch funktioniert, aber spuerbar schlechtere Ergebnisse liefert als das alte Solr-Setup.

Dieser Artikel richtet sich an Teams, die vor genau dieser Such-Migration stehen. Er deckt die technische Vorbereitung, das Schema-Mapping, die Reindex-Strategie, Testverfahren und einen konkreten Rollback-Plan ab, damit die Umstellung kontrolliert und mit minimalem Risiko fuer den laufenden Betrieb erfolgen kann.

2. Solr End-of-Life in Magento: der technische Hintergrund

Magento unterstuetzte Solr ueber ein separates Modul, das eng an die damalige Magento-Architektur gekoppelt war. Mit der Einfuehrung von Elasticsearch als Standard-Suchengine in Magento 2.1 und der schrittweisen Vertiefung der Integration bis Magento 2.4 wurde Solr zunaechst parallel unterstuetzt, dann als deprecated markiert, und schliesslich vollstaendig aus dem Core entfernt. Seither existiert keine offizielle Solr-Unterstuetzung mehr, und Community-Erweiterungen, die Solr nachruesten, laufen ausserhalb des offiziellen Support-Rahmens.

Der technische Grund fuer diesen Wechsel liegt in der Architektur: Elasticsearch bietet eine modernere, RESTful-JSON-basierte API, bessere horizontale Skalierbarkeit durch Sharding, und eine aktivere Weiterentwicklung im Vergleich zu Solr, dessen Entwicklungsgeschwindigkeit in den letzten Jahren nachliess. Fuer Magento als Plattform bedeutete das, langfristig auf die Technologie mit der aktiveren Community und dem staerkeren Cloud-Oekosystem zu setzen. Fuer Haendler bedeutet es, dass die Such-Migration weg von Solr keine kurzfristige Modeerscheinung ist, sondern eine dauerhafte Plattformentscheidung von Magento selbst.

3. Migrations-Checkliste: Vorbereitung und Bestandsaufnahme

Vor jeder Such-Migration steht eine vollstaendige Bestandsaufnahme des aktuellen Solr-Setups. Dazu gehoert die Liste aller in Solr indexierten Attribute inklusive ihrer Solr-Feldtypen, alle Custom-Boosting-Regeln, alle konfigurierten Synonym- und Stopwort-Listen, sowie jede Custom-Erweiterung, die direkt mit der Solr-Query-Schnittstelle interagiert. Ohne diese Inventarisierung geraet die Migration schnell unvollstaendig, weil Legacy-Anpassungen unbemerkt verloren gehen.

Ein zweiter wichtiger Schritt der Checkliste ist die Dokumentation des aktuellen Sucherverhaltens als Referenzpunkt. Dazu gehoert eine Liste typischer Suchanfragen mit den jeweils erwarteten Top-Ergebnissen, um nach der Migration eine objektive Vergleichsbasis zu haben. Ohne eine solche Baseline bleibt die Frage "ist die neue Suche genauso gut wie die alte" reine Subjektivitaet, was insbesondere bei der Abnahme durch Stakeholder ohne technischen Hintergrund zu endlosen Diskussionen fuehren kann.

# Inventory: export current Solr schema fields for reference
curl -s "http://solr-host:8983/solr/magento/schema/fields?wt=json" | jq '.fields[] | {name, type}'

# Inventory: list all custom search-related extensions in the codebase
grep -rl "Solr" app/code/ --include="*.php" | sort

# Document baseline search behavior for later comparison
echo "laufschuh,kuehlschrank,notebook" | tr ',' '\n' > baseline_queries.txt

4. Schema-Mapping: Solr-Felder auf Elasticsearch uebertragen

Solr arbeitet mit einem expliziten, in schema.xml definierten Feldschema, in dem jeder Feldtyp (text_general, string, tint, und aehnliche) explizit deklariert wird. Elasticsearch dagegen nutzt standardmaessig dynamisches Mapping, das Feldtypen automatisch aus den ersten eingehenden Dokumenten ableitet, unterstuetzt aber auch explizite Mappings fuer praezise Kontrolle. Fuer eine saubere Such-Migration sollte jedes Solr-Feld bewusst auf einen Elasticsearch-Feldtyp uebertragen werden, statt sich auf automatisches Mapping zu verlassen, weil Fehlinterpretationen bei dynamischem Mapping schwer nachtraeglich zu korrigieren sind.

Besondere Aufmerksamkeit verdienen Textfelder mit Sprachanalyse. Solrs text_general-Feldtyp mit deutschem Stemmer entspricht in Elasticsearch einem text-Feld mit einem Analyzer, der einen german_stemmer-Filter nutzt. Facettierbare Attribute, die in Solr oft als string deklariert sind, sollten in Elasticsearch als keyword-Feld abgebildet werden, um exakte Filterung ohne Analyse zu ermoeglichen. Diese Unterscheidung zwischen text und keyword existiert in Solr in dieser Form nicht direkt und ist eine der haeufigsten Quellen fuer unerwartetes Verhalten nach der Such-Migration.

{
  "mappings": {
    "properties": {
      "name": { "type": "text", "analyzer": "german_analyzer" },
      "sku": { "type": "keyword" },
      "description": { "type": "text", "analyzer": "german_analyzer" },
      "color": { "type": "keyword" },
      "price": { "type": "scaled_float", "scaling_factor": 100 },
      "visibility": { "type": "integer" },
      "categories": { "type": "keyword" }
    }
  }
}
// Corresponds to Solr schema fields:
// name (text_general) -> text with custom analyzer
// sku (string)         -> keyword (exact match, no analysis)
// color (string, facet)-> keyword
// price (tfloat)       -> scaled_float for exact price comparisons

5. Config-Umstellung in Magento

Nach Abschluss von Inventarisierung und Schema-Mapping folgt die eigentliche Umstellung der Magento-Konfiguration. Der Suchengine-Schluessel in app/etc/env.php wird von solr auf elasticsearch7 geaendert, und die zugehoerigen Server-Parameter (Host, Port, Index-Praefix) werden ueber die Admin-Konfiguration oder direkt per CLI gesetzt. Da die Magento-Core-Unterstuetzung fuer Solr entfernt wurde, laesst sich diese Umstellung nicht schrittweise innerhalb derselben Magento-Version testen, sondern setzt in der Regel voraus, dass parallel dazu auch ein Magento-Upgrade auf eine Version ohne Solr-Support stattfindet.

Fuer Shops, die noch auf einer aelteren Magento-Version mit Solr-Support laufen, empfiehlt sich, die Such-Migration in zwei getrennten Schritten durchzufuehren: zunaechst der Wechsel der Suchengine auf einer Version, die beide Engines unterstuetzt, um das neue Setup unter realer Last zu validieren, und erst danach das eigentliche Magento-Upgrade. Dieses Vorgehen reduziert das Risiko, zwei grosse Veraenderungen (Suchmigration und Plattform-Upgrade) gleichzeitig debuggen zu muessen.

# Switch the search engine from Solr to Elasticsearch
bin/magento config:set catalog/search/engine elasticsearch7
bin/magento config:set catalog/search/elasticsearch7_server_hostname elasticsearch
bin/magento config:set catalog/search/elasticsearch7_server_port 9200
bin/magento config:set catalog/search/elasticsearch7_index_prefix magento2

# Clear cache and trigger the first full reindex on the new engine
bin/magento cache:flush
bin/magento indexer:reindex catalogsearch_fulltext

6. Reindex-Strategie und Downtime-Planung

Der erste vollstaendige Reindex nach der Such-Migration baut den kompletten Elasticsearch-Index von Grund auf neu auf, was bei grossen Katalogen erhebliche Zeit in Anspruch nehmen kann. Es empfiehlt sich, diesen initialen Reindex in einer Staging-Umgebung durchzufuehren und die tatsaechliche Laufzeit zu messen, um ein realistisches Wartungsfenster fuer die Produktionsumstellung zu planen. Parallel dazu sollte der alte Solr-Index bis zur endgueltigen Bestaetigung des neuen Setups nicht geloescht werden, um im Zweifel schnell zurueckwechseln zu koennen.

Fuer Shops, die eine Downtime nicht akzeptieren koennen, ist ein Blue-Green-Ansatz sinnvoll: Ein zweites, identisches Magento-System wird auf Elasticsearch umgestellt und vollstaendig getestet, waehrend das Produktivsystem weiterhin mit Solr laeuft. Erst nach erfolgreicher Validierung wird der Traffic per Load-Balancer-Umschaltung auf das neue System geleitet. Dieser Ansatz erhoeht den Infrastrukturaufwand waehrend der Such-Migration, minimiert aber das Risiko einer sichtbaren Downtime fuer Endkunden erheblich.

7. Testing und Ergebnis-Parity-Pruefung

Die in Abschnitt 3 dokumentierte Baseline an typischen Suchanfragen bildet die Grundlage fuer die Parity-Pruefung nach der Migration. Fuer jede Referenzanfrage wird verglichen, ob die Top-Ergebnisse in Elasticsearch denen in Solr in Reihenfolge und Relevanz weitgehend entsprechen. Vollstaendige Identitaet ist dabei kein realistisches Ziel, weil Solr und Elasticsearch unterschiedliche Relevanz-Scoring-Algorithmen nutzen (Solr traditionell TF-IDF-basiert, Elasticsearch standardmaessig BM25), aber grobe Abweichungen in der Trefferreihenfolge deuten auf ein fehlerhaftes Schema-Mapping oder fehlende Boost-Konfiguration hin.

Neben dem reinen Ergebnisvergleich gehoert automatisiertes Testing zur soliden Such-Migration: ein Testskript, das die Baseline-Queries gegen beide Systeme parallel ausfuehrt und Abweichungen in Trefferzahl und Top-5-Ergebnissen automatisch markiert. Solche Tests sollten Teil der Staging-Pipeline werden und vor der finalen Produktionsumstellung erneut durchlaufen, um sicherzustellen, dass zwischenzeitliche Konfigurationsaenderungen keine Regression eingefuehrt haben.

#!/usr/bin/env bash
# parity-test.sh - compare Solr and Elasticsearch results for baseline queries
set -euo pipefail

while read -r query; do
  solr_count=$(curl -s "http://solr-host:8983/solr/magento/select?q=${query}&wt=json" \
    | jq '.response.numFound')
  es_count=$(curl -s -X POST "localhost:9200/magento2_default_catalogsearch_fulltext_1/_search" \
    -H "Content-Type: application/json" \
    -d "{\"query\":{\"match\":{\"name\":\"${query}\"}}}" \
    | jq '.hits.total.value')

  echo "Query: ${query} | Solr: ${solr_count} | Elasticsearch: ${es_count}"
  if [[ "$solr_count" != "$es_count" ]]; then
    echo "  WARNING: result count mismatch, investigate mapping or boosting"
  fi
done < baseline_queries.txt

8. Haeufige Fallstricke bei der Migration

Der haeufigste Fallstrick ist das Vergessen custom-konfigurierter Solr-Synonyme und Stopwort-Listen. Diese liegen in Solr typischerweise als eigene Textdateien (synonyms.txt, stopwords.txt) im Konfigurationsverzeichnis und werden bei der reinen Konfigurationsumstellung nicht automatisch mitgenommen. Ohne explizite Uebertragung in die Elasticsearch-Analyzer-Konfiguration verschwinden diese Anpassungen stillschweigend, was zu einer Such-Migration fuehrt, die technisch funktioniert, aber Jahre an aufgebautem Relevanz-Tuning verliert.

Ein zweiter haeufiger Fallstrick ist verlorenes Custom-Boosting. Solr-Setups enthalten oft handgepflegte Boost-Regeln fuer bestimmte Kategorien, Marken oder Attribute, die in individuellem PHP-Code oder Solr-Konfigurationsdateien verankert sind. Diese Regeln haben in Elasticsearch kein automatisches Aequivalent und muessen manuell als function_score-Komponenten in der Query-Logik nachgebaut werden. Ein dritter Fallstrick betrifft Custom-Erweiterungen, die direkt gegen die Solr-Client-Bibliothek programmiert wurden: Diese muessen vollstaendig neu implementiert werden, da die zugrunde liegenden PHP-Clients fuer Solr und Elasticsearch vollkommen unterschiedliche APIs bieten.

9. Rollback-Plan fuer den Ernstfall

Auch bei sorgfaeltiger Vorbereitung sollte jede Such-Migration einen dokumentierten Rollback-Plan haben. Die einfachste Absicherung ist, den Solr-Index und die zugehoerige Infrastruktur bis mindestens zwei Wochen nach der Produktionsumstellung aktiv und aktuell zu halten, statt ihn sofort abzuschalten. So laesst sich im Fall gravierender, erst in Produktion sichtbarer Probleme innerhalb weniger Minuten auf Solr zurueckschalten, indem die Suchengine-Konfiguration einfach zurueckgesetzt wird.

Wichtig fuer einen funktionierenden Rollback ist, dass der Solr-Index waehrend der Uebergangsphase weiterhin synchron mit Produktaenderungen gehalten wird, nicht nur der Elasticsearch-Index. Andernfalls liefert ein Rollback zwar eine funktionierende Suche, aber mit veralteten Produktdaten. Der Rollback-Plan sollte zudem klar definierte Entscheidungskriterien enthalten: Welche Fehlerquote, welche Nutzerbeschwerden oder welche Performance-Abweichung loesen den Rollback konkret aus, statt diese Entscheidung im Ernstfall spontan treffen zu muessen.

# Rollback procedure: revert search engine configuration to Solr
bin/magento config:set catalog/search/engine solr
bin/magento config:set catalog/search/solr_server_hostname solr-host
bin/magento config:set catalog/search/solr_server_port 8983

# Clear cache so the reverted configuration takes effect immediately
bin/magento cache:flush

# Verify the active engine after rollback
bin/magento config:show catalog/search/engine

10. Zusammenfassung

Die Such-Migration von Solr zu Elasticsearch oder OpenSearch ist fuer alle Magento-Shops, die noch auf Legacy-Solr-Setups laufen, unausweichlich, aber technisch komplexer als eine reine Konfigurationsaenderung. Sie erfordert eine vollstaendige Inventarisierung des bestehenden Solr-Schemas, ein bewusstes Feld-Mapping auf Elasticsearch-Typen, insbesondere die Unterscheidung zwischen text und keyword, sowie die manuelle Rekonstruktion von Synonymen, Stopwords und Custom-Boosting, die in Solr oft ueber Jahre gewachsen sind.

Eine strukturierte Checkliste, eine dokumentierte Baseline fuer Ergebnis-Parity-Tests und ein klar definierter Rollback-Plan reduzieren das Risiko der Umstellung erheblich. Wer diese Schritte konsequent durchlaeuft, statt die Such-Migration als reinen Infrastrukturwechsel zu behandeln, erhaelt am Ende eine Suche, die nicht nur technisch aktuell ist, sondern auch die Relevanz-Qualitaet des alten Solr-Setups erreicht oder uebertrifft.

11. FAQ: Such-Migration von Solr zu Elasticsearch