Hacking the migration service in Azure Database for PostgreSQL
Introduction Azure Database for PostgreSQL offers a powerful and scalable database solution for developers and enterprises. Whether you're looking to change your networking configuration from VNET integration to Private Endpoint or downsizing storage, the Migration Service in Azure Database for PostgreSQL provides options for smooth migrations. Historically, migrating between flexible servers was manual—using pg_dump/pg_restore or third-party tools—which can be time-consuming and error-prone. This guide introduces an alternative workaround: utilizing the Migration Service to facilitate flex-to-flex migrations and outlines known networking scenarios where this workaround has been used. Note: While flex to flex migration isn't officially supported by the Azure Database for PostgreSQL product team, it has been observed to work successfully for many customers. Why migrate from Flex to Flex? There are several reasons common reason to migrate between Azure Database for PostgreSQL Flexible Servers: Change from VNET integration to Private Endpoint networking Downsizing the storage capacity of a server Consolidating databases to optimize costs Regardless of your specific reason, utilizing the Migration Service in supported scenarios simplifies the process and helps maintain data integrity. How the migration workaround works? In brief, select "On-Premise Server" as the migration source in the Migration Service, then provide the details of your existing flexible server. This approach leverages the standard migration tool, sidestepping some limitations. Restrictions & Limitations Keep in mind, the same restrictions outlined by Microsoft in their official documentation apply here: Known issues with the Migration Service Prerequisites for migration Migration of extensions Known Networking Scenarios (Unofficially Supported) PostgreSQL Flex source PostgreSQL Flex target Status Public Access Public Access Works Private Endpoint Private Endpoint Works Vnet Integrated Private Endpoint Works Vnet Integrated Vnet Integrated Not tested How to perform the migration? Step 1: Launch the Migration Service: Step 2: Enter Source Details Select “On-Premise” as the source server type Choose the migration option Choose the migration mode Include the Azure Database for PostgreSQL source server details - this is where we input the flexible server credentials Step 3: Connect to the Target Server Choose your target flexible server and complete the migration wizard Remember to review extension compatibility if you use extensions. Conclusion Migrating between Azure PostgreSQL Flexible Servers using this workaround is a practical option when supported scenarios don't fit your environment. Follow the outlined steps for a smooth, reliable migration with minimal disruption. With careful planning and validation, you’ll maintain data integrity and build a scalable database infrastructure on Azure. Happy migrating! Additional Tips & Resources If you encounter issues related to extensions or other limitations, consider exploring pgcopydbfor advanced migration options. Feedback: We welcome your thoughts and suggestions - as well as net new supported scenarios.Online Migration to PostgreSQL Flexible Server on Azure from Single Server
You can leverage PostgreSQL's online migration feature for seamless database transitions, ensuring minimal downtime during the process. By employing this capability, you can efficiently migrate data while simultaneously maintaining continuous access for users. This approach streamlines the migration process, enhances overall system reliability and reduces disruptions.
