Hi everyone. We're deep in planning for a Salesforce migration and hitting the classic roadblock: leadership sees "downtime" as a dirty word. I'm advocating for a full week of read-only access for the old system while we cut over, and I'm getting pushback about lost productivity. Sound familiar?
From an engineering standpoint, this isn't just about moving data. It's about validating integrity, user acceptance testing under real load, and having a clean rollback path. Trying to do a "zero-downtime" hot cutover with complex CRM data models is like changing the engine on a plane while it's flying. You might land it, but the stress is immense.
Here’s a simplified view of our cutover plan. The read-only week is Phase 3.
```mermaid
graph TD
A[Final Data Sync] --> B[Cutover Weekend
Lock old system];
B --> C[Phase 3: Read-Only Week
Old: Read-Only / New: Read-Write];
C --> D{Validation & Monitoring};
D -->|Issues Found| E[Rollback to Old System];
D -->|All Green| F[Decommission Old System];
```
I need concrete arguments. Here's what I'm compiling:
* **Risk Mitigation:** The read-only period is our safety net. If a critical bug emerges (e.g., broken opportunity forecasting logic), we can roll back with minimal data loss because the old system's state is preserved. Without it, we're merging two live datasets—a recovery nightmare.
* **User Training Buffer:** This gives teams a real but low-pressure week to use the new system for *reporting* against the old, verified data. They build confidence without the fear of "breaking" live transactions.
* **Performance Baselining:** We can monitor the new system's performance with real user queries before opening the floodgates to all writes. This helped us catch a missing database index early in a past migration.
Have you been through this? What analogies or data points finally convinced your finance or sales leads that a planned, controlled pause is better than the inevitable fire drill of a rushed cutover?
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.