Feature Pack 7 or later

Migrating WebSphere Commerce search

To migrate from Feature Pack 2, 3, 4, 5, or 6 BOD-based search deployment to Feature Pack 7 or later REST-based model follow this procedure.

Feature Pack 8 provides a significant upgrade to search architecture that was introduced in Feature Pack 7. You are recommended to migrate to Feature Pack 8 from any earlier Feature Pack.

In Feature Pack 7, WebSphere Commerce search introduced the REST-based search runtime programming model. The search runtime contains a new architecture, deployment strategy, and REST APIs to program against the search server. This programming model and architecture was improved with Feature Pack 8.

When you migrate, WebSphere Commerce search updates the existing WebSphere Commerce search cores and configuration files to the latest version of WebSphere Commerce search. Your existing customizations are also considered during the migration steps to ensure that your latest version also contains your earlier changes to WebSphere Commerce search behavior.

Important: If you need to continue to receive support for WebSphere Application Server, you must upgrade to WebSphere Application Server to version 8.5.5 with Java 8. Earlier versions of WebSphere Application Server are no longer supported. You can only update to use IBM SDK, Java Technology Edition Version 8 if your existing WebSphere Commerce runtime instance is on WebSphere Commerce version 7 Feature Pack 6, 7, or 8, and has Fix Pack 9 installed. For more information, see Support for JDK 8, WebSphere Application Server V8.5.5.5, and Rational Application Developer V9.5.0.2

Before you begin

  1. Review the following WebSphere Commerce search topologies and terminology differences between feature pack releases:
    Standard configuration (local deployment)
    The standard configuration mode creates and deploys a separate search profile and Web module on the same machine as the WebSphere Commerce profile.
    For more information about the standard configuration, see the Standard configuration overview.
    Advanced configuration (federate and cluster)
    The advanced configuration allows you to federate and cluster WebSphere Commerce search. First, in the standard configuration, it creates and deploys a separate search profile and web module on the same machine as the WebSphere Commerce profile. Then, federates them across nodes by using the deployment manager (DMGR).
    For more information about the advanced configuration, see the Advanced configuration overview.
  2. If you want to publish a new starter store, you must migrate the WebSphere Commerce search server first, and then publish the new starter store after feature enablement.
  3. Ensure that you complete the following tasks in your lower version of WebSphere Commerce:
    1. Deploying the WebSphere Commerce search server
    2. Setting up the search index
    3. Preprocessing the WebSphere Commerce search index data
    4. Building the WebSphere Commerce search index
  4. Ensure that you complete the following task in your later version of WebSphere Commerce:

About this task

During this task, you perform the following high-level steps:
  1. Prepare your environment for migration by installing the new feature pack version and running the foundation enablement script.
  2. If you are migrating from Feature Pack 2, 3, or 4, migrate facetable attributes.
  3. Run the automated search index setup migration utility on all existing master catalog IDs.
  4. Manually compare and copy customized WebSphere Commerce search configuration files into the new search version.
  5. Populate and build the full search index data.
  6. Update your storefront JSP files, depending on your feature pack version.
  7. Secure the search server, if your previous version of WebSphere Commerce search had security enabled.
  8. Set price ranges to index and display in starter stores by updating search properties in the component configuration file (wc-component.xml).
  9. Reconfigure clustering and replication, if your previous search deployment is in a clustered environment.
  10. Configure the JVM custom properties for the cluster members, so that the Solr multi-index reader can read resources that are located outside its instance.
During this task, you do not perform any steps to migrate the following areas, as they are automatically migrated:
  • Storefront features
  • Search rules

