SearchStax Migration for Drupal Sites Leaving Acquia Search
A forced move is still a choice.
SearchStax is where Acquia is sending its search customers. Acquia Search sunsets in 2026 and SearchStax is the migration path it recommends. Solr stays underneath, so the move can be almost invisible to a visitor — which is exactly what makes it the moment to ask whether Solr is still the right answer.
SearchStax is a managed Solr service with the visibility Acquia Search never exposed. A migration no one chose gets planned like a chore, and a chore gets scoped to the smallest thing that clears the deadline. That instinct is right about the mechanics and wrong about the timing. The direct path here is narrow — Solr on both sides, no front-end change, an index that moves across with a module — so the engineering is a week of careful work rather than a quarter of it. What the deadline actually buys is the one moment in five years when someone has budget, a timeline and executive attention pointed at search. Spending all of it on parity is the expensive option, because the next time this comes up will be the next time a vendor forces it.
How the Work Splits
A managed Solr service with real visibility over it — server performance, index and data analysis, search preview and the configuration control Acquia Search never exposed — plus the Drupal modules that authenticate against it and move an existing index across.
The judgment a deadline leaves no room for. Whether Solr is still the right foundation for the people searching this site or the sunset is the moment to change it, a staged migration that proves itself in a lower environment before production sees it, and the configuration discipline that stops environment-specific settings following an index somewhere it does not belong. We have run this more than once, which mostly means we know where the week goes.
Search that survives the sunset with no front-end change, and a foundation chosen on purpose rather than inherited from whoever bought the last one. Solr where Solr is still the right engine, something else where the audience arrives with intent and a string match is the friction.
The work in practice
Acquia announced it is sunsetting Acquia Search in 2026 and named SearchStax as the recommended path off it. So this is not a migration anyone put on a roadmap. It arrived on one.
The mechanics are narrower than the anxiety
Solr is the foundation on both sides. That single fact decides most of the scope: the query behaviour a visitor experiences does not change, no front-end work is required, and the existing index moves across rather than being rebuilt from scratch. Drupal authenticates against the new service and generates its own endpoint and token configuration, and a migration module carries the index and the views that read it.
What replaces Acquia Search is more than a like-for-like swap on the administrative side. SearchStax puts a dashboard over the Solr server — performance, data analysis, search preview and configuration a team can reach without a support ticket. For most organizations that is the actual upgrade.
Where the week actually goes
Not the migration. The configuration.
Three failures show up often enough that we now go looking for them: Boost by Date processor settings that do not survive the move, highlighted-field errors that surface only when an index is rebuilt, and facet configuration that quietly differs between environments and so passes in staging and fails in production. Each one is an afternoon if it is found in a lower environment and a bad day if it is found after the switch.
So the sequence matters more than the steps. Configure and commit, deploy to development or staging, validate search behaviour and performance there, and only then push to production — with the Acquia indexes left in place afterwards as a rollback until the new ones have run clean under real traffic. The cleanup is the last step rather than part of the launch.
The question worth asking while you are in there
Solr is a capable engine and for a great many sites it remains the right one. But the reason to raise this now is not that Solr is tired. It is that the audit you would otherwise never fund is already half done — someone is looking at the index, the facets and the content model this week because they have to.
The question is what people arrive wanting. If they browse, filter and know roughly where they are going, Solr is doing the job and the migration should be exactly as boring as it looks. If they arrive with intent — a clinical question, a large catalogue, a comparison, an expectation set by everything else they search — then string matching is the friction, and this is the cheapest moment there will ever be to change the foundation. Replacing Solr with Algolia on one engagement took search response times down by 40%, and that project started as a search migration too.
That decision is yours to make, and worth making deliberately rather than by deadline. Pare & Co works through the same three questions each time: what people search for, what the content model can actually support, and whether the gap between those two is a relevance problem or an engine problem. Two of those three answers point at content rather than at software, which is usually the useful part.
Where this sits
SearchStax work sits inside Engineering & Integration alongside the Drupal practice that carries it. The step-by-step framework — the five phases, the modules and the rollback window — is written up in full in Navigating Your Drupal Solr Migration.