# Migrating a validator node to a new environment Sometimes an organization needs to migrate their validator node into a new environment. Common reasons for this include: * Changing infrastructure providers (e.g. switching cloud or on-premise vendors) * Wanting to upgrade host environment configuration * Rotating access due to security procedures or policies. If you are currently operating a validator node on Volta of the EW Chain and need to migrate it from its existing host environment to a new one, there are two options: ## **Install a new node and retire the existing one** * This option requires [provisioning a new host environment and following the installation procedures to establish an entirely new node](/ewc-validator-documentation/guides/installing-a-validator-node.md) (note: this will result in a new address, private key, EWT balance, etc.). Once your new node is installed, the current one will be removed from the network and you will be able to retire / deprecate the legacy node and host environment. * The benefits of this approach are: * It is easy to replicate the node installation process, so the overall migration is simpler; * You don't have to worry about independently modifying the installation script; * You can maintain continuity by simultaneously retiring the original node and adding the new one to the network; * The drawbacks of this approach are: * You must determine a secure way to maintain access to the legacy block rewards held on the original node address; * Depending on your organization's IT policies and procedures, it may be more complex and costly to procure multiple host environments during the migration. * You may need to replicate or modify access management policies and procedures for the new environment. {% hint style="warning" %} If you elect to install new node, make sure you transfer any EWT held in the original node address to a separate wallet that you can continue to access going forward, and/or maintain the private key to the original node to access old block reward balances. {% endhint %} ## **Migrate your existing node to a new environment** * This option involves migrating the existing node (i.e. maintaining the same address and private key) to a new host environment. To do this, you must extract the private key from the existing environment and then re-run a modified installation script in the new environment, using the private key of the validator node. * The benefits of this approach are: * You maintain continuity by keeping the same address and private key; * You don't need to operate two validator nodes (and thus host environments) simultaneously. * The drawbacks of this approach are: * Depending on the parameters of the existing vs. new environment, you may need to modify configurations and access management. * You must securely extract the private key from the existing node, temporarily store it, and import it into the new environment. * You will experience a period of "downtime" throughout the migration, during which your organization's validator node will not be operational. {% hint style="info" %} As of 2023, if you select this option and you used the OpenEthereum client for your original node please note that your node will be migrated to the Nethermind client during this process due to the deprecation of the OpenEthereum client for EWC in 2022. {% endhint %} Follow the steps to migrate existing nodes to new node: 1. ``` 1. **Migrate existing nodes:** Follow the steps to migrate existing nodes to new node: ``` ``` 1. Collect and store the following necessary info from Old Instance - 1. You can stop containers in old instance. `docker-compose down` 2. Value of `Validator Address`, `InfluxDB Username`, `InfluxDB Password` . You’ll find this info in `install-summary.txt` file. 3. Value of `docker-stack/keystore/.secret`\ To copy the .secret key to your local instance: `scp -P 2222 -i YOURKEYS.pem user@YOUR_INSTANCE:/home/user/docker-stack/keystore/.secret ~/Downloads/` 4. `docker-stack/keystore/UTC--*` (you may run this command in `docker-stack` -> `NETHERMIND_KEY_FILE="$(ls -1 ./keystore/|grep UTC|tail -n1)"`)\ ![:warning:](https://energyweb.atlassian.net/gateway/api/emoji/d3c1da2f-42ad-4fbc-8fd8-633f447a083c/atlassian-warning/path) **The key that was created first is a** `node address` **generated by Nethermind. This is not your mining key, do not copy it!** ![:warning:](https://energyweb.atlassian.net/gateway/api/emoji/d3c1da2f-42ad-4fbc-8fd8-633f447a083c/atlassian-warning/path) 5. \[optional] keep a backup of `docker-stack/` dir. 2. Commented out the following lines from script 1. [Volta validator installation script](https://github.com/energywebfoundation/ewc-validator-node-install-scripts/tree/master/volta-affiliate/nethermind) 2. [EWC validator installation script](https://github.com/energywebfoundation/ewc-validator-node-install-scripts/tree/master/ewc-affiliate/nethermind) \[line from `180-213`] - from `echo "Creating Account..."` \[line 180] **till** `docker rm -f nethermind` \[line 213] . 1. Then run the script in the new instance. 1. The End Result would be the the following . `Validator Address`, `Enode`, `InfluxDB Username` and `InfluxDB Password` field would be empty `==== EWF Affiliate Node Install Summary ==== Company: Company_Name Validator Address: Enode: null IP Address: New_IP_ADDESSS InfluxDB Username: InfluxDB Password:` 2. In the new Instance, There is the `docker-stack/` dir. Enter to the directory and run `docker-compose ps` and run `docker-compose down` to kill node and telemetry containers. 3. The `.secret` file in `docker-stack/keystore`dir needs to be updated with the older one. \[ `.secret` file is in only `readonly` mode. Change mode before updating with old value. `chmod 644 .secret` ] 4. The `.env` file in `docker-stack/` dir needs to be updated. 1. Update the `VALIDATOR_ADDRESS=` field with old value. 2. Update the `NETHERMIND_KEY_FILE=./keystore/UTC--*` with correct name. 5. In the `docker-stack/configs/volta.cfg` or `docker-stack/configs/energyweb.cfg`, the following 2 value needs to be updated. In the new instance, this value would be empty. Update the value with old `Validator Address` `"KeyStore": { "PasswordFiles": ["keystore/.secret"], "UnlockAccounts": ["Old Validator Address goes here..."], "BlockAuthorAccount": "Old Validator Address goes here..." },` 6. Copy the Validator’s mining private key to your new instance * Copy the `UTC--*` file from old instance to `docker-stack/keystore` dir or create that file in `docker-stack/keystore/` dir with exact same name and same value.\ To copy the file to your local instance: `scp -P 2222 -i YOURKEYS.pem user@YOUR_INSTANCE:/home/user/docker-stack/keystore/UTC_PART ~/Downloads/` * \[Optional] If you want a exact sync of database, you can copy db files from the old instance to the new instance - * DB Path - `docker-stack/database/volta` or `docker-stack/database/energyweb` * Run `docker-compose up -d` * Check logs of parity container - * `docker-compose logs -f nethermind` * `docker-compose logs -f nethermind_telemetry` The Validator’s IP address and enode will change. Once you have completed the migration, fill out the installation summary form (for [Volta here](https://share.hsforms.com/1t9po2Du9TgabWS28TQWx1A37vj2), and for [Energy Web Chain](https://share.hsforms.com/1UAF_LAH1RMeYCN-pUY5pnQ37vj2) here) to provide the new IP and enode information. You can also contact netops@energyweb.org to provide notification of the migration. ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.energyweb.org/ewc-validator-documentation/guides/maintaining-a-validator-node/migrating-a-validator-node-to-a-new-environment.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.