New plan for Ishikari Zone No. 1

[Update: January 22, 2019]


We started providing a new plan in Ishikari Zone No. 1 for disks and servers from September 27, 2018. The new plan features an enhanced menu and lower fees. This page explains topics including an overview of the new plan, how to migrate from old plans (plans created before September 27, 2018), and restrictions for use with a mixture of new and old plans.


Tools are available for easily transitioning servers and disks created using an old plan to the new plan. For details, please refer to :ref:``Tool for migration from old plan to new plan <is1a-migrate-tool>`.

Features of new plan

When compared to old plans (plans provided until September 26, 2018) for Ishikari Zone No. 1, the new plan has the following features.

  • Lower fees for a plan with the same performance. (For details on fees, please refer to Service site .)
  • The following storage plans which were not provided can now be created similar to other zones.
    • SSD 40GB
    • SSD 1TB
    • SSD 2TB
    • SSD 4TB
  • Customers who currently own resources of an old plan can continue to create new resources for the old plan even after the start of provision for the new plan. (Creation using the old plan is not possible by customers who had not entered into a contract for servers and disks of an old plan by the time that provision of the new plan started.)
  • It is not possible to use a mixture of old plans and new plans between servers and disks. For example, a disk from the new plan cannot be connected to a server from an old plan. (The method for migrating old plan resources to the new plan is explained below.)

Control panel display

A display indicating whether a new plan or old plan is being used is added to the resource list screen for servers and disks of Ishikari Zone No. 1.


The display indicating old plan or new plan is not shown for customers who use only the new plan for all servers and disks in Ishikari Zone No. 1. The display is only shown when there is a mixture of new and old plans, or if only old plans are being used.

How to migrate from old plans for servers and disks

When continuing to use an old plan, you will not be able to use enhanced plans or services which are newly available for Ishikari Zone No. 1. You can use the following procedures to migrate from an old plan to the new plan.


Due to updating of equipment used in the cloud infrastructure system, the new plan is not compatible with some infrastructure systems for the old plan. Therefore, use is not possible by combing resources from old plans and new plans. For example, it is not possible to combine a new plan server and an old plan disk. Therefore, when migrating to the new plan, migration to the new plan must be performed for both the server and the disk.


After temporarily stopping the server for the old plan, you can migrate to the new plan by executing Change plan . Select [New Plan] for the change destination plan. (You can also update to specifications differing from the old plan at the same time as migrating.)


Migrate by using disk copy to copy contents to the new plan disk which will be newly created. Select the target old plan disk and then click the [Copy] button at the top-right of the screen. Select [Disk] for the copy destination and then click the [Next] button.

The copy destination disk settings screen is displayed. Use the generation selection radio buttons at the top of the screen and select [New Plan]. Confirm that the disk which you want to migrate is selected as the source disk and that the same capacity is selected for disk size. Next, click the [Create] button.


Furthermore, conversion to the new plan is performed automatically after operations for OS reinstall. Please also update to the new plan for the generation of connected servers.

When simultaneously updating server and disk to the new plan

You can simultaneously replicate the server and disk for an old plan to a new plan by using the cloning function for the old plan server and disk. For information on using the cloning function, please refer to Cloning function.


When using the cloning function, resources are created as temporary replications. Therefore, if an IP address has been assigned from a shared network, the current IP address will be changed. (There is no problem when using a unique IP address assigned to the customer; for example, in the case of router + switch.)
If it is necessary to migrate to the new plan without changing the IP address that was assigned from a shared network, follow the procedures given above to individually migrate the server and disk to the new plan.

Cautions when using API

API specifications have changed in conjunction with the start of the new plan. For example, parameters have been added to clearly indicate whether a new plan or old plan is being used for operation. You can continue to use API in the conventional format; however, it will behave as follows.

  • If an old plan is not clearly specified, the new plan will be used when creating new servers and disks.
  • Although you can continue to use the ServerPlan.ID parameter, it is not recommended.
  • ServerPlan.ID for both the new plan and old plan is displayed when executing GET /product/server. However, when creating the server, a new plan is selected regardless of which ID is specified.

When creating an old plan server or disk from API, you must clearly specify the plan generation in the newly added Generation parameter. Either 100 (old plan) or 200 (new plan) can be specified.
Also, we recommend specifying the ServerPlan.CPU and ServerPlan.MemoryMB parameters instead of ServerPlan.ID, which is no longer recommended.


Only accounts which created a server or disk in Ishikari Zone No. 1 before provision of the new plan was started can create new servers/disks for an old plan or change a plan to the old plan.

1. Create a server/disk

Specifying ServerPlan.ID when creating a server is not recommended. We now recommend plan specification using ServerPlan.CPU and ServerPlan.MemoryMB.
The following is an example when creating a server with one CPU core and memory of 1,024MB (1GB).

POST /server

  "Server": {
    "Name": "1Core-1GB",
    "ServerPlan": {
      "CPU": 1,
      "MemoryMB": 1024

In the example above, the new plan is selected if the old plan is not clearly specified in the Generation parameter. If you want to create an old plan, clearly specify the old plan by entering 100 for the Generation parameter.

POST /server

  "Server": {
    "Name": "旧プラン 1Core-1GB",
    "ServerPlan": {
      "CPU": 1,
      "MemoryMB": 1024,
      "Generation": 100

Similar to servers, you must also specify the Generation parameter when creating an old plan for disks.

POST /disk

 "Disk": {
    "Name": "旧プラン SSD-20G",
    "Plan": {"ID": 4},
    "SizeMB": 20480,
    "Generation": 100

2. Behavior of plan change operation

At the time of plan change operation, a new plan or old plan for the server is automatically selected based on a plan that matches the first disk connected to the target server. If the disk is not yet connected, the new plan is set automatically.

We do not recommend specifying PUT /server/:serverid/to/plan/:planid. When performing plan change operations for a server in the future, please use the PUT /server/:serverid/plan format. If Generation is omitted, a new plan or old plan for the server is automatically selected based on a plan that matches the first disk.

PUT /server/:serverid/plan

  "CPU": 1,
  "MemoryMB": 1024,
  "Generation": 100

Appendix: Default Generation by zone

Currently, multiple Generation settings are possible only for Ishikari Zone No. 1 where new plans and old plans exist. Plans in the zone are uniform for Ishikari Zone No. 2 and Tokyo Zone No. 1. For these zones, only the 100 plan can be selected. If a plan is not specified, 100 will be used as the default value.

The following is a list of values that can be used in each zone and default values for when no value is specified.

Zone name List of Generation Default Generation
Ishikari Zone No. 1 100 (old plan)/200 (new plan) 200
Ishikari Zone No. 2 100 100
Tokyo Zone No. 1 100 100


Normally, it is not necessary to use the old plan to newly create both a server and a disk. Only use the old plan in the following case.
Create a new disk for connecting to an old plan server which has not been migrated to the new plan
Create a new server for connecting to an old disk which has not been migrated to the new plan

Tool for migration from old plan to new plan

In Offers on GitHub , SAKURA Cloud provides tools for easily migrating servers and disks created using an old plan to the new plan. By using this tool, you can easily migrate to a new plan with advantageous functions and prices, without the need to change network configuration.

Required environment

The following conditions must be satisfied in order to use the tool.

  • An API key possessing operating authority for the server targeted for migration must be issued.
  • It must be possible to use Linux, FreeBSD, Windows, MacOS or other CLI environment in which the migration tool operates. (Migration is not possible by running the tool in the server targeted for migration.)

Furthermore, the following items required for executing the tool must be prepared in advance:

  • API key (set of access token and access token secret)
  • Resource ID, name, tag, and other information of the server targeted for migration that will be specified when executing the tool


Downloading of tools

You can download the tool from Here . The end of the file name indicates the environment in which the tool operates (for example, “linux-amd64” indicates use in a 64-bit environment Linux). Please download the appropriate file.

The downloaded archive is a zip file. Use the unzip command or other method to expand the file.

Execution of tools

The body of the tool is cloud-plan-migrate inside the expanded directory. Here, specify the resource ID of the server targeted for migration as a parameter and then execute the tool.

$ cloud-plan-migrate <サーバのリソースID または名前>


If you want to migrate multiple servers, you can specify multiple resource IDs in the parameter. Furthermore, in addition to the resource ID, you can specify the server name. (If there are multiple servers with the same name, the tool will be executed for all servers. Please be careful when setting the terminal if the name uses multi-byte characters, such as in the Japanese language.)

Also, by using the --selector option and executing an arbitrary tag name in the parameter, you can perform batch execution for all servers to which that tag is assigned. If the old plan has a large amount of servers, you can easily execute the migration tool by assigning dedicated tags to the servers targeted for migration.

$ cloud-plan-migrate --selector <タグ名>

After execution, an entry prompt is displayed. Enter the token and secret here.

Your API AccessToken is not set
   Enter your token: <アクセストークンを入力>
Your API AccessTokenSecret is not set
   Eneter your secret: <アクセストークンシークレットを入力>

Using the tool to execute migration work

The tool automatically executes migration work after acquiring information on the target server, information on the API key, and other information required after the server. The main work executed by the tool is as follows.

  1. Shut down the server if it is running.
  2. Disconnect disks.
  3. Clone each disk and create a new plan disk.
  4. Connect disks.
  5. Change the server plan.
  6. Start server (Default: Enabled; can be set to “disabled” as an option).
  7. Delete old disks (Default: Disabled; enabled only when specified as an option).

During processing, the migration progress status for the target resource is displayed on the screen. Logs are successively output in a migrate-[yyyyMMdd-HHmmss].log format under the current directory.


An error will occur and migration work will not be performed if no disk is connected to the target server, or if even one server is included that has already been migrated to a new plan.

Other command options

In addition to the --selector option which was just introduced, you can also use the following command line options.

  • --token: Specify the API key (access token). You can also specify the environment variable SAKURACLOUD_ACCESS_TOKEN.
  • --secret: Specify the API key (access token secret). You can also specify the environment variable SAKURACLOUD_ACCESS_TOKEN_SECRET.
  • --disable-reboot: The server is not rebooted after plan migration is finished.
  • --cleanup-disk: Delete the old plan disk after plan migration is finished.
  • --assumeyes or -y: Omit confirmation before executing the migration work.


When the --token or --secret option is used, an entry prompt is not displayed after execution. However, in some cases, API key information may be displayed after the process being executed is confirmed by another user that is currently logged in. Please use while paying sufficient attention.