{note:title=Upgrading from v2.0 to v2.0.1}Customers upgrading from v2.0 to v2.0.1 should review the process described in the section [lweug20:Upgrade Instructions for v2.0 to v2.0.1].{note}
h2. Overview of Migrating from v1.7 or 1.8 to v2.0
It is not yet possible to perform a fully automated upgrade from one LucidWorks Enterprise version to another, but it is possible to migrate configuration and data from a prior version to v2.0. *Migration is possible only from v1.7 or v1.8 to v2.0.*
{warning}
While the migration steps are outlined below, it is recommended that this only be attempted after consultation with Lucid Imagination Support to be sure the latest version of the tools are installed and all customizations are accounted for.
One issue to be careful of is that data source IDs may change when importing configuration data from the prior installation of LucidWorks Enterprise to the new one. This is because the Update Tool imports the configuration data and allows LucidWorks Enterprise to use it's own processes to assign new data source ids. However, the index data is simply converted, leaving documents with the same data source related fields intact. This mismatch will not destroy the system, but may cause unexpected behavior in the Admin UI and in search results (such as, document counts may not appear correctly in the Admin UI). Deleting documents may also be problematic, meaning that using the UI to delete documents from data sources may delete documents for the wrong data sources.
It is highly recommended to run through this process in a test environment to understand the likely outcome before using this in production.
{warning}
The migration steps are as follows:
# Export [system configuration|lweug20:LucidWorks Update Tool] from the older version while LucidWorks Enterprise is running. Be sure to review the issues.txt output of the tool to understand what problems may occur during the rest of the migration.
# Stop LucidWorks Enterprise and run the [Upgrade Tool|lweug20:LucidWorks Update Tool]. Save the output files where they can be found later.
# [Install|lweug20:Installation] LucidWorks Enterprise v2.0 on a new server or in a different location from the older version.
# [Migrate|lweug20:LucidWorks Update Tool] the LucidWorks Enterprise configuration to the new version (with LucidWorks Enterprise running).
# Update configuration files with customizations that are not supported by the Update Tool.
# [Upgrade the index|Index Upgrade Tool] for each collection and put the new index files in the proper places in the new installation. LucidWorks Enterprise should not be running while this occurs.
# [Re-generate auto-complete indexes|lweug20:Auto-Complete of User Queries] for each collection, if desired.
At the current time, it is not possible to install a new version of LucidWorks Enterprise over an existing one. If upgrading the application on the same server it is currently running on, a new directory path will need to be input into the installer to continue. Also, make sure to define the component ports on the new installation as different from the existing LucidWorks Enterprise.
{scrollbar}
h2. Overview of Migrating from v1.7 or 1.8 to v2.0
It is not yet possible to perform a fully automated upgrade from one LucidWorks Enterprise version to another, but it is possible to migrate configuration and data from a prior version to v2.0. *Migration is possible only from v1.7 or v1.8 to v2.0.*
{warning}
While the migration steps are outlined below, it is recommended that this only be attempted after consultation with Lucid Imagination Support to be sure the latest version of the tools are installed and all customizations are accounted for.
One issue to be careful of is that data source IDs may change when importing configuration data from the prior installation of LucidWorks Enterprise to the new one. This is because the Update Tool imports the configuration data and allows LucidWorks Enterprise to use it's own processes to assign new data source ids. However, the index data is simply converted, leaving documents with the same data source related fields intact. This mismatch will not destroy the system, but may cause unexpected behavior in the Admin UI and in search results (such as, document counts may not appear correctly in the Admin UI). Deleting documents may also be problematic, meaning that using the UI to delete documents from data sources may delete documents for the wrong data sources.
It is highly recommended to run through this process in a test environment to understand the likely outcome before using this in production.
{warning}
The migration steps are as follows:
# Export [system configuration|lweug20:LucidWorks Update Tool] from the older version while LucidWorks Enterprise is running. Be sure to review the issues.txt output of the tool to understand what problems may occur during the rest of the migration.
# Stop LucidWorks Enterprise and run the [Upgrade Tool|lweug20:LucidWorks Update Tool]. Save the output files where they can be found later.
# [Install|lweug20:Installation] LucidWorks Enterprise v2.0 on a new server or in a different location from the older version.
# [Migrate|lweug20:LucidWorks Update Tool] the LucidWorks Enterprise configuration to the new version (with LucidWorks Enterprise running).
# Update configuration files with customizations that are not supported by the Update Tool.
# [Upgrade the index|Index Upgrade Tool] for each collection and put the new index files in the proper places in the new installation. LucidWorks Enterprise should not be running while this occurs.
# [Re-generate auto-complete indexes|lweug20:Auto-Complete of User Queries] for each collection, if desired.
At the current time, it is not possible to install a new version of LucidWorks Enterprise over an existing one. If upgrading the application on the same server it is currently running on, a new directory path will need to be input into the installer to continue. Also, make sure to define the component ports on the new installation as different from the existing LucidWorks Enterprise.
{scrollbar}