Task 04: Data sync and cutover

Introduction

This final task involves performing a planned failover to the Azure SQL Managed Instance. By performing a planned failover, you’ll help Adatum Corporation maintain business continuity and prevent disruptions to their eBook shopping services. This ensures that Adatum Books remains operational even in the event of a failure, providing a seamless experience for their customers.

Description

In this final exercise, you’ll perform a planned failover to the Azure SQL Managed Instance, breaking the link and making the Managed Instance the new primary database.

Success criteria

You performed a planned failover to the Azure SQL Managed Instance.
You successfully broke the link and made the Managed Instance the new primary database.

Learning resources

In a production environment, you would typically want to follow these steps for the data migration during a maintenance window:

Stop the workload on the primary SQL Server database so the secondary database on SQL Managed Instance catches up.
Validate all data has made it over to the secondary database on SQL Managed Instance.
Fail over the link to the secondary SQL managed instance by choosing Planned failover.
Cut over the application to connect to the SQL managed instance endpoint.

Key tasks:

01: Fail over the Adatum database using SSMS

Expand this section to view the solution

In the SSMS Object Explorer, right-click on the Adatum (Synchronized) database, select Azure SQL Managed Instance link, then select Failover….
In the new windows Introduction page, select Next.
Planned manual failover will be selected for the failover type. Select Next.
If it launches a browser window, sign in with your lab credentials:

Item Value

Username Your Azure username

Password Your Azure password
Close the browser window.
Select Sign in… under Sign in to Managed Instance.
Use the following on the Connect to Server window:

Item Value

Authentication SQL Server Authentication

Login MILab

Password your Azure password (used for SQL/MI authentication
Select Connect.
Select Next.
Select the I understand checkbox under Link removal, then select Next.

Failing over to a SQL Managed Instance stops replication, breaks the link, and drops the distributed availability group.
On the Summary step, review the actions, then select Finish when you’re ready to fail over the database.

You can select Script to generate a script to easily fail over the database using the same link in the future.
All entries on the Results should show Success.
Select Close on the window. You’ll see that the distributed availability group no longer exists.

Item	Value
Username	`Your Azure username`
Password	`Your Azure password`

Item	Value
Authentication	SQL Server Authentication
Login	MILab
Password	your Azure password (used for SQL/MI authentication

02: Cut over to the SQL Managed Instance

Expand this section to view the solution

At the top of SSMS’s Object Explorer, select Connect, then select Database Engine.

If it’s not already filled out, use the following on the Connect to Server window:

Item	Value
Server name	the fully qualified host name of your Managed Instance(that you copied)
Authentication	SQL Server Authentication
Login	MILab
Password	your Azure password (used for SQL/MI authentication)

Select Connect.
Verify the state of the Adatum database in the Managed Instance.

Conclusion

Congratulations! You’ve successfully migrated a SQL Server database to an Azure SQL Managed Instance.

In a real-world scenario, after you successfully complete the migration stage, you should go through a series of post-migration tasks to ensure that everything is functioning efficiently.

This phase is crucial for reconciling any data accuracy issues, verifying completeness, and addressing performance issues with the workload.

For more details, review the Post-migration section of the migration guide.