Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The process works by first transferring one environment, and testing a development integration with that one environment. Once the development integration is cleared to work, all other environments are transferred, and the integration is upgraded to handle the new SaaS endpoints. Finally, the integration is scheduled to cutover from on-prem to GraFx Publisher, one final transfer is planned to synchronize files, and the entire production site is switched to GraFx Publisher.

Typically, this requires one business day of downtime for the final cutover.(Side note, while you will be transfering all environments, the actual environment transfer tool supports transfering one environment at a time.), but the actual time depends on the size and number of the environments being transferred.

Transfer Each

Best for an integration where there are multiple sites for each environment.

The process works by planning to transfer one environment at a time and testing a development integration with each environment. For each environment, once the development integration is cleared to work with that environment, a cutover is planned. During that cutover, one last transfer is made to synchronize, and then the production site is switched to GraFx Publisher.

Typically, this requires half a business day to one business day of downtime for the final cutover for each environment.

Note

 Cutover

The cutover is when testing is done and your site is ready to switch all API endpoints from your on-prem install to CHILI publish Online.

At this point, you typically want to do another data transfer from your on-prem environment to your GraFx Publisher environment so all the files are synchronized. This cutover day must be planned with the CHILI publish support team, and will usually require a few hours to one business day of downtime. 

Each Cutover Will Cause Downtime!!! 

Determine your plan or create a new plan of your own. The Customer Success team will help as best they can, but keep in mind that the choice is ultimately up to your team. Also keep in mind that no matter what you do, there will be scheduled downtime. The final cutover requires files to be transferred and that takes time.

...

If you are doing a production transfer (not just testing). You need to fix potential absolute paths in the resource files can cause issues post-migration, especially in cloud environments. To avoid this, the FixAbsolutePathsInDataXml FixDataXmlFiles command converts absolute paths to relative ones.

Code Block
.\CHILI.Migration.CLI FixAbsolutePathsInDataXmlFixDataXmlFiles -d "C:\chili_data\Environments\test"

...

If you backed up your data.xml files, you can just restore them to undo the changed made by FixAbsolutePathsInDataXml

...

Transferring Data

Info

It’s important to note that you are transferring to a temporary cloud-based storage and not directly to your environment. This is due to infrastructure.

Single Environment Transfer

To migrate your a single environment to a the cloud-based storage, use the CopyEnvironmentToDropzone command. This requires the path to your environment and the environment ID. It's recommended to perform this operation when your system is under minimal load and has sufficient free RAM (at least 4GB). Code Block

.\CHILI.Migration.CLI

...

CopyEnvironmentToDropzone

...

-d

...

"C:\chili_data\Environments\test"

...

-e

...

"45bbcd53-6334-48a9-8394-0cf4821d7bbc"

-d is the path to your environment

-e is your environment ID

Note

By default, the history of documents and assets will not be transferred. This decision is aimed at increasing the speed of transfer, especially in large environments where these files can number in the hundreds of thousands. Since very few clients utilize this feature for any real production use-case, the transfer of history files is disabled by default.

The history files are used in the BackOffice to display changes to a file including preview errors and file update dates.

image-20240708-191331.pngImage Added

If you need to transfer history files, you can re-enable this feature by using the -i parameter and setting it to true.

For example:

CopyEnvironmentToDropzone -d "C:\chili_data\Environments\test" -e "45bbcd53-6334-48a9-8394-0cf4821d7bbc" -i true

Multi Environment Transfer

Alternatively, the Data Migration Toolkit now supports a multi-environment transfer option. If you are planning to utilize this option, it is important to inform the support team prior to your cutover day.

Open the below to see full instructions.

Expand
titleMulti-Environment Transfer Instructions

First you will create a JSON file to define the environment ID, which is called a DeploymentGuid and the name of the environment (folder name) on your local system EnvironmentName.

Example of JSON

[

    {

        "DeploymentGuid": "c999ab9d-be99-9999-b99c-d99f99f99999",

        "EnvironmentName": "Environment1"

    },

    {

        "DeploymentGuid": "c888ab9d-be99-8888-b99c-d99f99f88888",

        "EnvironmentName": "Environment2"

    },

    {

        "DeploymentGuid": "c777ab9d-be99-7777-b99c-d99f99f77777",

        "EnvironmentName": "Environment3"

    }

]

To migrate multiple environments to the cloud-based storage, use the CopyEnvironmentToDropzone command but instead of -e you use -c. It's recommended to perform this operation when your system is under minimal load and has sufficient free RAM (at least 4GB).

.\CHILI.Migration.CLI CopyEnvironmentToDropzone -d "C:\chili_data\Environments\" -c "C:\MyFolder\EnvironmentsToMigrate.json"

-d is the base path to the environments directory

-c is the path to the configuration json

Note

See https://chilipublishdocs.atlassian.net/wiki/spaces/CPDOC/pages/edit-v2/1525055493#Single-Environment-Transfer about transferring history files

Step 3: Notify the Customer Success team when the transfer is complete

...