The inevitable GSA migration: How to smoothly transition your search service

With Google announcing the retirement of their Google Search Appliance (GSA) solution, we examine different migration options for its current users.

Google recently announced that they are winding up sales of their Google Search Appliance (GSA) solution, phasing out the product and existing contracts over the next three years.

By 2018, no renewals or updates will be offered and the striking yellow Google branded search servers, installed in rack rooms around the world, will become nothing more than redundant hardware.

With no alternative being immediately offered from Google, we examine several opportunities open to current GSA users to review their future search strategy.

Search solution migration options would generally fit into one of the following three categories, described below in more detail:

  1. Like for like
  2. Replicate, review and revise
  3. Replace, relocate and reposition

Option 1: Like for Like

Your organization’s current solution might work fine - some minor configuration has been performed over the years, and custom components have been avoided.  It works - but it’s about to die.

This scenario is best suited to a ‘lift and shift’ approach - automatically converting your Google Search Appliance’s include/exclude patterns, synonyms, keymatches, blacklisting, user interfaces and outputs.  No downtime is necessary, and your two systems can be operating in parallel for a period to aid in the transition.

You’ve bought yourself a new lease on search life, but you haven’t necessarily improved the overall experience.

Product Terminology Changes

Even with a like for like replacement, there will still be some differences in terminology used between products.  Is your replacement system working with front-ends or templates?  Scopes or sites? Keymatches or Curators? Queries or keywords? GoogleOff or NoIndex? Synonyms or query expansions? Onebox or ExtraSearch? Faceted search or dynamic navigation?

These issues are not insurmountable, but it’s worth setting aside some time to allow your search team to get familiar with new terminology.

Option 2: Replicate, Review and Revise

For a risk-averse organization, significant changes to search capabilities may be hard to introduce all at once.  Gradually introducing new features may be a better approach, once the initial migration has concluded.  General areas worth focusing on at this time include:


For each collection type, you’ll need to export your inclusion and exclusion patterns.  At its simplest level, this is a set of URLs and/or URL patterns that will inform your new search engine what it needs to include in its index (and what it needs to ignore).

It’s likely that these repositories and inclusion / exclusion patterns have stagnated over time - sites and content sections may have died, moved, been renamed or may no longer be useful.  Now you’ll have a good opportunity to review and update those inclusion and exclusion patterns. Funnelback’s Content Auditor can provide you with a bird’s eye view on exactly what’s being indexed, and allow you to adjust gathering patterns accordingly.


Replacing a search solution also involves a careful examination of downstream services and applications that may be using the search platform.  Not all of these will be known to a search administrator, but you can expect that those platforms’ owners will be quick to complain when their search integration breaks.

Auditing those integrations is a good starting point.  You’ll be unlikely to make the transition completely seamless if you require the owners of those applications or repositories to do any additional work to reconfigure their existing systems to work with the replacement search platform. The same endpoints, at the same locations, using the same syntax, should continue to respond in the same format.

Combining all of this information in table form will assist in your migration:




Integration Method



Drupal Module



Drupal Module




Other RESTful Integration points

Integration expectations of connected systems may also have evolved since your initial search deployment.  It might be appropriate to move to lightweight JSON responses to search requests and update APIs, or advertise the existence of XML and RSS endpoints for consumption elsewhere in the enterprise.


Google’s own ranking algorithm is infamously opaque - when using a replacement product’s ‘relevance’ sorting algorithm, you’ll need to be prepared for some variations for commonly-run queries.

One exception to this rule is the replication of the ‘Keymatch’ functionality in the GSA.  Direct keyword to URL mappings should be able to be migrated automatically to the new target system, providing a degree of consistency in the manually-configured edge cases for manipulated search results.

Benchmarking Ranking

It’s unrealistic to expect a replacement product to identically match the ranking order, but it’s a good opportunity to examine what you believe the ‘best’ results should be for known search queries:

Search Query

Best Answer 1

Best Answer 2



This set of expert-authored questions and answers can be used to train a search engine’s weighting behaviours.  In this way, you’ll be able to retain control of ranking behaviours.

Extending Functionality

Once you’ve got the softer issues addressed, you should start to expect more from your search solution than just gathering, indexing and querying.  For example, you could use your new search engine to start delivering:

  1. New collection types (e.g. official Social Media channels)
  2. New gathering methods (e.g. should you push, pull or a combination of both?)
  3. New ranking behaviours (e.g. who gets to define relevance?)
  4. New user interfaces (responsive designs, native mobile apps)
  5. New integrations (search suggestions,  / recommended content)
  6. New insights (index enrichment, natural language processing, answer visualisation)

There may be some repositories or content types that you’ve always wanted to include in your search index, but they simply haven’t been supported by your search appliance.

Your replacement platform should allow you to revisit those requirements, providing extensibility at connector, gather and filter levels.  Similarly, your document licence limit may have prevented you from gathering all that you wanted, or you may have had duplicate documents counting towards that limit.

Option 3: Replace, Relocate and Reposition

It’s possible that your GSA box has been gradually drifting out of alignment with the content, use cases and business goals that justified the initial purchase.  Now would be an excellent time to re-evaluate what your current and future search and content processing goals are.

Your users’ expectations of search have probably surpassed what the GSA is capable of delivering.  Your IT team may be willing to experiment with hybrid cloud / on-premises services, and your content authors are struggling to make sense of the mountain of information that they’ve created and are building on daily.  Ensure your new search solution is capable of supporting the current and future state.


  • Does an on-premises search solution still make sense?
  • Are there a subset of search indexes suitable for cloud hosting?
  • Is a private cloud search solution suitable?
  • Does your IT team have a preferred hosting platform or O/S?
  • What support options am I likely to need from my search provider?

Gartner’s focus on Insight Engines positions search engines as a platform on which to construct higher-value applications, natural language processing, content tools and analysis dashboards.  A replacement search platform should be capable of delivering these value-adding services.

Entity Extraction and Document Classification

With minimal training, indexes of content in unstructured documents can be enriched to identify themes, sentiment, locations, people and organizations.

Transparent Ranking

With an increased reliance on search to deliver insights, users expect a level of traceability and transparency when ‘answers’ or content are deemed to be the best or most relevant.  Exposing the decisions and weightings that lead to these recommendations provides a users with greater degree of confidence (and control over) the search experience.

Content Auditing and Analysis

Few tools inside an organization have greater visibility on the breadth and depth of content created, used, queried and published by users.  Leveraging this level of visibility to identify patterns and cross-references between items reveals publishing activities, subject areas and content themes and the corresponding regions to ignore, replace or enhance.

Developer-Friendly APIs

Ensure search can talk to everything it needs to - without having to customise your search platform.  Ask for (and expect) open, well-documented, interoperable standards for pushing content to search at scale whilst simultaneously extracting all the responses, answers and insights required.

Reposition Search from an Appliance to a Platform

A mindshift may be required - rethinking search as a core component in your organization’s technology stack requires treating the solution (and the insights it can empower) as a first-class member of your organization’s IT service offerings.

Any legacy (or proposed) content and publishing systems should also be considering how (not if) it will be able to contribute to and leverage from this platform.

We’ve done this before

Funnelback have already helped multiple clients who range in size and industry make the switch from GSA and step into a world of more intelligent and analytical search. With an unblemished record of seamless migrations and a string of happy clients to match, you’re in very safe hands.

Download our feature by feature comparison to see how we compare, and how we can help you with your migration plans and open up a whole new world of search.

Share Article on: