The third migration phase involves performing the actual deployment.  This includes setting up the infrastructure, provisioning your database, and migrating your data.  Now if you decide to use automation to accomplish these tasks, you will need to schedule and execute your jobs and carefully monitor the progress.  Google provides multiple ways to automate your deployments. You can use the Google Cloud SDK to develop custom scripts.  You can provision resources using things like Terraform or Kubernetes templates.  And you can stitch everything together using services like Cloud Run or Cloud Functions.

Schema conversion is a common step, and it can greatly increase both the risk and difficulty of any migration.  You want to make sure to take advantage of tools like Dataflow, Cloud Data Fusion, and Cloud Composer when appropriate.   Also remember, if you are updating your data, then you also need to update your queries as well.  So you need a way to verify that everything is going to work.

Your migration should look something like this.  First, you will need to finish copying all your existing records to the new environment.  Then, you will need to test everything and fix any issues.  Third, you will migrate your client connections to the new database.  And fourth, you can retire your old database if desired.

Now, if you are going with a live migration, then you will need to understand how to correctly drain your client connections.  Draining involves pausing and waiting for any in-process updates to complete.  Basically, you need to stop making any changes to the original database, and give your new database a chance to catch up.   Once that completes, it is also a good idea to take a snapshot or create a backup of your new database, before you start making any changes.  After all that, then you can tell your clients to start using the new environment.  So be aware, you might need to suspend database updates for a short period of time.

It is also very important to have enough resources on-hand to deal with any potential integration issues.  Ideally, your migration will go off without a hitch, but that does not always happen.  You want to make sure that you have the necessary time and people available to fix any last-minute issues.

Now, once your data migration is complete, you are going to do a final validation to ensure that your new system is working as expected.  Having proper unit, integration, and regression tests is extremely important.  You need to not only verify that your new database is working, but that all your dependent applications are working as well.

You also want to ensure that you are getting the right level of performance.  You can use Cloud Logging and Monitoring to help verify that.  I also recommend setting up alerts to let you know about issues as soon as possible.  If your database instance should never need more than 75% CPU, then set an alert at 76.

Ultimately, the difficulty of this step is going to depend on how much time you spent on the first two phases.  If you accurately identified all your dependencies, and you made the appropriate plans, then this phase should just be a matter of execution.