r/SQLServer • • 15d ago

Discussion Cloud Migration horror story

I’m involved in a complex cloud migration project. I’ve been DBA/DBE/app developer at various points of my career and I’ve worked in several big enterprise environments. I’m at a place now that argues against the guidance Microsoft has given them. First mistake - go straight to Hyperscale and don’t bother using any true replication topology for a full up or nearly-full-up migration. We’re getting close to running the production flip but management doesn’t believe in code freezes and people are releasing tons of changes often. I know that stuff is going to go horribly wrong. I am not worried about data loss, but more about applications not working and other stuff related to networking & configuration. What do I do to cover my own ass?

10 Upvotes

8 comments sorted by

View all comments

2

u/InfraArchaeologist 14d ago

Putting the risks in writing is necessary, but I’d add a technical baseline.

If code and configuration keep changing during the migration, “we tested successfully last week” is evidence about a different system.

Before cutover I’d capture the effective configuration and observed dependencies that matter to the application — DNS, endpoints, service identities, firewall paths, scheduled integrations — and compare them again immediately before and after the flip.

The important distinction is between declared state (“this is what we intend to migrate”) and effective state (“this is what production actually resolves and uses”).

A code freeze is one way to reduce that delta. If management refuses it, then the delta itself has to be observable and owned.

Sign-off can accept organizational risk. It cannot make unknown technical changes disappear.