Migrate OnePart

Product migration allows you to quickly index the old instance's data into the new OnePart instance.

This documentation explains how to migrate from a previous version of OnePart to a new one. We use the following convention to name the former OnePart instance as old, and the new instance to be installed as new. You can either use the OnePart installer or the command line interface (CLI). This procedure details how to migrate data using the OnePart installer.

This task shows you how to:

First step - migrate old instance to new one

  1. Double-click on the new OnePart installer.
  2. Select the install directory for the new instance (for example, e:\projects\mig\OPnew).
  3. Do not check Unzip Only.
  4. Check Migration.
  5. Give the path to old instance's datadir. Be careful not confuse with old install dir (for example, e:\projects\mig\OPold\datadir).
  6. Give the path to the licence file. This field can eventually left empty, that leads to use old instance's license file (for example, leave this field empty).
  7. Give the new instance name. As expected in a classic installation (non-migration), this name must not be already used in the list of windows services (for example, OPnew).
  8. Give the instance's hostname as usual, default value is probably the best value, see OnePart install if needed (for example, we keep the default value determined by installer).
  9. Define the window account if needed (for example, check The localSystem account).
  10. Define the new instance's baseport. It is important to understand that both instances old and new will be up at the same time, so choose another port range than old instance's one, and do not forget any OnePart instance port range spreads from its baseport to baseport+99 (for example, 20000).
  11. Do not check any of the following check boxes, or change port base yet, until you know exactly what you're doing. Those features give access to post-migration tools that will described in the following steps. It is possible to invoke them all at once but we encourage using them in a second time.
  12. Click install.
    When the installer stops, the new OnePart instance is installed based on the configuration of the old one. This means the new instance is up on its own port, and its configuration inherited from the old one. Some configuration files are patched by the migration to ensure their compatibility from the old version to the new one (AppsSecurity, supported connectors, custom configuration). Everything else, including new features, new data model, plugins, etc... even storage were installed and configured by migration in the new instance. Accounts, including admin, are also inherited from the old instance. So the new OnePart is fully functional, exactly as was the old OnePart, but on a different port, and without any data in its index.
    Note: Some configuration modifications, and certain connectors are not supported by migration. Therefore, you may need to manually change the customization or connectors to make them compatible with the new OnePart version. We recommend that you make these changes now and test them.

Second step - populate index with data

At this stage, two options are available to get data into the new OnePart instance:

  • You can switch to the console (either OnePart's or Exalead CloudView's) and do a scan of every connector (this includes non-supported connectors by migration). As we already said in the foreword, if a lot of part are due to be converted by XCV, that will probably last for a very long time. During that time, new instance will not be available with all its data. When finished, this procedure provides a fully functional with completely up-to-date data instance, ready to replace old one.
  • In case you have to scan a huge amount of data, and need a quickly available instance filled with those data, you can use Data migration feature. This feature will copy old instance's Consolidation Server storage to new instance. Then it will apply a "force aggregation" that will push the Consolidation Server's content "as it is" into the new index. This procedure by-passes XCV conversion, then we will quickly import old data into new instance. But, as we said in the foreword, this data is not up-to-date with new signatures and eventual new metas. This could lead to some malfunctions depending on the versions of old and new instances. If this method is used, it is possible some features using signatures could behave slightly differently as expected. It is mandatory to check afterwards, if new OnePart behavior is acceptable. Once the data migration is completed, it is your decision to use new OnePart as a production instance (even if side effects may occur), or as a beta version. It is also still possible to clean the index completely and use the above option (classic scan).

  1. Click on post-install shortcut in Windows start menu / Dassault Systemes OnePart / Tools
  2. Choose the new OnePart installation dir (example: e:\projects\mig\OPnew).
  3. Skip view about Window account which is disabled.
  4. Check Migrate-data.
  5. Click install.

Third step - update migrated data

If you performed a "data migration" instead of a classical scan on the connectors, the new OnePart instance displays data that is not up-to-date with XCV conversion, and whose signatures can potentially produce buggy behavior. Thus, you need to update data doing Force rescan. Force rescan will update data, using connectors (only supported ones), which means XCV conversions will be done and the new instance's index will be updated. Note while this operation is in progress, OnePart will still be available. As data migration is designed for huge indexes which are very long to reload from scratch, the force rescan will be a very long process. During this period of time, data will still be available in OnePart.

Note: This operation enables a specific PAPI filter designed specially for data migration purpose and force rescan.

  1. Click on post-install shortcut in Windows start menu / Dassault Systemes OnePart / Tools
  2. Choose the new OnePart installation dir (example: e:\projects\mig\OPnew).
  3. Skip view about Window account which is disabled.
  4. Check Force rescan.
  5. Click install.
  6. When rescan is finished you must manually disable Data Migration PAPI filter in the Exalead CloudView Administration Console.
    • Go to Connectors > OnePartPAPIFilters > Data Migration and disable the option Enable this PushAPI filter.
    Note: When the tool ends the Force rescan begins, however, this rescan will probably last for a long time. To check if rescan is still going, go to the Administration Console and verify that the connectors are no longer scanning. Once the scan is finished it must be disabled.

Fourth step - go to production

Anytime you decide to go to production and replace the old OnePart instance by new one. You must follow the procedure below.

  1. Stop old instance by any means you wish.
  2. Update the new instance's storage with the old one. This is done using post-migration tools as we saw above and checking Migrate storage.
  3. Change baseport of new instance. This can also be done by editing the post-migration Change port base.