Planning guide for text search services

Use this planning guide to select a text search service for a new deployment and to plan a migration from Content Search Services to Elasticsearch or OpenSearch for an existing deployment.

Note: In ACCE and in this documentation, the term Elasticsearch refers to both Elasticsearch and OpenSearch services.

Before you begin

Use the topic to help decide which text search service to use for new deployments and how to plan migration for existing deployments. For migration planning, use dual mode indexing only when both Content Search Services and Elasticsearch or OpenSearch support the selected languages for your object store.

For quick navigation, review the following questions in order:

Question 1: Are you planning a new deployment or updating an existing one?

Start by determining whether you are selecting a text search service for a new deployment or planning changes for an existing deployment. Elasticsearch or OpenSearch is the recommended search service for almost all new deployments because it provides modern search algorithms and reduces the risk of index corruption compared to Content Search Services.

Option What to do
You are planning a new deployment Use Elasticsearch or OpenSearch as the text search service for the object stores that you create. Before you proceed, verify that the selected analyzers support the languages that you need.
You already use Content Search Services Go to Question 2 to determine the migration approach that best fits your environment.

Question 2: If you already use Content Search Services, how much content is indexed?

If you already use Content Search Services, choose a migration approach based on the scale of the existing indexes.

Environment size Recommended approach
Several million documents or fewer If you have several million documents or fewer indexed in Content Search Services, start fresh with object stores that use Elasticsearch or OpenSearch. Then reindex the content into those object stores. This approach usually works better at this scale.
Hundreds of millions of documents Plan a staged migration by using dual mode indexing. Place individual object stores into dual mode, and use the full-text reindex job sweep to move previously indexed content to Elasticsearch or OpenSearch without creating redundant indexing requests in Content Search Services.
Billions of documents Migrate only a subset of content when full migration is not practical. Use filter expressions with the full-text reindex job sweep to target the content that provides the highest value for migration.

Question 3: If you are planning a migration, do you need to migrate all content or only a subset?

For existing deployments, decide whether you need to migrate all indexed content or only selected content. If your environment contains a very large number of indexed documents, migrating all content might not be practical because of the time and storage that are required.

Option What to do
You need to migrate all content Use dual mode indexing and continue to run both services until all required content is indexed in Elasticsearch or OpenSearch. After you verify search behavior, remove Content Search Services from the object store configuration.
You need to migrate only recent or high-value content Use a filter expression with the full-text reindex job sweep to migrate only the content that matches defined criteria, such as documents that were created in the last 3 years.

For example, the following filter expression selects documents that were created after 1 September 2023:

DateCreated > 20230901T070000Z

Question 4: If you are planning a migration, how can you improve migration efficiency?

For migration projects where you use a filter expression to select content, consider creating a database index on the DocVersion table for each object store that you filter on. This index improves the efficiency of identifying candidate documents for the reindex job.

In ACCE, you can create the database index from Data Design > Table Definitions > DocVersion > Indexes > Add. If you migrate content by creation date, consider adding an index on the create_date field.

You can also use the preview and counters option with the filter expression to estimate how many documents are selected for migration. After you determine the average time that is needed to index a batch, you can estimate the overall migration duration.

Related topics