Procedure

  1. Prepare your environment for migration.
    1. Install the new feature pack version that you want to use on the WebSphere Commerce server.
    2. If you did not enable the foundation feature on your latest feature pack that is installed, then enable foundation. Enabling foundation also enables WebSphere Commerce search. For more information, see Enabling WebSphere Commerce foundation.
    3. If you did not enable the starter store enhancements feature on you latest feature pack that is installed, then enable starter store enhancements. For more information, see Enable the starter store enhancements feature.
    4. Restart the WebSphere Commerce application server.
  2. If you are migrating from Feature Pack 2, 3, or 4, migrate facetable attributes.
    1. Go to the following directory:
      • WC_installdir/bin
      • WebSphere Commerce DeveloperWCDE_installdir\bin
    2. For attribute dictionary facetable attributes, run the search faceted attributes migration utility:
      • WebSphere Commerce DevelopermigrateSearchFacet.bat
      • WindowsmigrateSearchFacet.bat -instance instance_name -dbuser db_user -dbuserpwd db_password
      • SolarisLinuxAIXmigrateSearchFacet.sh -instance instance_name -dbuser db_user -dbuserpwd db_password
    3. For facetable attributes not in the attribute dictionary, manually migrate the faceted attributes:
      1. Run the following SQL query:
        
        select distinct srchfieldname from clsattrsrchconf where attrname is not null;
        
        Note the result for comparison. For example:
        
        SRCHFIELDNAME
        ------------------
        CAS_F1
        
      2. Run the following SQL query:
        
        select srchattr_id, propertyvalue, propertyname from srchattrprop 
        where propertyname in ('facet', 'facet-classicAttribute') and propertyvalue not like 'price%'
        
        Note the result for comparison. For example:
        
        SRCHATTR_ID            |PROPERTYVALUE
        ------------------------------------------------------------------------------------------------------
        -7000000000000000127   |ads_f10001_ntk_cs
        -7000000000000000125   |ads_f10501_ntk_cs
        -7000000000000000123   |ads_f11001_ntk_cs
        -1002                  |mfName_ntk_cs
        -1039                  |parentCatgroup_id_facet
        -1013                  |parentCatgroup_id_search
        -2000                  |xf_ads_f1_ntk_cs
        1030                   |cas_f1_ntk_cs
        
      3. Find and update the record that begins with the SQL select statement result from Step 5.c.i. in the propertyvalue column (case insensitive). For example, the SRCHATTR_ID with 1030 matches the sample snippets.
        Set the propertyname value from facet to facet-classicAttribute:
        
        update srchattrprop set propertyname='facet-classicAttribute' where srchattr_id='SRCHATTR_ID'
        
        Where SRCHATTR_ID contains the matching row value. For example, 1030.
      4. Insert a row for each of the classic attributes into the FACET table. Ensure that the facet_id does not conflict with any existing values. For example:
        
        insert into facet (facet_id, attr_id, srchattr_id, selection, sort_order, keyword_search, 
        zero_display, storeent_id, max_display, sequence, field1, field2, field3, optcounter) 
        values (-1039, null, 1030, 0, 0, 1, 0, 10901, 20, 0.0, null, null, null, 0)
        
        Note: Ensure that your statement matches your environment. For example, by updating the correct storeent_id value.
      5. Insert a row in the FACETDESC table for the attributes. For example, if the attribute name is Color:
        insert into facetdesc values(-1039, -1, 'Color', 'classic attribute COLOR', null, null, null, 1);
        
      6. Trigger a delta update or perform a full index update.
    4. To ensure that the migrated attributes display in the storefront, set the FACETABLE column of the ATTR table to 1:
      
      UPDATE ATTR SET FACETABLE = 1 WHERE ATTR_ID IN (list_of_facetable_attribute_ids);
      
  3. Run the search index setup migration utility:
    Important: If you have multiple master catalog IDs, for example, 10001 and 10002, you must migrate all of them separately. That is, if you migrate only 10001, but do not migrate 10002, Solr configuration errors occur when you build the search index.
    1. Go to the following directory:
      • WC_installdir/components/foundation/subcomponents/search/bin
      • WebSphere Commerce DeveloperWCDE_installdir\components\foundation\subcomponents\search\bin
    2. Run the search index setup migration utility
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-indexsubtype indexsubtype] [-dbauser dbauser] [-dbauserpwd dbauserpwd]
      • SolarisLinuxAIXmigrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-indexsubtype indexsubtype] [-dbauser dbauser] [-dbauserpwd dbauserpwd]
      Where:
      instance_name
      The name of the WebSphere Commerce instance with which you are working (for example, demo).
      masterCatalogId
      The ID of the master catalog (for example, 10101).
      If you do not know the master catalog ID, run the following SQL:
      
      SQL: select * from catalog where IDENTIFIER='STORE_IDENTIFIER'
      
      dbuser

      DB2The name of the user that is connecting to the database.

      OracleThe user ID connecting to the database.

      dbuserpwd
      The password for the user that is connecting to the database.
      solrhome
      The location of the Solr home directory path that contains the index data of Solr. The value must be an absolute path.
      The default value is:
      • WebSphere Commerce DeveloperWCDE_installdir/search/solr/home
      • SolarisLinuxAIXWindowsWC_installdir/instances/instance_name/search/solr/home
      • For IBM i OS operating systemWC_instance_root/instances/instance_name/search/solr/home
      wasHome
      The installation path for WebSphere Application Server.
      searchServerName
      The search server host name. Required if the search server host name was changed from the default name before migration.
      searchServerPort
      The search server port. Required if the search server port was changed from the default port before migration.
      searchServiceContextRoot
      The search service context root. For the Solr related actions such as configSolrCores and configWCforSolr, the default value is /solr.
      indexsubtype
      Specify -indexsubtype Inventory if you set up the inventory index in an earlier feature pack version.
      If specified, the migrateSolrSearch script migrates the catalog entry, catalog group, unstructured, and inventory indexes for the master catalog at the same time.
      If not specified, the migrateSolrSearch script migrates the catalog entry, catalog group, and unstructured indexes by default.
      dbauser
      The name of the DBA user. This parameter is required with the dbauserpwd parameter if you set up workspaces in an earlier feature pack version.
      dbauserpwd
      The password of the DBA user. This parameter is required with the dbauser parameter if you set up workspaces in an earlier feature pack version.
    3. WebSphere Commerce DeveloperClean the test server.
      1. Start Rational Application Developer.
      2. Right-click the test server. Then, select Clean....
    4. Ensure that the utility runs successfully by reviewing the log file to see the results of the migration. The log file is located is the location that is specified in the migrate-solr-search-logging.properties file.
      By default, you can find the log at the following location:
      • WebSphere Commerce DeveloperWCDE_installdir\components\foundation\subcomponents\search\config\migrate-solr-search-logging.properties
      • SolarisLinuxAIXWindowsWC_installdir/components/foundation/subcomponents/search/config/migrate-solr-search-logging.properties
      If the utility did not run successfully, you can modify the logging configuration file as needed, specifically the logging level:
      Logging configuration file parameters
      Parameter Value
      Logging level
      INFO
      The typical logging level to use for the utility. This level also lists all SQL statements that you can use to roll back the migration.
      FINEST
      This level lists all details as the utility runs. Use this level if you encounter errors or exceptions during the migration and you need additional information for troubleshooting.
      Log file location java.util.logging.FileHandler.pattern=../log/migrate-solr-search-logging.log

      If you deployed the WebSphere Commerce search cluster, ensure that the EAR changes are propagated to all the nodes.

  4. Compare and copy your customized search configuration files into the new search version.
    1. If you customized the WebSphere Commerce search preprocessor configuration files:
      1. Go to the following directory:
        • WC_installdir/instances/instance_name/search/pre-processConfig
        • WebSphere Commerce DeveloperWCDE_installdir\search\pre-processConfig
      2. Manually compare all the files in the MC_masterCatalogId.timestamp directory with the files in the MC_masterCatalogId directory.
      3. Identify all the changed files, and merge the specific Feature Pack 7 changes from the MC_masterCatalogId.timestamp directory to the files with the same names in the MC_masterCatalogId directory.
    2. If you customized the default WebSphere Commerce search Solr configuration files:
      1. Go to the following directory:
        • WC_installdir/instances/instance_name/search/solr/home/MC_masterCatalogId/locale_name/indextype
        • WebSphere Commerce DeveloperWCDE_installdir\search\solr\home\MC_masterCatalogId\locale_name\indextype
      2. For each core, manually compare the solrconfig.xml, wc-data-config.xml, and schema.xml files in the conf.timestamp directory with the files in the conf directory.
      3. Identify all the changed files, and merge the specific previous Feature Pack changes from the conf.timestamp directory to the files with the same names in the conf directory.
  5. Populate and build the full search index data:

    You must perform these tasks, as extra parameters are required in Feature Pack 7 or later, when a previous version of WebSphere Commerce search is enabled from an earlier Feature Pack version.

    1. If you are migrating from Feature Pack 2, complete the following tasks, specifying the indextype as CatalogGroup when you run the search index setup utility.

      Setting up the search index.

      If you have enabled workspaces and activate a task group and tasks, you must include the following parameters to create the workspace-related workspace tables and search configuration files:
      Feature Pack 5 or laterdbauser
      Feature Pack 5 or laterThe name of the DBA user. This parameter is required with the dbauserpwd parameter to create the workspace indexes.
      Feature Pack 5 or laterdbauserpwd
      Feature Pack 5 or laterThe password of the DBA user. This parameter is required with the dbauser parameter to create the workspace indexes.
    2. Complete the following task: Preprocessing the WebSphere Commerce search index data
      Important: You must preprocess both the CatalogEntry index and the CatalogGroup index. That is, ensure that the full-path parameter includes the CatalogEntry index.

      Including CatalogEntry index in the full-path parameter processes the configuration files for both CatalogEntry and CatalogGroup by default.

      The directory that contains the configuration files for CatalogGroup is one level below the directory for CatalogEntry.

    3. If you are migrating from Feature Pack 4 or lower, remove the Solr data for every workspace, language, and master catalog. For example, from the following locations:
      • solrhome/MC_masterCatalogId/locale/CatalogGroup/data
      • solrhome/MC_masterCatalogId/locale/CatalogEntry/data
      • solrhome/MC_masterCatalogId/locale/CatalogEntry/unstructured/data
    4. Restart the WebSphere Commerce search server, then complete the following task: Building the WebSphere Commerce search index.
      Important: You must build the catalog entry index when indexing WebSphere Commerce search. That is, at a minimum, the catalog entry index must be rebuilt when migrating WebSphere Commerce search. That is, ensure that the indextype parameter includes the CatalogEntry index.

      If you do not use the indextype parameter, both the CatalogEntry and CatalogGroup indexes are built by default.

      Feature Pack 8If the index build fails with multiple languages due to OutOfMemoryError issues, you must increase the search server heap size. For example, increase it to 2 GB. For more information, see Troubleshooting: Out of memory error from building the search index with multiple languages.

  6. Update your storefront JSP files, depending on your feature pack version.
    1. If you are migrating from Feature Pack 2, update your storefront JSP files:
      Note: This step is only required if interim fix #1590 is not installed.
      1. Open the following file:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Snippets/ReusableObjects/SearchFacetsDisplay.jspf
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\ storedir\Snippets\ReusableObjects\SearchFacetsDisplay.jspf
      2. Find all occurrences of the following snippet.
      3. 
        parentCatgroup_id_facet
        
      4. Replace all occurrences with the following snippet:
        
        parentCatgroup_id_search
        
      5. Find the following snippet:
        
        <c:if test="${totalCount > 1}">
           <c:forEach var="facetField" items="${globalfacets}">
           <c:if test="${facetField.value eq 'parentCatgroup_id_search'}">
           <c:if test="${fn:length(facetField.entry) > 1}">
              <%@ include file="../../Snippets/Search/CategoryFacetDisplay.jspf" %>
                 <c:set var="f" value="${f + 1}" />
              </c:if>
           </c:if>
        </c:forEach>
        
      6. Replace it with the following snippet:
        
        <c:if test="${totalCount > 0}">
           <c:forEach var="facetField" items="${globalfacets}">
           <c:if test="${facetField.value eq 'parentCatgroup_id_search'}">
           <c:if test="${fn:length(facetField.entry) > 0}">
              <%@ include file="../../Snippets/Search/CategoryFacetDisplay.jspf" %>
                 <c:set var="f" value="${f + 1}" />
              </c:if>
           </c:if>
        </c:forEach>
        
      7. Save your changes and close the file.
      8. Open the following file:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Snippets/Search/SearchSetup.jspf
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\Snippets\Search\SearchSetup.jspf
      9. Find the following snippet:
        
        request.setAttribute("handledSearchTerm"
           ,SpecialCharacterHelper
           .getHandledString(searchTerm, false));
        
        request.setAttribute("handledFilterTerm"
           ,SpecialCharacterHelper
           .getHandledString(wcp.get("filterTerm"), false));
        
        request.setAttribute("handledManufacturer"
           ,SpecialCharacterHelper
           .getHandledString(wcp.get("manufacturer"), false));
        
      10. Replace it with the following snippet:
        
        request.setAttribute("handledSearchTerm"
           ,SpecialCharacterHelper
           .escapeDollar(searchTerm));
        
        request.setAttribute("handledFilterTerm"
           ,SpecialCharacterHelper
           .escapeDollar(wcp.get("filterTerm")));
        
        request.setAttribute("handledManufacturer"
           ,SpecialCharacterHelper
           .escapeDollar(wcp.get("manufacturer")));
        
      11. Save your changes and close the file.
      12. Open the following file:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/include/BreadCrumbTrailDisplay.jsp
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\include\BreadCrumbTrailDisplay.jsp
      13. Find the following snippet:
        
        <c:if test="${fn:startsWith(breadcrumbLabel, '({')}">
           <c:set var="rangeLabel" value="${fn:replace(breadcrumbLabel,'({','')}" />
           <c:set var="rangeLabel" value="${fn:replace(rangeLabel,'})','')}" />
           <c:set var="rangeLabel" value="${fn:replace(rangeLabel,'}','')}" />
        
      14. Replace it with the following snippet:
        
        <c:if test="${fn:startsWith(breadcrumbLabel, '{')}">
           <c:set var="rangeLabel" value="${fn:replace(breadcrumbLabel,'{','')}" />
           <c:set var="rangeLabel" value="${fn:replace(rangeLabel,'}','')}" />
        
      15. Save your changes and close the file.
      16. Restart your WebSphere Commerce server.
      17. Deploy the changes for the JSP files you updated. For more information, see Deploying J2EE assets for a single file.
    2. If you are migrating from Feature Pack 6, update your storefront JSP files to ensure that the advanced search feature works correctly:
      1. Open the following file:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Layouts/CategoryNavigationResults.jsp
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\Layouts\CategoryNavigationResults.jsp
      2. Find the following snippet:
        
        <c:when test="${!empty WCParam.searchTerm || !empty WCParam.manufacturer || !empty WCParam.facet || !empty WCParam.metaData}">
        
      3. Replace it with the following snippet:
        
        <c:when test="${!empty WCParam.searchTerm || !empty WCParam.manufacturer || !empty WCParam.filterTerm || !empty WCParam.facet || !empty WCParam.metaData}">
        
      4. Save your changes and close the file.
      5. Open the following file:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Layouts/SearchBasedCategoryPage.jsp
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\Layouts\SearchBasedCategoryPage.jsp
      6. Find the following snippet:
        
        <c:when test = "${empty WCParam.searchTerm && empty WCParam.manufacturer && empty WCParam.facet && empty WCParam.metaData}">
        
      7. Replace it with the following snippet:
        
        <c:when test = "${empty WCParam.searchTerm && empty WCParam.manufacturer && empty WCParam.facet && empty WCParam.filterTerm && empty WCParam.metaData}">
        
      8. Save your changes and close the file.
      9. Deploy the changes for the JSP files you updated. For more information, see Deploying J2EE assets for a single file.
    3. If you are migrating from Feature Pack 6 or lower, update your storefront JSP files for Feature Pack 7 or later:
      1. Open the following file:
        For the Madisons starter store and Elite starter store:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/include/JSTLEnvironmentSetupExtForSearch.jspf
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Snippets/Search/AutoSuggestSerialize.jsp
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\include\JSTLEnvironmentSetupExtForSearch.jspf
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\Snippets\Search\AutoSuggestSerialize.jsp
        For the Aurora starter store:
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Widgets/Search/JSTLEnvironmentSetupExtForSearch.jspf
        • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Widgets/Search/AutoSuggestSerialize.jsp
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\Widgets\Search\JSTLEnvironmentSetupExtForSearch.jspf
        • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\storedir\Widgets\Search\AutoSuggestSerialize.jsp
      2. Find the following snippet:
        
        <%@ page import="org.apache.solr.client.solrj.impl.CommonsHttpSolrServer" %>
        
      3. Replace it with the following snippet:
        
        <%@ page import="org.apache.solr.client.solrj.impl.HttpSolrServer" %>
        
      4. Find the following snippet:
        
        if(solrServer instanceof CommonsHttpSolrServer ){
                    serverURL = ((CommonsHttpSolrServer )solrServer).getBaseURL();
        
      5. Replace it with the following snippet:
        
        if(solrServer instanceof HttpSolrServer){
                    serverURL = ((HttpSolrServer)solrServer).getBaseURL();
        
      6. Save your changes and close the file.
      7. Deploy the changes for the JSP files you updated. For more information, see Deploying J2EE assets for a single file.
  7. If your previous version of WebSphere Commerce search had security enabled, complete the following task: Securing the WebSphere Commerce search server. This ensures that the WebSphere Commerce search server is secured after migration.
  8. Set price ranges to index and display in starter stores:
  9. For a clustered search server:
    1. Set up the search cluster again, based on the local search server by completing the steps in Clustering WebSphere Commerce search. For example, when you migrate from an Advanced search deployment that is federated and clustered from a remote search server.
    2. Copy the WC_installdir/components/foundation/subcomponents/search/solr/home/replication-config.xml file to WC_installdir/instances/instance_name/search/solr/home. Then, edit the file to match your master machine and subordinate machine configurations.
    3. Manually copy the Solr home directory from the first WebSphere Commerce search application server that is running the search index setup migration utility to all clustered servers. The default Solr home is in the following location:
      • working_dir/search/instance_name/search/solr/home
    4. Reconfigure WebSphere Commerce search for replication.
    5. Restart your WebSphere Commerce search cluster and WebSphere Commerce cluster.
  10. Feature Pack 8Configure the JVM custom properties for the cluster members.

    This step enables the solr.allow.unsafe.resourceloading flag, which is required for the Solr multi-index reader to read resources that are located outside its instance.

    1. Log on to the WebSphere Application Server administrative console for the DMGR profile of the search cluster.
    2. Go to Servers > Clusters > WebSphere application server clusters.
    3. Click the cluster that you created in this task.
    4. Under Additional Properties, click cluster members. All the servers in the current cluster are listed.
    5. Set the following JVM custom properties for each server:
      1. Click the server name.
      2. Under Server Infrastructure, go to Java and Process Management > Process Definitions.
      3. Under Additional Properties, click Java Virtual Machine.
      4. Under Additional Properties, click Custom Properties.
      5. Click New and set the following values:

        Custom properties

        Name Value
        solr.allow.unsafe.resourceloading true
        By default, the resource loader does not load files from external servers for security reasons.
      6. Click Apply.
    6. Save your changes to the master configuration and ensure that all nodes are synchronized.

What to do next

After you complete the migration steps, you can migrate WebSphere Commerce search customization assets. Then, publish a starter store and go to the storefront to confirm that WebSphere Commerce search is functioning correctly.