In this blog, we'll cover the Plan B of our migration strategy.
To learn more about different strategies(differences, risk, steps, and comparison) including this one please read previous blog Migrate Aurora v1: Strategies Explained

Migrating using the snapshot-and-restore method involves taking a backup of your existing Aurora Serverless v1 cluster and restoring it to a new provisioned cluster that you’ll then convert to Aurora Serverless v2. This approach minimizes risk by allowing you to work on a cloned environment and provides an easier rollback path.

Database Migration Process

(Start Migration)  
      ↓  
(Verify Engine Version) → (Schedule Maintenance) → (Notify Stakeholders) → (Take Final Snapshot)  
      ↓  
(Test) → (Restore Snapshot) → (Upgrade Engine Version) → (Convert Writer Instance)  
      ↓  
(Add Optional Reader Instances) → (Trigger Failover)  
      ↓  
(Update Application Connection Settings) → (Validate Connectivity and Performance)  
      ↓  
           ┌───────────────────────────────┐  
           │      Migration Successful?    │  
           └───────────────────────────────┘  
                   ↙             ↘  
                Yes                No  
                 ↓                 ↓  
        (Finalize Migration)   (Initiate Rollback)  
                 ↓                 ↓  
        (Update Documentation)    (Restore from Snapshot)  
                                    ↓  
                               (Revert Application Settings)  
                                    ↓  
                               (Validate Rollback)  
                                    ↓  
                               (Notify Stakeholders Rollback)  
                                    ↓  
                                (End Rollback) 

Milestone 1: Pre-Migration Preparation

Step 1: Verify Engine Version & Compatibility

1. Log into the AWS Management Console and navigate to the RDS Console.
2. Under Databases, select your Aurora Serverless v1 cluster.
3. Check the Configuration tab to confirm your engine version.
   • If you’re not on a supported version (minimum PostgreSQL 13.6 for Serverless v2), plan a minor upgrade on your current cluster before proceeding.
4. Document: Record the engine version and cluster settings.

Step 2: Schedule Downtime and Notify Stakeholders

1. Plan a Maintenance Window:
   • Choose a period with minimal traffic and inform all affected users.
2. Prepare a Rollback Plan: (provided at the bottom of this blog)
   • Outline detailed steps to restore your original Aurora Serverless v1 cluster from a snapshot if needed.

Step 3: Backup Your Data – Create a Final Snapshot

1. In the RDS Console, select your Aurora Serverless v1 cluster.
2. Click Actions and choose Take snapshot.
3. Provide a name for the snapshot (e.g., aurora-v1-final-snapshot).
4. Click Take Snapshot and wait for the snapshot to complete (monitor the status until it shows as available).
5. Document: Note down the snapshot ID and creation timestamp.

Milestone 2: Restoring the Snapshot and Setting Up a Provisioned Cluster

Step 4: Restore the Snapshot to a New Provisioned Cluster

1. In the RDS Console, click on Snapshots from the left-hand menu.
2. Locate your snapshot (aurora-v1-final-snapshot), select it, and click Actions > Restore Snapshot.
3. In the restore dialog:
   • Cluster Identifier: Provide a new unique name (e.g., aurora-provisioned-for-migration).
   • DB Instance Class: Choose a provisioned instance type (e.g., db.r5.large) for the initial restore.
   • VPC and Subnets: Ensure you select the appropriate VPC and subnet group to maintain similar connectivity.
4. Click Restore DB Cluster.
5. Monitor: Wait for the new provisioned cluster to become available.
6. Document: Record the details of the new cluster, including endpoint and instance class.

Step 5: Engine Version Upgrade (if Necessary)

• Check: Confirm the restored cluster’s engine version.
• Upgrade (if required):
  • If your restored cluster is not at the minimum version required for Serverless v2 (e.g., below PostgreSQL 13.6), perform a minor upgrade:
    1. Select the restored cluster and click Modify.
    2. In the Database options section, choose the required minor version.
    3. Schedule the upgrade immediately if you’re in a maintenance window.
• Document: Verify the engine version post-upgrade.

Milestone 3: Converting the Provisioned Cluster to Aurora Serverless v2

Step 6: Convert the Writer Instance to Aurora Serverless v2

1. In the RDS Console, select your provisioned cluster.
2. Click Modify on the writer instance.
3. Under DB instance class, choose the Serverless v2 option (often labeled as db.serverless).
4. Set Capacity Range:
   • Minimum ACUs: e.g., 0.5 ACU (1 GiB RAM).
   • Maximum ACUs: e.g., 8 ACUs (16 GiB RAM).
5. Scroll down and click Continue, then review your changes.
6. Choose to Apply immediately if your maintenance window allows.
7. Monitor: Ensure the modification completes successfully and the instance is now running as Serverless v2.
8. Document: Record the new Serverless v2 instance details.

Step 7: Add Optional Serverless v2 Reader Instances

1. For scaling read workloads, you can add additional Serverless v2 instances.
2. In the RDS Console, select your converted cluster and click Add reader.
3. Choose the Serverless v2 option and configure the desired ACU range.
4. Monitor: Confirm that new reader instances are active.
5. Document: Save the configuration details.

Step 8: Perform Failover to Promote the Serverless v2 Instance

1. In the RDS Console, select the cluster.
2. Click Actions and select Failover.
3. Confirm the failover, ensuring that one of the Serverless v2 instances becomes the primary (writer).
4. Monitor: Check that the cluster endpoint now points to the new primary.
5. Document: Update records with the new primary endpoint.

Milestone 4: Updating Application Configuration and Testing

Step 9: Application Connection Changes

1. Review Your Connection Method:
   • Cluster Endpoint: If your application uses the cluster endpoint (a DNS name provided by Aurora), typically no changes are required.
   • Instance Endpoints: If using individual instance endpoints, update the connection strings to point to the new Serverless v2 primary.
2. Test Connectivity:
   • Run connectivity tests using a PostgreSQL client (e.g., psql) to ensure connections are successful.
3. Document: Note any changes made to connection settings and update internal documentation.

Step 10: Validate Performance and Monitor

1. Performance Testing:
   • Run application-level tests to ensure performance meets expectations.
   • Use Amazon CloudWatch and Performance Insights to monitor ACU utilization, CPU load, and replication lag.
2. Security and Networking:
   • Verify that security groups, VPC settings, and subnet configurations are intact.
3. Document: Record baseline metrics and any observations during the testing phase.

Milestone 5: Rollback Procedure (If Issues Arise)

Step 11: Initiate Rollback to Aurora Serverless v1

1. If Critical Issues Arise:
   • Immediately notify stakeholders and begin the rollback procedure.
2. Restore the Snapshot:
   • Go to Snapshots in the RDS Console.
   • Select aurora-v1-final-snapshot and click Restore Snapshot.
   • Create a new Aurora Serverless v1 cluster using the snapshot.
3. Revert Application Changes:
   • Update your application connection strings to point back to the original Aurora Serverless v1 endpoint.
4. Test Connectivity and Performance:
   • Confirm that the restored cluster functions as expected.
5. Document: Log rollback actions and share a post-mortem with the team.

Common Issues & Gotchas

• Serverless v1 cluster cannot be paused temporarily (for example, if you want to stop old cluster for while to verify if application crashes, you'll need to verify by other ways i.e cloudwatch logs, database internal activity (pgactivity)

• After successful migration the cluster label will still be provisioned even though cluster is migrated. This is info bug and doesn't impact the working of db (i.e cluster will work as serverless v2)

• You'll also need to migrate your database triggers (if any)

In next blog we'll explore Plan A (In-place migration) in depth.