Stay organized with collections
Save and categorize content based on your preferences.
Assessing your source database and how its usage maps to Spanner
requires evaluating your business, technical, operational,
and financial needs. We recommend covering the following key areas for your
assessment:
Business goals: Define the specific business problems
Spanner solves, such as scalability, availability, and
consistency. Establish measurable success criteria, such as reduced latency,
increased transaction volume, and cost reduction.
Cost analysis: Calculate the potential total cost of using Spanner
(compute, storage, and network) and compare it to your current database costs.
Factor in one-time migration costs and ongoing operational expenses. For more
information, see Spanner pricing.
Schema compatibility: Analyze the existing source database schema for
possible incompatibilities with Spanner such as data types, constraints,
indexes, or stored procedures. Plan for schema modifications and data
transformations to appropriately map your source database schema to Spanner. For
more information, see
Schema design best practices.
Data consistency and transactions: Understand Spanner's
external consistency model and its differences from your source database
transaction model. Evaluate the impact on your application logic. For more
information, see
Spanner: TrueTime and external consistency.
Data locality and regional configurations: Determine optimal
Spanner deployment topology such as regional, dual-region, or multi-region
deployments based on user locations, latency requirements, and cost
considerations. For more information, see
Instances configurations.
Application code compatibility: Inventory all database interactions with
your application code. Identify areas that require modification because of
differences in SQL dialect, client libraries, and transaction management.
Performance and scalability requirements: Define current and projected
workloads such as read and write ratios, transaction rates, and data volume.
Determine acceptable latency and throughput. For more information on
Spanner's performance, see
Performance overview.
Migration strategy and downtime: Develop a detailed migration plan,
including data extraction, transformation, loading, and validation. If downtime isn't a concern,
you can perform a one-time bulk load and cutover. Otherwise, consider minimizing
downtime. Define a rollback plan.
Operational consideration: Plan for changes in database administration,
monitoring, and disaster recovery. Assess the learning curve for the team.
Integrate Spanner with existing operational tools and processes
For more information, see
Disaster recovery overview.
[[["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-28 UTC."],[],[],null,["# Assess your migration\n\nAssessing your source database and how its usage maps to Spanner\nrequires evaluating your business, technical, operational,\nand financial needs. We recommend covering the following key areas for your\nassessment:\n\n- **Business goals**: Define the specific business problems Spanner solves, such as scalability, availability, and consistency. Establish measurable success criteria, such as reduced latency, increased transaction volume, and cost reduction.\n\n\u003c!-- --\u003e\n\n- **Cost analysis** : Calculate the potential total cost of using Spanner (compute, storage, and network) and compare it to your current database costs. Factor in one-time migration costs and ongoing operational expenses. For more information, see [Spanner pricing](/spanner/pricing).\n\n\u003c!-- --\u003e\n\n- **Schema compatibility** : Analyze the existing source database schema for\n possible incompatibilities with Spanner such as data types, constraints,\n indexes, or stored procedures. Plan for schema modifications and data\n transformations to appropriately map your source database schema to Spanner. For\n more information, see\n [Schema design best practices](/spanner/docs/schema-design).\n\n- **Data consistency and transactions** : Understand Spanner's\n external consistency model and its differences from your source database\n transaction model. Evaluate the impact on your application logic. For more\n information, see\n [Spanner: TrueTime and external consistency](/spanner/docs/true-time-external-consistency).\n\n- **Data locality and regional configurations** : Determine optimal\n Spanner deployment topology such as regional, dual-region, or multi-region\n deployments based on user locations, latency requirements, and cost\n considerations. For more information, see\n [Instances configurations](/spanner/docs/instance-configurations#configuration).\n\n- **Application code compatibility**: Inventory all database interactions with\n your application code. Identify areas that require modification because of\n differences in SQL dialect, client libraries, and transaction management.\n\n- **Performance and scalability requirements** : Define current and projected\n workloads such as read and write ratios, transaction rates, and data volume.\n Determine acceptable latency and throughput. For more information on\n Spanner's performance, see\n [Performance overview](/spanner/docs/performance#typical-workloads).\n\n- **Migration strategy and downtime**: Develop a detailed migration plan,\n including data extraction, transformation, loading, and validation. If downtime isn't a concern,\n you can perform a one-time bulk load and cutover. Otherwise, consider minimizing\n downtime. Define a rollback plan.\n\n- **Operational consideration** : Plan for changes in database administration,\n monitoring, and disaster recovery. Assess the learning curve for the team.\n Integrate Spanner with existing operational tools and processes\n For more information, see\n [Disaster recovery overview](/spanner/docs/backup/disaster-recovery-overview).\n\n- **Security** : Review Spanner's security features such as\n [authentication](/spanner/docs/authentication), [authorization](/spanner/docs/iam),\n and [encryption](/spanner/docs/encryption-in-transit). Ensure compliance with relevant\n regulations.\n\nSource specific guides\n----------------------\n\n- MySQL: [Migrate from MySQL to Spanner](/spanner/docs/migrating-mysql-to-spanner)."]]