Hey everyone! I have an Azure SQL Server with five databases currently based in North Europe. I need to shift these to another region, but I've hit a snag because the connection strings are hard-coded into a lot of our applications. I really want to avoid asking our developers to change the code if possible. I was considering a workaround where I temporarily move the databases to another SQL server, then create a new one in the desired region with the same name and transfer the databases back. Does anyone have a more efficient way to handle this?
5 Answers
I handled a similar situation using a failover group while setting up disaster recovery. Just keep in mind it doesn't handle server-level objects like logins. Developers switched to a failover endpoint during migration, which helped streamline the process. Also, you might want to keep a minimal server footprint in the new region to manage costs. Check out this guide for more details: https://learn.microsoft.com/en-us/azure/azure-sql/database/failover-group-sql-db?view=azuresql
You can set up a DNS alias for your server name! It’ll take some setup—first, geo-replicate your databases to the new region, do some failover magic, and then delete your old SQL server. But you can ease your transition this way. Also, having the devs switch to pulling connection strings from a key vault could save you future headaches. Making connection strings dynamic is crucial!
Here’s a thought: you could just roll up a newspaper and give the lead dev a gentle nudge for allowing hard coding in the first place! For now, setting up DNS could be a temporary fix, but make sure to do it right for the long haul.
It’s really not ideal to hard code connection strings in 2023! You definitely should consider replacing them with environment variables or some other configuration method. It’s a simple fix that could save you a lot of headaches.
Seriously, who even does that anymore? That was a thing back in the early 2000s but there are better practices now!
I’m curious what’s prompting the move? Is it about costs, regulations, or perhaps latency issues? Knowing the motivation might help others give you tailored advice.
Thanks for the tip! This seems like a tidy solution. I wish it were entirely up to me; all our new systems do this, but we’ve got some ancient setup from the days of Excel and Access that needs replacing soon. *sigh*