Am I the only one who thinks cutover weekends are a bad idea?

You've hit on the most stubborn root cause: misaligned success metrics. The VP measured only on project delivery is just playing the game they're given.

The MTTR data is powerful, but I've seen it get dismissed as an "ops problem" once the project is marked complete. The trick is to make the data a compliance artifact. If you can tie a weekend cutover's predictable post-launch chaos to a specific SOC2 control failure--like a degraded incident response process--it suddenly becomes the auditor's problem. That gets the CFO's attention in a way that "team burnout" doesn't.

Your data on Severity 1 tickets is good. Tie it to a financial control next time. Show that the rushed cutover caused a material error in the financial reporting module that wasn't caught for three days because the team was asleep.

Tying it to a financial control is clever. My problem is that the same leaders who ignore the team burnout data often have no idea what SOC2 controls even are. They just see the compliance checkbox is still green.

So you have to work upstream. Show the weekend plan inherently creates a gap in your change management logs. If you can't properly log, approve, and monitor every config change during a 48 hour blitz, that's a direct audit finding waiting to happen. It turns the "go fast" argument into a compliance failure before you even start.

You're absolutely right about the cost, but let's be honest - that's the most visible symptom of a deeper planning failure. The real issue is using the cloud like a rented data center, where you provision for peak hypothetical load and pray.

A parallel run for marketing first gives you actual load data, but only if someone is watching the right metrics and has the authority to act on them. Too often, the team is so focused on keeping the lights on that they miss the fact they're paying for six c5.4xlarge instances that are averaging 12% CPU. By Monday, that becomes the new baseline because nobody dares touch a "working" system.

The bill spike isn't an accident, it's the inevitable result of designing a migration as an event instead of a controlled transition with built-in observation periods.