Migrating an application to Google Cloud Spanner takes more than copying its data. Plan for schema conversion, application changes, data movement, validation, and a cutover with a defined fallback. The right approach depends on your source database, data volume, outage limit, application behavior, and replication needs.
What to decide before you start
First document the conditions that determine which migration path is safe and practical. A one-time database load and a large production migration with strict uptime requirements are different projects.
- Source database and version: identify the engine and version so you can check which migration tools and conversion guidance apply.
- Data volume and growth: estimate the current dataset and how quickly it changes.
- Downtime tolerance: establish how long writes can be paused, if at all.
- Application dependencies: inventory query patterns, database clients or ORMs, transaction behavior, and any assumptions about the source database.
- Database-side logic: identify stored procedures, triggers, and other custom behavior that must be replaced or redesigned.
- Operational requirements: document network and compliance constraints, replication needs, and how the system must recover if cutover fails.
These details affect the schema, tooling, migration method, and rollback plan. Without them, a source-specific runbook or tool recommendation would be premature.
Follow a migration sequence that includes the application
A practical sequence is to assess the source, convert and review the schema, adapt the application, test and optimize, move the data, validate the result, and then cut over with a fallback plan. Treat these as connected work: schema and application changes should be tested together before production data is switched over.
#1 Best Overall
1. Convert the schema, then review it
Extract the source database definition and use an appropriate conversion tool, such as Spanner Migration Tool, to create an initial Spanner schema where supported. Do not treat automated conversion as final. Review the generated schema against the source data and the application’s behavior, then deploy and test it in staging with representative data before production.
Pay particular attention to:
- Data types: confirm that the target type preserves the source values’ meaning and full range.
- Primary keys and locality: check that key choices suit the data and the way the application accesses it.
- Indexes: verify that the schema supports the application’s query patterns.
- Constraints and unsupported features: identify anything that needs a different design in Spanner.
For MySQL, Google’s documented examples include mapping integer types to INT64, boolean representations to BOOLEAN, and character or text types to STRING. These are starting points, not automatic guarantees of equivalence: validate ranges and semantics against the actual data. Spanner Migration Tool can report conversion details, warnings, and items it did not convert; it does not convert stored procedures or triggers.
Rank #2
2. Adapt the application to Spanner
Plan application changes as part of the migration rather than postponing them until after the data is loaded. Choose either Spanner’s GoogleSQL interface or its PostgreSQL interface based on the application’s ecosystem and compatibility needs. The choice does not remove the need to review source-specific SQL behavior and differences.
Update and test the database connection, client or ORM configuration, queries, and transaction handling. Review read and write patterns and test application behavior against Spanner. Because Spanner does not run user code at the database level, move required stored-procedure and trigger behavior into application code or redesign it for the target architecture.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
Choose a data-migration method
The central choice is whether to keep the source online during migration or pause writes for a dump-and-load. Make this decision using your outage tolerance, source and tooling support, consistency requirements, and ability to process changes fast enough for cutover.
| Approach | What it involves | Key consideration |
|---|---|---|
| Live migration | Transfer a consistent source snapshot, then capture and apply changes made after that snapshot using change data capture (CDC). | The migration must keep up with incoming changes. If the CDC apply rate cannot exceed the rate of new changes, lag can prevent a safe cutover. Plan connectivity among the source, Spanner, and migration tooling, and account for buffering changes while the snapshot transfers. |
| Downtime migration | Create a consistent dump, transfer it to Cloud Storage, and load it through a supported path, such as Dataflow or Spanner Migration Tool. | Plan when writes stop and how the snapshot remains consistent. Google warns that a downtime migration on a live database might cause data loss. Where supported, multiple smaller dump files can improve parallel loading. |
Source-specific examples are not universal runbooks
For PostgreSQL-to-GoogleSQL migrations, Google’s guidance describes exporting data with PostgreSQL COPY to CSV, uploading it to Cloud Storage, and importing it with Dataflow or client libraries. The documented MySQL guidance includes sample-data loading, ongoing comparisons, and a reverse-replication option for fallback. Confirm that a method and its tooling support your exact source and target setup before using it.
Match tools to the migration stage
Google lists different tools for different parts of the work. Their suitability depends on the source engine, migration stage, data size, and validation needs; no single tool replaces schema review, application refactoring, or cutover planning.
- Spanner Migration Tool: assessment, schema conversion, and data migration.
- Datastream: CDC and bulk data for supported sources.
- Dataflow: bulk and live-migration workflows.
- Data Validation Tool: standardized data validation.
- Database Migration Assessment: basic assessment for MySQL and PostgreSQL.
Check the current documentation for source coverage and requirements before choosing a tool; support varies by source and migration stage.
Validate the target before cutover
Do not use a successful load as the only indication that a migration is ready. Test application functions against Spanner, run representative production-level workloads, and compare source and target results against the business’s required consistency level. For large MySQL comparisons, Google’s guidance describes using Dataflow joins to match keyed rows.
Define acceptance criteria before switching production traffic. They should reflect what the business needs the data and application to do, not just whether the migration process completed. If a live migration is in progress, include CDC lag and the ability to continue applying changes in the cutover decision.
Plan cutover and fallback together
Write down the cutover steps, decision criteria, and rollback behavior before the production change. Decide what happens to writes during the transition and how the team will recover if the target does not meet its acceptance criteria. A fallback that simply points the application back to the source may not be sufficient if writes have already gone to Spanner.
For MySQL, Google’s documented reverse-replication approach reads Spanner change streams, filters changes that were already forwarded, transforms rows, checks whether the source already contains newer data, and writes changes back to the source. This is a source-specific option, not a general guarantee that reverse replication is available or suitable for other database engines. Confirm an applicable fallback design for your source before cutover.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
