When you're migrating your schema, data, and metadata from a source database to a
destination database, you want to ensure that all of this information is
migrated accurately. Database Migration Service provides a high-fidelity way to
migrate database objects (including the schema, data, and metadata) from one
database to another.
All of the following data, schema, and metadata components are migrated as part
of the database migration:
Data
All tables from all databases and schemas, excluding the following system
databases: sys, mysql, performance_schema,
and information_schema.
Schema
Naming
Primary key
Data type
Ordinal position
Default value
Nullability
Auto-increment attributes
Secondary indexes
Metadata
Stored procedures
Functions
Triggers
Views
Foreign key constraints
Continuous migration
Data manipulation language (DML) and data definition language (DDL)
changes to all data, schemas, and metadata listed above are
updated during continuous migrations.
What isn't migrated
When migrating a MySQL database, MySQL system databases aren't migrated. These databases contain information about users and privileges. Because of this, user account login information must be managed in the destination Cloud SQL database instance directly.
To add users to the Cloud SQL destination instance, navigate to the instance and add users from the Users tab, or add them from the MySQL client.
In addition to users and privileges, non-default flag settings aren't migrated to the Cloud SQL destination instance. Run
SHOW VARIABLES
on your source database before migrating your schema, data, and metadata to the
destination database, and then run it again on the Cloud SQL
database. Update flag settings as needed on the Cloud SQL database to
replicate the source settings.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eDatabase Migration Service ensures accurate migration of database objects, including schema, data, and metadata, from one database to another.\u003c/p\u003e\n"],["\u003cp\u003eAll tables, excluding MySQL system databases such as \u003ccode\u003esys\u003c/code\u003e, \u003ccode\u003emysql\u003c/code\u003e, \u003ccode\u003eperformance_schema\u003c/code\u003e, and \u003ccode\u003einformation_schema\u003c/code\u003e, are migrated.\u003c/p\u003e\n"],["\u003cp\u003eSchema elements like naming, primary keys, data types, and metadata components such as stored procedures, functions, and triggers are all migrated.\u003c/p\u003e\n"],["\u003cp\u003eUser account login information and non-default flag settings are not migrated; they must be managed directly in the Cloud SQL destination instance.\u003c/p\u003e\n"],["\u003cp\u003eData manipulation language (DML) and data definition language (DDL) changes to data, schema, and metadata are continuously updated during ongoing migrations.\u003c/p\u003e\n"]]],[],null,["# Migration fidelity\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nMySQL \\| [PostgreSQL](/database-migration/docs/postgres/migration-fidelity \"View this page for the PostgreSQL version of Database Migration Service.\") \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/migration-fidelity \"View this page for the PostgreSQL to AlloyDB version of Database Migration Service.\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nWhen you're migrating your schema, data, and metadata from a source database to a\ndestination database, you want to ensure that all of this information is\nmigrated accurately. Database Migration Service provides a high-fidelity way to\nmigrate database objects (including the schema, data, and metadata) from one\ndatabase to another.\n\nAll of the following data, schema, and metadata components are migrated as part\nof the database migration:\n\n### Data\n\n- All tables from all databases and schemas, excluding the following system databases: `sys`, `mysql`, `performance_schema`, and `information_schema`.\n\n### Schema\n\n- Naming\n\n- Primary key\n\n- Data type\n\n- Ordinal position\n\n- Default value\n\n- Nullability\n\n- Auto-increment attributes\n\n- Secondary indexes\n\n### Metadata\n\n- Stored procedures\n\n- Functions\n\n- Triggers\n\n- Views\n\n- Foreign key constraints\n\n### Continuous migration\n\nData manipulation language (DML) and data definition language (DDL)\nchanges to all data, schemas, and metadata listed above are\nupdated during continuous migrations.\n\n### What isn't migrated\n\nWhen migrating a MySQL database, MySQL system databases aren't migrated. These databases contain information about users and privileges. Because of this, user account login information must be managed in the destination Cloud SQL database instance directly.\n\nTo add users to the Cloud SQL destination instance, navigate to the instance and add users from the **Users** tab, or add them from the MySQL client.\n\n[Learn more about creating and managing MySQL users](/sql/docs/mysql/create-manage-users).\n\nIn addition to users and privileges, non-default flag settings aren't migrated to the Cloud SQL destination instance. Run\n[\u003cvar translate=\"no\"\u003eSHOW VARIABLES\u003c/var\u003e](https://dev.mysql.com/doc/refman/8.0/en/show-variables.html)\non your source database before migrating your schema, data, and metadata to the\ndestination database, and then run it again on the Cloud SQL\ndatabase. Update flag settings as needed on the Cloud SQL database to\nreplicate the source settings.\n| **Note:** Some flags that apply to a primary database may not make sense on a replica. Also, not all MySQL flags are allowed on a Cloud SQL instance. Refer to the [Cloud SQL documentation](/sql/docs/mysql/flags) for more information."]]
