Environment Migration between Regions

Within the confines of the multiple environment regions approach, the initially chosen location of the project can be easily changed using the migration option (obviously, if you have access to several environment regions). It represents an extremely powerful tool, that can help you to benefit in both cost and productivity – as an example, you can choose cheaper hardware for the development/testing stages and subsequently migrate your production-ready application to the hardware with the best parameters, just before the release. 

Note: The availability of the migration option, as well as its allowance for each particular environment region, depends on your hosting provider’s settings.

So, in order to migrate the existing environment to another hardware region, perform one of the following:

• Click on the Change environment topology button and choose the Migrate option within the regions’ list above.

• Or select the Settings button next to the desired environment and switch to the Migration menu option.

In both cases, you’ll see the same frame opened with a Current region of the chosen environment stated and an option for choosing the Target region, i.e. the hardware it should be migrated to

Note: that the pricing policy in different regions can vary based on their parameters and is applied automatically after the relocation is done, thus it’s recommended to get acquainted with the appropriate costs in advance – the actual information can be discovered using the corresponding link, provided within the tip under the Target region selector.

Just lower down the tab the Live migration section is placed, either with the special switcher shown or providing some additional info, depending on the chosen target region. Here you can define which migration type (among the two provided ones) should be used:

• live migration – available only between the regions, marked with the special LM label within the list (this depends on the physical location of a particular region’s hardware)
• offline migration – can be used for any environment regions.

State all the necessary conditions and click on Verify & Migrate at the bottom of the section to initiate the relocation. Confirm your decision within the appeared pop-up frame.

Once the migration is completed, the appropriate information message will appear on the dashboard and the region label next to the environment will be changed. In addition, you’ll receive the notification email with the migration details (like its duration for every container and any changes that happened with their parameters due to this process).

And below we’ll consider both migration modes in more detail.

Live Migration

Within the Target region list, you can see a special LM label shown next to particular regions – it is used to mark the Live migration option’s availability.

Upon selecting such a region as a target one, the Live migration switcher will appear beneath (in the enabled state by default).

If choosing this type of migration, the environment relocation will be performed implicitly, i.e. without a restart of containers and any extra configurations needed, so your app’s users won’t face any interruptions.

Note: that in the case of a high load (i.e. big amount of incoming requests) an environment can still undergo a brief downtime (about 10 seconds) with the 502 – environment stopped error shown. Nevertheless, when data is successfully transferred, it will resume its work automatically.

If for some reason the offline mode is needed – just turn off the corresponding switcher. 

In such a case, an environment with all of the containers in it will become unavailable for the whole relocation process and resume its normal work, after this operation completes, with no additional manual adjustments required.

Offline Migration

When the live migration option is unavailable (due to moving an environment to another data center) or in case it was disabled manually, the offline mode is used. In contrast to the online one, during such a relocation, an environment will be shut down until the end of this process.

In addition, if this migration type is the only available one, some environment settings, like IP addresses of nodes and, optionally, the domain name assigned, will be changed. Thus, after the migration is completed, some manual configurations may be required to restore the normal operability of the moved application – all of the necessary information will be additionally sent to you via email.

Obviously, based on the abovementioned pros and cons, live migration is a much more preferable option, if available.