Help Center/ Migration Center/ Service Overview/ Notes and Constraints
Updated on 2025-08-19 GMT+08:00
View PDF
Share

Notes and Constraints

This section describes the MgC constraints about region availability, server migration, cross-AZ migration, and storage migration.

Region Availability

MgC is available in AP-Singapore, TR-Istanbul, LA-Sao Paulo1, and LA-Santiago. Although MgC is a region-level service, it offers global capabilities, enabling you to migrate to any region on the cloud. For information security purposes, all collected data and task records are stored in the regions where MgC operates.

Feature Constraints

The following lists MgC features and their constraints.

Migration plans can be created only in the AP-Singapore and TR-Istanbul regions.

Table 1 Constraints on migration plans (new)

Migration Plan Type

Constraint

Batch server migration
  • Only one migration workflow can be created for a migration plan.
  • A migration plan can only include source servers from the same platform.
  • A server can only be included in one migration plan.
  • A migration plan can include a maximum of 100 servers.

Cross-AZ server migration

Batch object storage migration
  • Only one migration workflow can be created for a migration plan.
  • A migration plan can be used to migrate buckets from the same source platform and to the same target region.
  • A source bucket can be included in multiple migration plans.
  • You can define the migration scope for a source bucket using multiple prefixes, but only one prefix can be specified to control data replacement in the target bucket.

Batch file storage migration
  • Only one migration workflow can be created for a migration plan.
  • A maximum of 100 file systems can be added to a migration plan.
  • Target file systems included in a migration plan must be in the same region.

To ensure proper resource allocation and stable system running, the following quota limits are set for all workflows:

  • A maximum of 50 migration workflows can be created per day in a project.
  • A maximum of 1,000 servers can be migrated at the same time. Any additional servers beyond this limit will cause workflows to pause at the initial step and remain in a pending state. Whenever any ongoing migration completes, a paused workflow will automatically resume, following the order in which the workflows were created.
  • A maximum of 100 resources can be included in a workflow.

Constraints on MgC Agent

Table 2 Constraints on MgC Agent

Item

Constraint

Servers for deploying the MgC Agent for Windows
  • Supported OSs: Windows Server 2019, Windows Server 2016, Windows Server 2012, Windows 10, or Windows Server 8.1
  • PowerShell version: 3.0 or later
  • Specifications: at least 4 CPUs and 8 GB of memory
  • At least 20 GB of available space on the drive (drive C by default) for installing the MgC Agent

For more information, see Preparations in the section "Installing the MgC Agent on Windows."

Servers for deploying the MgC Agent for Linux
  • Supported OS: CentOS 8
  • Specifications: at least 4 CPUs and 8 GB of memory To use big data-related features, prepare at least 8 CPUs and 16 GB of memory.
  • At least 20 GB of available space on the disk for installing the MgC Agent

For more information, see Preparations in the section "Installing the MgC Agent on Linux."

Connection to MgC
  • An account can have up to 100 online MgC Agents at the same time.
  • A maximum of five MgC Agents (regardless of the status) can be registered with a single migration project.

Resource collection tasks
  • A maximum of 50 resources can be included in a single task.
  • A collector can collect a maximum of 50 resources across tasks at the same time.

Migration Constraints

The following lists the constraints for each migration scenario supported by MgC.

Table 3 lists the constraints on server migration with MgC.

Table 3 Constraints on server migration

Item

Constraint

Batch server migration plans
  • Only one migration workflow can be created for a migration plan.
  • A migration plan can only include source servers from the same platform.
  • A server can only be included in one migration plan.
  • A migration plan can include a maximum of 100 servers.

Batch server migration workflows
  • Each server can be migrated by only one workflow.
  • Server migration workflows cannot migrate servers that boot using UEFI and have no targets associated. To migrate such servers using a workflow, associate them with existing UEFI servers on Huawei Cloud in advance. You can also use the Server Migration Service (SMS) to migrate such servers.
  • SMS manages tasks in server migration workflows. The notes and constraints for SMS also apply to server migration using MgC. For details, see What Are the Notes, Constraints, and Precautions for Server Migration?
  • If you want to migrate a server for the second time, you need to stop the initial migration workflow, stop the SMS-Agent process on the server, delete the server record from the SMS console, and create a new workflow.

Resource assessment and recommendations
  • Target servers must have disks at least as large as those on source servers.
  • Target servers must use the same type of OS as source servers.
  • There must be sufficient quotas for recommended disk types in the target region.

Precautions during migration

After a migration workflow is created, the source servers must not be stopped or restarted, and disks on the source servers must not be changed. Otherwise, the migration will fail.

Source server settings

Any firewall or antivirus software must be stopped and WinRM must be started on Windows source servers. You can run winrm quickconfig on the PowerShell CLI to check the WinRM settings.

Network connectivity

Source servers must be able to access Linux target servers over port 22 and Windows source servers over ports 22, 8899, and 8900.

Table 4 lists the constraints on cross-AZ server migration with MgC.

Table 4 Constraints on cross-AZ server migration

Item

Constraint

Cross-AZ batch server migration plans
  • Only one migration workflow can be created for a migration plan.
  • A migration plan can only include source servers from the same platform.
  • A server can only be included in one migration plan.
  • A migration plan can include a maximum of 100 servers.

Source server specifications

Automated installation of KVM drivers is not supported for cross-AZ migrations. You need to manually install KVM drivers on source servers that use Xen by referring to Installing KVM Drivers.

Source server quantity
  • A maximum of 30 servers can be migrated at a time using the automated one-stop process.
  • A maximum of 100 servers can be migrated at a time using the manual process.
  • Under the same environmental conditions, the more source servers there are being migrated, the slower the migration speed.

Source server disks
  • Servers whose system disk is larger than 1 TB cannot be migrated.
  • You are not advised to migrate servers whose disk capacity exceeds 4 TB.

Source server status

Frozen source servers in the retention period cannot be migrated.

Target servers
  • Migrating to existing target servers is not supported.
  • Target servers created by MgC are billed on a pay-per-use basis. You can manually change their billing mode from pay-per-use to yearly/monthly after the migration is complete.

Shared file systems

MgC cannot migrate files from shared file systems such as Network File System (NFS) or Common Internet File System (CIFS), or from Network Attached Storage (NAS) devices.

Applications bound to hardware

MgC cannot migrate OSs that contain applications bound to hardware.

Servers added to domains

After migrating servers added to a domain, you need to add them to the domain again.

Encrypted files

MgC cannot migrate OSs that contain protected folders or encrypted volumes.

External storage of servers

MgC cannot migrate data from the external storage attached to a source server.

Server passwords

Table 5 and Table 6 list the constraints on storage migration using MgC.

Table 5 General constraints on storage migration

Item

Constraint

Objects with multiple versions

By default, only the latest version of objects in source buckets is migrated.

Storage class of target buckets

The storage class of target buckets can only be Standard or Infrequent Access. You can change the storage class of target buckets after the migration is complete.

Migration object
  • Object names cannot contain special characters.
  • The size limit for a single object is 4.76837158203125 TB (500 MB × 10,000). If the limit is exceeded, the migration may fail.

Migration network

Migrations are supported over public networks, private networks, and private lines.

Symbolic links
  • Symbolic links cannot be used for specifying migration paths which define the migration scope. To migrate a path pointed to by a symbolic link, you need to:
    • Enter the actual path when specifying the migration path.
    • After the migration is complete, manually create a symbolic link to the path at the target.
  • For migration from NAS_SMB or migration from NAS_NFS to OBS, symbolic links cannot be migrated.
  • For migration from NAS_NFS to NAS_NFS, symbolic links can be migrated by enabling metadata migration. Otherwise, these files will be skipped during the migration.
  • For migration from Alibaba Cloud OSS to NAS_NFS, symbolic links can be migrated by enabling metadata migration. Otherwise, the symbolic links will lose their link functionality and become regular files after the migration.
    NOTICE:

    If the objects that symbolic links point to are not completely migrated to the target, these symbolic link files may fail the verification. As a result, the task will be in a failed status. In this case, wait until the involved objects are completely migrated to the target, and try the task again.

Hard links

For migration from NAS_NFS to NAS_NFS, hard links can be migrated by enabling metadata migration. Otherwise, these files will be skipped during the migration.

Migration scope

You can migrate a single bucket or multiple buckets in batches.

Metadata migration

NOTE:

For migration from Tencent Cloud COS, only user-defined metadata can be migrated. For details, see User-Defined Metadata.
  • Only Chinese characters, English characters, digits, and hyphens (-) can be migrated. Other characters cannot be migrated.
    • Chinese characters are URL-encoded during the migration.
      CAUTION:

      Chinese punctuation marks cannot be URL-encoded during the migration. If metadata contains Chinese punctuation marks, the metadata and the corresponding object will fail to be migrated.

    • English characters, digits, and hyphens (-) are directly migrated without being encoded.
  • For heterogeneous migrations, metadata cannot be migrated.

Archived data

To migrate archived data from object storage, you must restore it first. You need to:

  • Ensure the restoration is complete before creating migration workflows.
  • Configure a validity period for restored data based on the total amount of data to be migrated. This helps prevent migration failures because restored data becomes archived again during the migration.
  • Pay your source cloud vendor for restoring archived data. To learn about the pricing details, contact your source cloud vendor.

Concurrent subtasks

User-defined. There cannot be more than 10 concurrent subtasks for each online migration node.

For example, if there are 2 online migration nodes, the maximum number of subtasks can be 20 or any number below.

Object list files

These files must be stored in the same region as the target bucket.

  • These files must be in .txt format, and their metadata Content-Type must be text/plain. The directory storing these files can only contain .txt files.
  • A single file can contain a maximum of 100,000 lines.
  • A single file cannot exceed 300 MB.
  • A maximum of 10,000 list files can be stored in the folder.
  • The files must be in UTF-8 without BOM.
  • The length of each line in a file cannot exceed 65,535 characters, or the migration will fail.
  • The Content-Encoding metadata of the files must be left empty, or the migration will fail.
  • In the files, a tab character (\t) must be used to separate the URL and new file name in each line. The format is [URL][Tab character][New file name at the target]. Only the Chinese and special characters in the source and target file names must be URL encoded.
  • Spaces are not allowed in each line in a file. Spaces may cause migration failures because they may be mistakenly identified as object names.
Table 6 Constraints on file system migration

Scenario

Constraint

Migration source: SMB systems
  • File systems where a single directory contains more than 5 million files cannot be migrated.
  • Resumable transfer is not supported.
  • Symbolic links cannot be migrated.

Migration source: NAS file systems
  • The following types of files can be migrated: regular files, directories, symbolic link files, and hard link files.
    CAUTION:

    If the file handle of a source file is occupied or the source file is deleted, the migration of the file will fail.

  • Special files such as character device files, block device files, sockets, and pipe files cannot be migrated.
  • The metadata of symbolic link files cannot be migrated.

Migration from non-SMB file systems to SMB file systems

In SMB file systems on Windows, file names are case-insensitive, so files with names that differ only in letter casing cannot coexist in the same directory. If such files exist at the source, you need to rename them before the migration. Otherwise, only the last uploaded files will be retained at the target.

For example, if a source directory contains two files dir/A.txt and dir/a.txt, and dir/A.txt is last uploaded to the target, file dir/a.txt will be retained at the target, but its content will be that of dir/A.txt.